Re: Oracle vs Informix comparison

It seems to me, that a good transaction log should be "lean" - i.e., only contain the physical representations absolutely necessary to redo the transaction. If you agree with this, then consider the impact that this would have if the transaction log is the source of replication - All of the replicated databases would have to be physically (at the lowest level of the transaction log information) identical. This is not likely except in the most ideal situations. The trigger / stored procedure replication approach provides the best balance between performance and real-world business requirements. Steve ;David Williams <djw@smooth1.demon.co.uk> wrote: ;>In article <58if4p$oca@dfw-ixnews2.ix.netcom.com>, Rajashekar ;>Sundaramurthy <rajsekar@ix.netcom.com> writes ;>>You wrote: ;>> ;>> You are describing a synchronous replication scenario wherein the ;>>updating transaction waits for the replication to be completed before ;>>the commit occurs. ;>> ;>>In Oracle7 (which uses triggers/stored procedures and deferred ;>>transaction queues) to handle replication, the simpler update-anywhere ;>>environment works as follows ( for asynchronous replication) ;>> ;>>Application inserts a row into a table at the master site; ;>>The AfterInsert trigger fires which updates a snapshot log with the ;>>ROWID of the newly inserted row; ;>>Application commits the insert transaction; ;>> ;> ;> There is still a performance problem - I write all the data necessary ;> to redo the update to a transaction log. Why should I also write it to ;> a snapshot log?? It is a waste of time. Also why rewrite the code to ;> performance the transaction on the site you replicate to. The code for ;> transaction follforward is already written/debugged/tested in a ;> production environment. Why a) Have more code which is not as ;> efficient and clear will not be as stable b) Write the transaction ;> 1.1 times to disk instead of once.? ;> ;>-- ;>David Williams Steve Tahmosh State Street Bank