Re: Help: Standby database config.

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

1. Do you have the transactions available at the standby / remote site ?
2. 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 Mon Jul 02 2001 - 08:53:02 CDT