Well, the flood of responses (not) to this topic probably answers one of the points raised!
While endorsing all that Dennis has stated, I would just like to add something. Most crucially, replication is an exercise in logic, which fundamentally depends on getting your database design correct on both (or all) instances. If one site has an indadequately defined model, then sure as fate, replication will uncover the weakness sooner or later in the form of corrupt data or a failed replication transaction. Which provides a useful side benefit, by the way. We have been running replication for 15 years. In-house system. Slowly and incrementally improved over the years. Why replicate? Because we had such a poor wan, that transactions across it were highly problematic. Easier to have a couple of instances, and replicate between them each night. Now we have three big sites, and murmurs between them in the dead of night ensure everything is maintained synchronous... The point about checking that replication has worked in very important. I spent a lot of time building up an ever-increasingly complex array of exception reports. No emails in the morning - all's well. Hey, but replication is great for carrying out major data migrations! peter edinburgh > -----Original Message----- > From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]] > Sent: 26 August 2002 19:19 > To: Multiple recipients of list ORACLE-L > Subject: RE: General Replication question > > > Ed - We have flirted with the replication thing here for some > time. I have > had the same questions as you, trying to take classes, for > example. I don't > think replication is widely used, but there are plenty of > sites out there. <snip> ********************************************************************* This e-mail message, and any files transmitted with it, are confidential and intended solely for the use of the addressee. If this message was not addressed to you, you have received it in error and any copying, distribution or other use of any part of it is strictly prohibited. Any views or opinions presented are solely those of the sender and do not necessarily represent those of the British Geological Survey. The security of e-mail communication cannot be guaranteed and the BGS accepts no liability for claims arising as a result of the use of this medium to transmit messages from or to the BGS. The BGS cannot accept any responsibility for viruses, so please scan all attachments. http://www.bgs.ac.uk ********************************************************************* -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Robson, Peter INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
