RE: recover standby database failure
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.
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
Subject: Re: recover standby database failure
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.