Re: Question re DataGuard

Hey Bill,

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

Paul

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
> http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_SwitchoverFailoverBestPractices.pdf
>
> Oracle 10g Release 2, Data Guard Fast-Start Failover best practices
> (automatic database failover)
> http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_FastStartFailoverBestPractices.pdf
>
> Oracle 10g Release 2, Client Failover Best Practices
> http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_ClientFailoverBestPractices.pdf
>
> Ray
>
> 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-l