Re: Symmetric Replication VS. Standby Database?

While symmetric replication does work and provides a solution to many shops' needs, It simply doesn't work well with high transaction volume. If you turn up your server without this sort of replication, measure its performance at peak activity for sustained periods of time, then do the same with symmetric replication added, you'll find that performance will suffer. Consider the fact that every DML statement issued toward a replicated table will fire off additional, 'recursive' SQL code in the form of triggers and stored procedures. This processing creates logs of system activity so that it may later be replicated to a secondary server. That is, your inserts generate more inserts. In your environment, with millions of inserts daily, this may be unbearable.

I suggest you go with the standby server scheme where you copy your archived redo logs to a secondary site that remains in a constant state of recovery. This way, you have no impact on Primary Server performance while providing yourself with solid disaster recovery.

Take a look at the 7.3 Server Documents on Standby. Pay particular attention to the sections describing events that are not propagated to the standby server. Many ( database maintenance procedures for instance rebuilding tables and/or indexes for performance reasons ) are not, which may require a full re-build of your standby server.

There are drawbacks to both methods.

-Kevin Brand

Ben Harmon <benh_at_dascom.com> wrote in article <5latog$jr2_at_news9.noc.netcom.net>...
> Hi,
> We will be setting up a high volume OLTP Oracle 7.3 database on
> Solaris 2.5. Inserts could exceed millions per day with a fair amount of
 

> selects as well. The table relationships will be fairly simple, however.
> This will be a 7x24 system and down time has to be kept to an
 absolute
> minimum. I am contrasting the relative benefits and costs of symmetric
> replication versus a standby database.
> I would greatly appreciate any feedback that this brilliant and
> educated group might care to offer.
>
>
> Thank you,
>
> ________________________________________________
> Ben Harmon
> ben_at_dascom.com.nospam
> **Please remove .nospam suffix if you want to mail me**
> ________________________________________________
>
  Received on Wed May 14 1997 - 00:00:00 CDT