Re: Advanced replication 1

A couple of comments on the original questions and Glen's answers. Firstly, since 7.1.6 when replication first came out, Oracle has always detected the conflict. To do this, in Oracle7 a copy of both the old row and the new one were sent as part of the replication to be compared at the destination site. In Oracle8, with MIN_COMMUNICATION set you can send just the parts of the row that make sense to send (for example, the primary key and the old and new values of just the changed columns rather than all columns).

So detection has always been done. Resolution, however, is NOT something that any DBA in their right mind would want to allow the kernel to perform automatically. How can Oracle determine who should win out in such cases? It's really driven by business needs, not technical ones. So what Oracle does is provide you with a variety of mechanisms to tell the database how to resolve the conflict (latest/earliest timestamp, site priority etc.).

Now back to Glen's first answer. Technically, he's correct. Oracle leaves it to you to determine how to resolve the conflict. Should this be done manually? In 99% of cases, the answer would be no, but sometimes it makes sense. For example, one site I worked at had data dependent resolution needs that could not be coded in PL/SQL. They had a person check the error queues and decide who should win out. But most of the time this doesn't make sense. You should put automatic conflict resolution in place.

As far as the applications being informed is concerned, there is no way to automatically do this. What I've seen some sites do is build a system that tells the users directly, either via email or a table that's checked on login, that the data has changed. Again, it's so difficult to work out a way to do this across all 85 odd platforms that Oracle is deployed on, and across all application types, that we can't do it automatically in the kernel.

HTH. Pete

Glen Upreti wrote:

> I will preface this by saying I am making a few assumptions:
> A. You are using asyncrounous replication.
> B. You are using Oracle's row-level replication, not procedural
> replication that you have written.
> C. You are using Oracle 8 Advanced Replication.
> D. Anything I may say may not be used against me.
> Here it goes:
> 1. Oracle by default does not resolve this conflict, it just identifies
> it for you to fix. Yipee!
> 2. I believe that the data in site A will look like what it was changed
> too and the data in site b will look like what it was changed to and the
> conflicts will be stored as changes not yet done in def_error in the
> respective database (site b's changes will be stored in def error on
> site a and vice versa). Since you mentioned site c, site c's status
> cannot be determined because I do not know where c is getting it's data
> from. if from both A and B then site c will look like whichever change
> it receives first and hold the second change in def_error.
> There are things, however, that you can do to have oracle resolve these
> errors by itself (by site priority, by time, I can't remember).
> 2.1 Depends.
> 2.2 I do not think that they are, you just have to keep checking
> def_error.
> --glen
>
> Issa Semaan wrote:
> >
> > QUESTION 1 :
> >
> > In an environment of replication Muti-Master with 3 masters sites (A, B and
> > C) , all master sites containing in their main group the same table X filled
> > with the same data :
> > - A Local application on site A removes a data D of table X, then validates
> > (transaction 1).
> > - Another local application on the site B then tries to update the same data
> > d of table X (transaction 2).
> > In this case, Oracle detects a conflict of replication and tries to solve
> > it.
> > 1. How does Oracle try to resolve this conflict?
> > 2. If Oracle does not manage to resolve this conflict, how does it reacts?
> > 2.1. Are the transactions rolled back ? If yes, which one and on which site
> > ??
> > 2.2. How are the applications informed of the failure of the transactions?
>
> --
> |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
> Glen Upreti
> Senior Oracle DBA
> Northern Arizona University
> Phone (520)523-8393 Fax(520)523-7407
> Glen.Upreti_at_NOSPAMnau.edu

--
Regards

Pete

Received on Tue Jun 29 1999 - 13:40:20 CDT