Re: replication

Ralf Karpa wrote:
>
> On Sun, 27 Apr 1997 00:22:35 +0300, voodoo <voodoo_at_netvision.net.il> wrote:
>
> Hi.
>
> >is replication based only on database triggers and not on log sniffing?
> Replication is based on packages and triggers.
>
> >roomers say that log sniffing is faster. is it ?
> As far as I know, Sybase does log-sniffing for replication. I think this will be
> faster.
>
> Bye Ralf.

Replication (regardless of vendor) consists of two phases, which are shown below with implementations used for each.

1. Capture
2. Redo Log Sniffing
3. DML Capture via Triggers
4. Apply
5. Physical Log Apply
6. DML Execution

Vendors who have implemented Redo Log Sniffing have made a big deal out of the supposed performance advantages. However, replication schemes are constrained by the APPLY phase. If log sniffing has any advantage, it is attacking the wrong problem because that is not where the bottlenecks are found.

The Apply phase typically is done through DML execution, not through log apply. The difficulty here is that changes must be applied in a transactionally consistent manner, and must preserve the original ordering of transactions. For example, if transaction #1 adds a new customer and transaction #2 updates that customer, you can't apply them in 2,1 order. To get around this problem, Oracle implemented Replication Groups so you can parallelize propogation of changes where possible.

Bottom line, don't worry so much about the capture phase. Look at the APPLY phase, and can other vendors parallelize apply operations. You'll also want to look at features such as automatic conflict detection and conflict resolution through declarative means. You don't want to code all of this.

Managability is also key to operating a replication environment. Oracle has the GUI Replication Manager to make it easier. Also, consider the luxury of having all replication events stored in database tables and visible through SQL or other GUI tools (Oracle Data Browser, etc.). I would hate to have to dig through thousands (millions?) of records in flat files to find a problem transaction (un-anticipated conflict, etc.). I'm thinking of a batch transaction I dealt with last week that had 125,000 statements before the COMMIT! Not all work is nice and easy OLTP style.

-- 
----------------------------------------------------------------------
The opinions expressed are my own and do not necessarily represent
those of Oracle Corporation.
----------------------------------------------------------------------