Monitor recovery of a Data Guard standby database Oracle Database Tips by Donald BurlesonDecember 9, 2015

Monitor Data Guard Recovery Progress on Standby Sites

Determining the progress of the recovery process is essential before switchover to a standby database. Moreover, the recovery progress should be monitored periodically in order to find the lag between the primary database and the standby database.

If the Oracle instance is showing a regular backlog of archived logs required to be applied on the standby database, the recovery process will have to be tuned in order to synchronize it with the primary database.  Otherwise, during the failover operation, it will take longer for the log apply service to catch up before the Oracle instance can be activated.

Recovery Progress on Data Guard Standby Sites

In this section, the use of dynamic views to find the overall recovery progress and the status of various processes involved in recovery will be presented. The following views are particularly important in determining the status of managed recovery:

• v$managed_standby
   

• v$archived_standby
   

• v$archive_dest_status
   

• v$log_history

To find the overall progress of the recovery process on the standby database, v$archive_dest_status on the standby site can be queried to find the last archived log received and applied on this site. The following query, when executed on standby database, will provide this information:

Select
   ARCHIVED_THREAD#,
   ARCHIVED_SEQ#,
   APPLIED_THREAD#,
   APPLIED_SEQ#
From
   V$ARCHIVE_DEST_STATUS;

The following sample output from the query shows the standby database is eight logs behind the primary database:

ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#
---------------- ------------  --------------- ------------
               1           594               1          586

The difference between the ARCHIVED_SEQ# and APPLIED_SEQ# column is the number of logs available on the standby site that need to be applied to synchronize it with the primary database. The above query only shows the difference between logs available and applied on the standby site. There may be a scenario when all the logs from the primary database are not transferred to the standby site. In this case there may be more logs that are required to synchronize the standby database.

The archived logs can be found by comparing the ARCHIVED_SEQ# column from the above output with the last log archived on the primary database. The last archived log on the primary site can be obtained from the SEQUENCE# column of v$log_history. The following query can be executed on the primary database for this purpose:

Select
   max(SEQUENCE#) Latest_Archive_Log
From
   V$LOG_HISTORY;

The v$archived_log view shows details of the progress of the managed recovery process for individual archived logs. The following query can be used to see the status of an individual archived log on the standby site. 'RFS' in the REGISTRAR column shows that these logs are transferred from the primary site by log transfer services.

Select

   THREAD#,
   SEQUENCE#,
   APPLIED,
   REGISTRAR
From
   V$ARCHIVED_LOG;

   THREAD#  SEQUENCE# APP REGISTR
---------- ---------- --- -------
         1        585 YES RFS
         1        586 YES RFS
         1        587 NO  RFS
         1        588 NO  RFS
         1        589 NO  RFS

In the managed recovery operation, there are various processes involved at the standby site. The v$managed_standby view gives the status of these processes. A sample output from the following query will show the status of ARCH, RFS, and MRP process:

Select
   PROCESS, 
   SEQUENCE#,
   STATUS
From
   V$MANAGED_STANDBY;
 


PROCESS  SEQUENCE# STATUS
------- ---------- ------------
ARCH             0 CONNECTED
ARCH             0 CONNECTED
MRP0           595 WAIT_FOR_LOG
RFS            595 ATTACHED
RFS            594 RECEIVING