RE: recover standby database failure
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <finn.oracledba@xxxxxxxxx>, <mike.mitchell@xxxxxxxxxxxxxxx>
- Date: Thu, 15 May 2008 11:24:29 -0400
I think Finn's analysis of your situation is correct, but there is no real
need to cancel recovery unless you want to test your ability to open the
standby. Just wait until the next archive arrives to hit return. When you
get tired of sitting in front of a terminal you figure out a system for
detecting the complete arrival of the next archive, decide whether to inject
a delay between the arrival of the archived redo log and the application to
recovery to balance speed of recovery with the potential to intercept a
serious logical error executed against the primary before it is applied to
the standby.
Most likely the operation of opening a standby manually managed as described
is destructive unless you cancel recovery, shut down, copy clone and do a
startup rename resetlogs on the clone to test if you have in fact correctly
manually managed a "roll your own" standby. Then if the open is successful
you probably need to run a lot of reports to make sure the recovery test was
actually successful rather than only apparently successful. Why I might not
be satisfied unless all the weekly and month end reports appeared to be
perfect! And who better to evaluate whether the reports look correct than
the folks who otherwise might be running those reports on the production
primary database?
Since manually managing a recovery standby is error prone, I do recommend
executing this copy clone open frequently. The renamed database can be used
as a "frozen reporting database" while recovery is resumed on the standby of
the original name. If you're rolling your own rather than using Oracle's
software to manage a standby, there several things you can do to destroy the
validity of the standby (such as unlogged actions on the "primary"). Of
course if you regularly test your standby by doing a clone/rename/open
resetlogs, that normally will decouple you from a simultaneous actual
problem with your "primary." Over time you can do the math of frequency of
errors detected with the standby process versus frequency of problems of the
"primary" to determine your risk and ask management whether they want to
spend more money to reduce that risk.
This isn't a bad way to test that your hot backup procedures are correct,
and you just happen to be using a different machine to repetitively test
recovery. Of course if you're using this for more than a test there may be
license issues. And of course there is also the question of whether you
might be better off with RMAN.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Finn Jorgensen
Sent: Wednesday, May 14, 2008 5:26 PM
To: mike.mitchell@xxxxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: recover standby database failure
Michael,
If I'm understanding you correctly then this is normal behaviour. It
means the database has been recovered up until the most recent
available archive log. I haven't set up a manual standby db since
Oracle 7.1 so I'm not sure about this, but I would think at this point
you just type "cancel", wait for more archive logs to arrive and then
"recover automatic standby database;" again. Repeat.
Thanks,
Finn
<snip>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
