Re: Re:Help: Standby database config.

Exactly how is not applying the logs automatically going to help you in this situation?

What I mean is, if you detect that a drop table has happened within minutes of it happening, then the redo for that will likely be in your main database's current redo log. Hence it won't have been archived, and hence, the standby won't have been 'tainted' by it. Whatever method of applying redo logs you went for, your standby would still be OK.

But if the drop table wasn't detected until some considerable time had elapsed, then (a) in automatic managed standby mode, you standby suffers from the same problem or (b) in manual standby mode, your standby is hopelessly out of date (and/or suffers from the same problem as well!)

Since you can't skip archives, you either apply the one with the drop table command in it, or you forfeit your ability to apply any others *after* that log -hence the standby gets more and more out of date.

And unless you propose only to manually apply the logs at the end of the day, after doing exhaustive checks to make sure that there are no problems with the production system whose replication to the standby would be undesirable, this really isn't a very workable proposition. Without those checks, you'll be just as likely to apply a piece of redo containing something very unfortunate as you would have done using automatic managed standby mode.

Standby databases are meant to protect you from disaster. User errors, however inconvenient, are not disasters, and ordinary incomplete recoveries are your 'way out' of them. I think it an extremely bad idea to confuse the two, and your friend is giving you very poor advice.

Regards
HJR <u518615722_at_spawnkill.ip-mobilphone.net> wrote in message news:l.993988800.1535369873_at_adsl-151-197-238-2.phila.adsl.bellatlantic.net.. .
> A friend of mine suggested me to config our standby database
> withoutusing 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?
> >Daniel A. Morgan
>
> What he means is that if somebody drop a table mistakenly or something.
> If we just let oracle write all the logfiles to the standby destination,
> but only apply 2 hour behind of them, when we need to bring up the
> standby database, we can apply the rest of it. Otherwise, we can use
> it for recover until time.
>
> thanks
>
>
>
>
>
>
> --
> Sent by dbadba62 from hotmail subdomain of com
> This is a spam protected message. Please answer with reference header.
> Posted via http://www.usenet-replayer.com/cgi/content/new
Received on Sun Jul 01 2001 - 16:02:04 CDT