Re: Oracle vs Informix comparison

Actually what really happens in Oracle replication is: 1. Application updates one table. 2. Trigger fires to record the fact that some replication will need to be done. 3. Application commits and end user happily continues work. At some point in time after the application commits, the system will pick up the changes, transmit the transaction (not individual statements but the whole transaction) to other sites to be replayed. The end user is not waiting for this to happen, the 2pc is used by the system to ensure a transaction gets sent to a remote site at least once and at most once. the 2pc is never used by the client application in this scenario. the 2pc is used to gaurantee the data gets propagated correctly. Oracle's replication works with disconnected (no network available) users as well as connected users. If the following, wrong, timeline where accurate, disconnected users could never update information. what you have described is syncronous replication. While Oracle supports that if you want, our replication uses asyncronous replication techniques. You have to go out of your way to do syncronous replication. So - the transaction does not suffer the time-lag of the replication being processed on the remote machine. - adding more readers to my log files (the single largest point of contention in an RDBMS) isn't going to speed up my database either. - the stored procedures/triggers, being system generated and managed, cause as many applicatoin level mess-ups as do primary keys, foreign keys, check constraints, etc. Just another constraint. On 7 Dec 1996 14:50:21 GMT, satriguy@aol.com wrote: >While both methods will work, there are distinct advantages of using log >based/async replication over triggers. If we are using trigger based >replication and are in a transaction, then the transaction must suffer the >time-lag of the replication being processed on the remote machine. In the >best of cases where the trigger is simply copying the data into another >table within the same instance, there is still additional overhead. Also, >if this approach requires that a lot of triggers/stored procedures be >created which opens the possibility of application level mess-ups. > >CDR (or as it is now called Enterprise Replication) works off the log >files that are used for rollback and recovery. That means that there is >no increase in the code path of the transaction that is being replicated. >We simply have a seperate thread in the engine that is scanning the tail >of the log file and copying data which is to be replicated to a send >queue. This allows a single thread to manage the replication, rather than >all of the triggers/stored procedures that would be necessary in a trigger >based replication scheme. This results in much less overhead, less >requirements in the procedure cache pool and fewer possibilities of >failure. > > >Madison Pruet Thomas Kyte Oracle Government http://govt.us.oracle.com -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet