Re: Data Guard - Checking Current Status

From: Stefan Koehler <contact_at_soocs.de>
Date: Tue, 30 Dec 2014 10:31:05 +0100 (CET)
Message-ID: <500102266.7349.1419931865118.open-xchange_at_app09.ox.hosteurope.de>



Hi Michael,
i hope you are using DGMGRL and if not i highly recommend it :-))

In case of that Oracle 12c has a new DGMGRL command called "VALIDATE DATABASE" ( http://docs.oracle.com/database/121/DGBKR/dgmgrl.htm#DGBKR3877 ). It includes information about the transfer and apply lag (not SCN based, but time based) and does several checks before a fail over (or switch over).

You can also dump the current standby log and check for the latest committed (and received) data (OP code 5.4 = commit record) that should be available after fail over including rolling forward and rolling back. You can also get the latest received SCN from that redo dump (maybe for manual verification). However i can not see any great benefit from that information, beside you want to validate the redo entry with the corresponding block content (rba) right after the fail over.

Best Regards
Stefan Koehler

Freelance Oracle performance consultant and researcher Homepage: http://www.soocs.de
Twitter: _at_OracleSK

> Michael Cunningham <napacunningham_at_gmail.com> hat am 30. Dezember 2014 um 00:03 geschrieben:
>
> Hello, we are looking for the best way to check if the standby is up-to-date (or at least how up-to-date it really is) when it is necessary to fail
> over.
>
> Oracle 12cR1 on Linux
>
> The scenario is the primary server has crashed and we are faced with finding out how up-to-date the standby is. It would be nice to know the scn
> if possible.
>
> We are configured with standby redo logs in Maximum Performance mode. If this is not enough info please let me know.
>
> P.S. We are currently querying v$dataguard_stats and we can see the datum info, but we are curious if there is better info we could/should be
> looking at.
>
> --
> Michael Cunningham

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Dec 30 2014 - 10:31:05 CET

Original text of this message