Re: How keep 8i standby no-more-than 30 minutes behind?

"Sean M" <smckeownNO_at_BACKSIESearthlink.net> wrote in message news:3CA14DE7.28F4974F_at_BACKSIESearthlink.net...
> "Howard J. Rogers" wrote:
> >
>
> <snip good synopsis of init.ora parameters>
>
> > Unless, of course, you create a job (dbms_job is useful here, but you
could
> > do it from outside the database with cron) which issues an 'alter system
> > switch logfile' every half hour. That way, regardless of whether the
online
> > log is practically empty (quiet time) or full (busy), the logs will
switch
> > and an archive will be produced, which can be shipped to the standby.
>
> Right - but none of that *ensures* that the generated archive
> information is actually received *and applied* to the standby since 1)
> the primary archiver could fall behind and have multiple online redo's
> in need of archiving; 2) if MANDATORY isn't set in the
> log_archive_dest_n, the archive might not make it to the standby; 3) the
> standby might fall behind applying the redo, etc., etc. And without
> that guarantee, our friend Guy is sunk.
>

He's got 8i. We don't know whether he has the Standard or the Enterprise edition. If the former, the dest_n parameters are not useable, and mandatory is therefore not specifiable either. Min_succeed_duplex_dest would work in either, of course. But I think this is all a bit detailed for Guy at this stage. Whilst he's off worrying about intra-log checkpointing, it's enough for now I think to point him in the direction of log switches. When he's got that sorted, then this level of sophistication is going to be useful, undoubtedly.

> > Of course, there is another answer: upgrade to 9i. There, you can
configure
> > the standby to lag the database by a specific number of minutes. But
that's
> > designed to *prevent* the application of shipped redo, to allow user
errors
> > to be corrected without the expense of an incomplete recovery. And
that's
> > not what you're after.
>
> Ah, but 9i also allows you to use LGWR (as opposed to ARCH) to transport
> the redo data to the standby site, which allows for the possibility of
> no data loss and no data divergence

That's why I carefully said 'shipped redo' rather than 'shipped archives', of course.

I'd also prefer to say "and/or" there. You can choose no data loss AND no data divergence, or just no data loss. Or even just 'do your best'! DataGuard doesn't *mandate* no data divergence.

>- i.e. an Oracle guarantee that the
> standby is completely in sync with the primary (except, of course, for
> our old friends, the nologging transactions). So in sync, in fact, that
> if the primary can't write to the standby's redo logs, the primary shuts
> down immediately.
>

If you choose to run in protected mode, of course, which is optional.

HJR
> Regards,
> Sean
Received on Tue Mar 26 2002 - 23:23:36 CST