RE: recover standby database failure

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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Finn Jorgensen
Sent: Wednesday, May 14, 2008 5:26 PM
To: mike.mitchell_at_etouchpoint.com
Cc: oracle-l_at_freelists.org
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>

--
http://www.freelists.org/webpage/oracle-l