Re: REplication vs. Standby database

An important point: with a standby database, if a hardware failure of the disk/controller of your current redo log buys the farm, any tranactions that recently took place will not be propagated to the 'standy' system. Reason: if it hasn't been archived, it won't be sent by to the standby database to be applied.

By the same token, if you use a trigger to update a remote table, (replication), the update could fail on the primary, because the sencodary database has crashed.

Lot's of pro and cons. I do believe, however, Advanced que'ing will wait for the secondary/remote database to come back online, and not fail the primary's transaction.

This is something I have just began to investigate. I plan on getting into it a little more deeply.

Doug
Software Analyst/OCP

Tapan Trivedi wrote:

> They are not the same. Stand by uses a whole different methodology than
> replication. Replication can be partial. It can be snapshot or
> multimaster. You can hot backup a replicated database . The standby on
> the other end deals with totally different parameters.
> Tapan H Trivedi
>
> dkight wrote:
> >
> > We had a situation recently where our entire raid device suffered a hardware
> > failure. I am looking at updating our disaster recovery scheme by using
> > either a standby database or Replication. I understand that both apply
> > archive redo logs to a secondary database.
> >
> > Why does Oracle have a standby database product is replication is
> > essentially provides the same functionality and the replicated is available
> > for user access?
Received on Sun Aug 01 1999 - 02:11:31 CDT