Well, I'm glad you're both happy.
The fact remains, however, that a delay in applying the logs may give you
the chance to avoid repeating a daft user error at the cost of then not
being able to apply all sorts of useful transactions in the redo stream that
took place *after* the user error took place.
Unless you can hack a workaround (beyond the scope of most, I would have
thought) it is not possible to skip a chunk of undesirable redo, and apply
the desirable stuff. *That's* the real issue.
So all this stuff about it being a trifle to apply 8 hours of unapplied redo
is really besides the point: if you've got such a backlog because you are
hoping to avoid replicating mistakes, then presumably you are signing up to
the proposition that the 8 hours of redo will *never* be applied (because at
8 hours and one second, there was a stupid user error).
The benefits of opening a standby database missing the user error but also
missing 8 hours of useful work somehow escape me. But if you can sign up to
such a proposition, go for it. It just wouldn't be 'usual'.
Of course, Oracle itself has muddied the waters somewhat by allowing standby
databases to be opened read only as what you term a reporting instance, and
all the while it's in that state, new redo cannot be applied to it... so
even Oracle itself allows the idea that the standby may be allowed to get
out of date, and that in certain environments, this would be happily
accepted. That still means, however, that in the event of disaster, you can
no longer fail over to a near-clone of the production instance, only to a
rather stale and out-of-date version of a clone. So the added functionality
you gain out of standbys in 8i (and now 9i) is always at the expense of
their role in disaster mitigation.
Provided we can agree on that last statement, then we are in complete
agreement.
Regards
HJR
"Hemant K Chitale" <hkchital_at_singnet.com.sg> wrote in message
news:9hpuk9$9rp$1_at_dahlia.singnet.com.sg...
> I agree with Steve (or "bhtech" ?).
> A Standby Database doesn't have to be for Disaster Recovery only.
> Even if you look at a Disaster scenario, there are two
> considerations
> a. Do you have the transactions available at the standby / remote
> site ?
> b. How much time does it take to bring the standby / remote site
> online ? How much time can the enterprise / organisation afford to
> wait ?
>
> You need to ensure that the Archived Redo Logs are pushed
> to the other site ASAP (near-synchronous or actually synchronous)
> (that handles requirement a.)
>
> Considering the speed at which Oracle applies Redo Logs (extremely
> fast, much faster than the actual transactions), how long does it take
> to apply the last half-hour / one-hour / four-hours / eight-hours of
> Redo Logs ? Just bringing up the database doesn't mean that the
> disaster recovery scenario is complete. Your network might have
> to switch over. Your client machines may have to be able to reconnect.
> And your users must know what to do.
> Sure, there are companies which cannot afford 5 minutes downtime
> and have redundant networks, automatic failover .... blah blah
> But some organisations might take a day or more to switch over.
> It is not absolutely urgent to apply the Archived Redo Logs as soon
> as they are generated. You can afford to take your tiem to apply
> the Archives while the rest of the organisation tries to catch up with
you.
>
> You could have multiple images of your standby database (that is one
> scenario I propose sometimes -- keep backing up your standby database
> as well, you might want to do a "rollback" of your standby), recoveries
> with different time lags etc.
>
> Another good example of a standby as pointed out by Steve is where
> it is used for "cloning" an environment. You might be happy to have a
> clone that is 4 hours old but you cannot afford to wait the time it takes
> to copy the full production database when you need the clone. Use a
> standby. This could be where you have a very regular need for clones.
>
> A Reporting Instance can be generated from a Standby every day.
>
>
> Hemant K Chitale
> http://hkchital.tripod.com
> "bhtech" <steve_at_bhtech.com> wrote in message
> news:994081554.54156_at_proxy.storm.co.za...
> >
> >
> > Howard J. Rogers wrote:
> >
> > > 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.
> >
> > Standby databases are not meant to be used any particular way. They can
> > be used however they fit into your architecture. I've seen standby
> > databases also used to facilitate database backups, easily create clones
> > of production databases, failover into new hardware, et. al.
> >
> > I have a client that has been using standby databases with custom
software
> > that we wrote for Oracle 7.0 in 1995. One of the first things we built
in
> > was the ability to delay recovery so that we would have a reaction time
to
> > deal with dumb things done by users.
> >
> > We wrote our own mechanism for detecting, copying, and applying redo
logs
> > since standby database functionality didn't exist when we needed it.
This
> > allowed us to delay or suspend recovery of the standby database while
> > still copying archived redo logs from the production database. If you
did
> > need to catch up the standby database, it could be done very quickly
since
> > all of the redo was already on the standby database box.
> >
> >
> >
> > Posted via www.orafocus.com - Focusing on the World of Oracle
> >
>
>
Received on Sat Jul 21 2001 - 16:23:40 CDT
