Bill - Thank you very much. This is the type of information I was hoping to receive. I'm one of those DBAs who prefer to see the potholes before I fall in them.
Dennis Williams DBA, 20% OCP Lifetouch, Inc. [EMAIL PROTECTED] -----Original Message----- Sent: Thursday, June 20, 2002 12:49 PM To: Multiple recipients of list ORACLE-L Conflict resolution also has to be considered for log based replication as well. Same problems exist. If you think about it Oracles AQ approach is pretty much a log. Multi-master replication is still trigger/AQ based in 9i. It's working well for us. Some of the things you can do to reduce (but not elleminate) conflict resolution issues are: 1). Stagger sequence generated primary keys by site 2). Put triggers in place to prevent updating of primary keys (avoids some uniqueness conflicts) 3). Add a last_updated_dt to each table and use that as your primary method of update conflict resolution 4). Add a "primary" site capability for tie breakers. Oracle has a built in method, but it requires you add a site column to each table. If it is not data dependent, I prefer a custom stored procedure method where you choose a "primary" site that is not data dependent. Deletes are still our biggest problem. Don't really understand why they can't be applied in the same order at the remote site (perhaps because we am using parallel propagation?). But for some reason if we do massive deletes across multiple related tables in the same TX, we always end up having to manually reconcile. An approach recommended by oracle for this is to add a deleted_dt column to every table and do deferred batch deletions. We tried this in conjunction with views and instead of triggers to hide it from the application. A couple of problems with this approach is that if you delete, then try to re-insert with the same alternate key before the deferred purge process runs, you will get ORA-00001 errors. If you run the deferred deletion process too often you defeat the purpose of it and overload the system. --- [EMAIL PROTECTED] wrote: > Dennis, > > All dbs whether SQL Server or Oracle need to deal > with conflict resolution, thats not strictly an > Oracle limitation. As far a Quest goes, they handle > replication completely different from Oracle. > Oracle itself is still using triggers (in 8i at > least) , ubt now they hide the trigger, Shareplex > reads the Oracle redo logs. I believe that 9i uses > the redo logs and is based (structured) after > Shareplex itself - there were lots of articles on > this with the pre-release of Dataguard. Furthermore, > Oracle places all of its replication metadata in > SYSTEM tablespace which I dont like, Sharpelex uses > its own (which the user configures). As far as > Shareplex manuals, Quest is the one company that I > will stand up and say that regardless of anything > else, their documention is EXCELLENT. Their > documentation takes you from Shareplex architecture > right to directory structure, actual files, usage > and even scripting. The sales rep was incorrect. > However, I can see them not releasing the manuals > without a purchase. > > I believe that they are available on-line for > download, though I do not know if it is just for > current customers only. > (hehe can't believe I am defending a vendor:>). But > when someone does something right, I like to give > credit. Also, once you are setup, they are VERY > stable. I have my issues with them, but overall I > feel they do great job at what they do. > > > Hannah - Hope it helps any. > > > > -----Original Message----- > > From: [EMAIL PROTECTED]@SUNGARD On Behalf Of > DENNIS WILLIAMS <[EMAIL PROTECTED]> > > Sent: Thursday, June 20, 2002 10:33 AM > > To: Multiple recipients of list ORACLE-L > > Subject: RE: Replication question > > > > Yechel - Wow, what a blow to be struck with the > dreaded RTFM first thing in > > the morning. Thanks Yechiel, I needed that. > > Actually, I was hoping there was another resource > besides the > > manual, for two reasons: > > 1. This development group is a little irritated > that they are forced > > to use Oracle instead of MS SQL, so they are > taking replication issues as > > being Oracle limitations. > > 2. They have been talking to the Quest > salespeople, who naturally > > heap disdain on Oracle's standard replication > (selected Oracle SE because > > the price was closer to MS SQL). I asked the Quest > rep if they had a > > document similar to the Oracle manual. Gosh, he > couldn't think of one. Since > > nobody on the list has mentioned one, maybe they > don't have one. The best > > resource I've found so far is a former Sybase DBA > who was able to confirm > > that log-based replication has most of the same > issues as Oracle standard > > replication has. > > Thanks everyone for your replies. > > > > Dennis Williams > > DBA, 20% OCP > > Lifetouch, Inc. > > [EMAIL PROTECTED] > > > -- > Please see the official ORACLE-L FAQ: > http://www.orafaq.com > -- > Author: > 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). __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Pass 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). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS 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).
