Re: Question re DataGuard
Date: Tue, 18 Mar 2008 22:41:06 +1100
Here are my answers.
BTW, I highly recommend you read those PDFs that Ray linked.
The managed recovery process (MRP0) does not persist through a database restart. You will need to restart with the command again. sql> recover managed standby database disconnect;
If you need to shutdown the standby database use
sql> recover managed standby database cancel;
The recovery of the database does persist, in that like every Oracle database it has its sequence# to determine where it got to and where to begin again.
There are bunch of v$ views for monitoring from primary or standby depending on the version
you can watch the standby progress using (MRP0 process will show what it is doing)
select * from v$managed_standby;
The dataguard section of the manual has the rest of the views, plus some troubleshooting tips.
Don't have a non-production standby handy atm, however I think Oracle will just flag an error and just continue as before, something along the lines of "recovery already started"?
I have written a bunch of articles on standbys at http://www.pythian.com/blogs This doesn't make me anymore of an expert, I just work with standbys as many of our clients use them for redundancy and also as a database to run backups from. I just post on the stuff I discover.
Hope this helps
Ray Feighery wrote:
> Hello Bill
> The last time I set this up, I used the Data Guard Broker (dgmgrl) and
> found it very easy to use, but I assume the results will be the same.
> "does the managed recovery process persist through a restart of the
> standby database"
> Yes, as long as you don't open the standby database. One problem can
> occur if you use the standard dbstart scripts to restart the database
> for example on server reboot. You should only mount (not open) the
> standby database.
> "Is there a way other than querying the v$archived_log view to
> determine if the managed recovery process is in fact running"
> Just force a logfile switch and check the alert log of the standby
> database. You will see the log being applied.
> "Lastly, what are the ramification, if any, of issuing the command if
> the managed recovery process has already been started."
> I don't think it has any ramifications, but I haven't tested this.
> Some useful links for you:
> Oracle10g Release 2, Data Guard Switchover and Failover best practices
> Oracle 10g Release 2, Data Guard Fast-Start Failover best practices
> (automatic database failover)
> Oracle 10g Release 2, Client Failover Best Practices
> On 18/03/2008, William Wagman <wjwagman_at_ucdavis.edu> wrote:
>> Greetings, >> >> I am new to Data Guard. I'm running Oracle 10.2.0.3.0 EE on 64-bit >> Windows Server 2003. I understand that the command >> >> SQL> alter database recover managed standby database disconnect; >> >> begins the managed recovery process when the standby is first created. >> My question, does the managed recovery process persist through a restart >> of the standby database? I am assuming it does but don't know how to >> determine that. That is my second question, Is there a way other than >> querying the v$archived_log view to determine if the managed recovery >> process is in fact running? Lastly, what are the ramification, if any, >> of issuing the command if the managed recovery process has already been >> started. I just restarted the standby database (unfortunately I issued >> the command before testing the status of the archived logs, I suppose I >> could do it again) at which time I issued the command and the response >> was database altered. I haven't really been able to find an answer to >> this question anywhere. >> >> Thanks in advance. >> >> Bill Wagman >> Univ. of California at Davis >> IET Campus Data Center >> wjwagman_at_ucdavis.edu >> (530) 754-6208 >> >> >> -- >> http://www.freelists.org/webpage/oracle-l >> >> >>
-- Paul Moen The Pythian Group Inc (Australia) Ph: (work) +61 2 9844 5431 - preferred Ph: (mob) +61 415 926140 IM: (AIM,Y!,MSN) pythianmoen email: moen_at_pythian.com -- http://www.freelists.org/webpage/oracle-lReceived on Tue Mar 18 2008 - 06:41:06 CDT