Re: Help: Standby database config.

"Howard J. Rogers" <howardjr_at_www.com> wrote in message news:3b418c64_at_news.iprimus.com.au...
> Well, I'm glad you're both happy.

Uh huh...

>
> 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.

I don't intend to avoid repeating the error, I just want a decent shot of getting the data back without having to restore a backup.

Say a user accidentally deleted some information for a certain customer. It was caught pretty quickly and we were able to get the information
out of the standby database. This data was used to correct the error in the production database, and work continued.

No data lost... If the user deleted data a week ago, then we'd have to recover a backup elsewhere to a point-in-time before the data was accidentally
deleted. It's nice to avoid going through all that when possible.

>
> 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.
It is true that you can't selectively skip applying redo to a database. But heck, that's just the way Oracle works.

>
> 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'.

I believe that you proposed the idea of throwing away all data after a user error.
I certainly didn't because it's just not acceptible in the environments I support.

>
> 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.

I'm not worried about stale databases. I'll still have all of the archived redo
logs on disk waiting to be applied to the standby database. Even though recovery is suspended, the archived redo logs are copied to the machine the standby database resides on as they are generated.

>
> 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:52 CDT