Re: Question re DataGuard
- From: Paul Moen <moen@xxxxxxxxxxx>
- To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 18 Mar 2008 22:41:06 +1100
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@xxxxxxxxxxx> 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@xxxxxxxxxxx
(530) 754-6208
--
//www.freelists.org/webpage/oracle-l
--
//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@xxxxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
Other related posts:
