Re: Questions about applying archive logs

Hi Richard,

Thanks for the help.. However we're using Standard Edition, not EE.. so no dataguard for us.

So I'm back to my original main question.. What is the syntax/technique for taking the latest archive and redo logs and applying against the cold backup files I have on another server..and what is a good way to automatically apply those logs as they come across.

thx.. Allen

ps I will read the dataguard stuff even if we can't use it..

"Richard Foote" <richard.foote_at_bigpond.com> wrote in message news:8zyq9.52488$g9.153346_at_newsfeeds.bigpond.com...
>
> "Hub" <hub_at_houston.rr.NOSPAM.com> wrote in message
> news:NEsq9.125210$8o3.3755846_at_twister.austin.rr.com...
> >
> > Howdy ya'll..
>
> Let me guess. You're from India ;)
>
> I have some archive log questions. Oracle 9i, linux,
> > standard edition.
> >
> > Ok our main prod server spits out archive logs. On a seperate standby
> > server I have copies of all the cold backup files.. tablespace, logs,
> > control, redo, etc.. Every 15 minutes I cron job rsync the archive logs
> to
> > the standby server. What should I do on the standby side to
automatically
> > apply these archive logs to the standby server as they arrive (or soon
> > thereafter)?
>
> OK. Recommendation 1. Lookup the Data Guard Concepts manual and see if
> Oracle's Data Guard (or Standby DB) is the way to go. Based on what you've
> requested to do, I would suggest it is as everything can be nicely
automated
> and protected.
>
> So you need to create the standby DB on your standby server (basically
> copying the database files across, a special standby control file that's
> initially created on the prod server and possibly creating a set of
standby
> redo log files). Then mount the database and put it in managed recovery
mode
> which will make the standby DB applied redo as and when it arrives.
>
> On the Prod DB, the log_archive_dest_n parameters have options that
enables
> Oracle to automatically transport the redo to the standby server via
either
> the ARCH or LGWR processes.
>
> > Then if for some reason we have to switch from the main prod
> > server to the standby one.. what is the appropriate technique/syntax to
> take
> > the latest archive/redo files, apply them to the standby box, bring the
> > database up on the standby server.. etc.. does the main prod server
have
> > to be down to do this or can it still be running?
>
> OK. Recommendation 2. Lookup the Data Guard Concepts manual and the
various
> options you have. You can either perform a graceful switchover which
enables
> you to swap the behaviours of the Prod/Standby database (and very easily
> back again) or you can simply activate the standby DB which converts it to
> the 'Mainman'.
>
> >
> > Also, how can i have this standby database be read-only, updated as the
> > latest archive logs arrive, used for a report server..
>
> OK. Recommendation 3. Lookup the Data Guard Concepts manual and see how
you
> can take the standby DB out of recovery mode and open it as read only. At
> this point, users can log on and execute their queries but of course the
> database is no longer being maintained as such. But that's fine, any
queries
> that only requires historical data and isn't too fussed about having
today's
> data will be as happy as Larry. Then you can kick everyone off and place
the
> standby db back in recovery mode. Note that a Temp LMT is crucial here but
> the Data Guard doco covers all of that.
>
> >
> > Also these archive logs, can I apply them to another database somehow?
> Just
> > pick an archive log file and say "try to apply all of these changes to
> this
> > database"?
>
> Yes. You can create a "clone" database (which you create from the backups
of
> the Prod DB) and use the archive logs created since the backup to get the
> clone as up to date as required. Note the database must be a clone
database,
> it can't just be any database for (I hope) obvious reasons.
>
> My last recommendation. Read up on Data Guard. There's a lot to Standby
DBs
> these days with many options that make what you appear to want to do very
> flexible and automated.
>
> Good Luck
>
> Richard
>
> >
> > thx a bunch.. Hub
> >
> > hub_at_houston.rr.NOSPAM.com
> >
> >
>
>
Received on Mon Oct 14 2002 - 08:17:35 CDT