Re: replication

I believe that performance is constrained at the collecting phase at the Primary Server level. When this is the case, as it so often is, a full suite of installed stored procedures and triggers on all replicated objects could be nothing but slower than log sniffing ( which as zero impact on Server performance ).

Keep in mind that an environment set up to do log sniffing is always used for read-only purposes or disaster recovery. Now, doesn't this suggest that performance on the Server side is of high concern and wouldn't the local dba rather just send the log files to the replicate than have every DML statement fire off a trigger, a stored procedure, or both? I think so.

What I find interesting is that the only solution Oracle provides for those of us that need a read-only replicate is one that requires the use of triggers and stored procedures. The Standby-mode software built in to the 7.3 server is nice but only good for disaster recovery uses.

-Kevin Brand

Christian A. Craft <ccraft_at_us.oracle.com> wrote in article <33708728.2DBF_at_us.oracle.com>...
> 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
> 1) Redo Log Sniffing
> 2) DML Capture via Triggers
> 2) Apply
> 1) Physical Log Apply
> 2) 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.
> ----------------------------------------------------------------------
>
Received on Wed May 07 1997 - 00:00:00 CDT