Re: help: standby database config

Hannes Erven wrote:

> "Daniel A. Morgan" <dmorgan_at_exesolutions.com> wrote in message
> news:3B3EAED7.DEC83A8_at_exesolutions.com...
> > u518615722_at_spawnkill.ip-mobilphone.net wrote:
> >
> > > A friend of mine suggested me to config our standby database without
 using managed recovery because of the following reason:
> > >
> > > If you have corruption or bad data get into the online db you have no
> > > way to easily spot and stop that data from automatically migrating into
> > > the standby db. If you keep everything the same but only apply the
> > > recovery on the failover side every 2 hours or so you then have 2 hours
> > > to catch and stop the recovery. like recover to a point in time just
> > > before the corruption. The way you are doing it now with managed
> > > recovery I don't think it buys you much failover capability.
> > >
> > > Is this really a good idea?
> > >
> >
> > Not in my book. A stand-by database that can't be brought up in a minute
 or two isn't a stand-by database. Exactly what form of
> > corruption is your friend thinking is going to occur in the redo logs?
>
> Think of someone doing an
> DELETE FROM Very_Important_Table;
>
> or
>
> UPDATE CriticalData SET ImportantColumn='WrongValue';
>
> These changes wouldn't make their way through to the standby data. But i
> agree with you, Daniel, not automatically applying archived redo to the
> standby database does not make sense - in case your primary db goes down,
> you'll experience massive data loss.
>
> my 2 cents,
> -hannes

My feeling is apply the redo logs as fast as possible. The point of a stand-by database is not that it is perfect ... but rather that it is an exact replica of the production database at the instant it went down.

Daniel A. Morgan Received on Sun Jul 01 2001 - 19:48:04 CDT