Re: Oracle vs Informix comparison

Of course, any Oracle or Informix comparison isn't complete without a response from Thomas Kyte. Thanks for continuing to monitor the Informix mail list. At 07:51 PM 12/7/96 -0600, tkyte@us.oracle.com wrote: }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 } } Chuck Miller //////////////// Principal Systems Engineer ////////// // Informix Software Inc. ////// / /// 5 Concourse Parkway, Suite 1500 ///// // //// Atlanta, GA 30328 //// // ///// /// // ////// Phone 770-395-2300 // // /////// Fax 770-395-2306 / /////////// E-mail chuckm@informix.com ////////////////