Monitoring Log Apply Services For Physical Standby Databases

Monitoring Log Apply Services for Physical Standby Databases To monitor the status of archived redo logs and obtain information on log apply services on a physical standby database, query the fixed views described in this section. You can also monitor the standby database using Data Guard Manager. See Also: Appendix A, "Troubleshooting the Standby Database" This section contains the following topics: • • • • •

Accessing the V$MANAGED_STANDBY Fixed View Accessing the V$ARCHIVE_DEST_STATUS Fixed View Accessing the V$ARCHIVED_LOG Fixed View Accessing the V$LOG_HISTORY Fixed View Accessing the V$DATAGUARD_STATUS Fixed View See Also: Chapter 14 for complete reference information on the views named in the preceding list

6.5.1 Accessing the V$MANAGED_STANDBY Fixed View Query the physical standby database to monitor log apply and log transport services activity at the standby site. SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS 2> FROM V$MANAGED_STANDBY; PROCESS ------RFS MRP0

STATUS -----------ATTACHED APPLYING_LOG

THREAD# ---------1 1

SEQUENCE# ---------947 946

BLOCK# ---------72 10

BLOCKS ---------72 72

The previous query output shows that an RFS process has completed the archiving of redo log file sequence number 947. The output also shows a managed recovery operation that is actively applying archived redo log sequence number 946. The recovery operation is currently recovering block number 10 of the 72-block archived redo log.

6.5.2 Accessing the V$ARCHIVE_DEST_STATUS Fixed View To quickly determine the level of synchronization for the standby database, issue the following query on the physical standby database:

SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS; ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# ---------------- ------------- --------------- -----------1 947 1 945

The previous query output shows that the standby database is two archived logs behind in applying the redo logs received from the primary database. This might indicate that a single recovery process is unable to keep up with the volume of archived redo logs being received. Using the PARALLEL option might be a solution.

6.5.3 Accessing the V$ARCHIVED_LOG Fixed View The V$ARCHIVED_LOG fixed view on the physical standby database shows all the archived redo logs received from the primary database. This view is only useful after the standby site starts receiving logs, because before that time the view is populated by old archived log records generated from the primary control file. For example, you can execute the following SQL*Plus statement: SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#, 2> NEXT_CHANGE# FROM V$ARCHIVED_LOG; REGISTRAR --------RFS RFS RFS

CREATOR ------ARCH ARCH ARCH

THREAD# ---------1 1 1

SEQUENCE# ---------945 946 947

FIRST_CHANGE# ------------74651 74739 74772

NEXT_CHANGE# -----------74739 74772 74774

The previous query output shows three archived redo logs received from the primary database. See Also: V$ARCHIVED_LOG in Chapter 14

6.5.4 Accessing the V$LOG_HISTORY Fixed View Query the V$LOG_HISTORY fixed view on the physical standby database to show all the archived redo logs that were applied: SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# 2> FROM V$LOG_HISTORY; THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# ---------- ---------- ------------- -----------1 945 74651 74739

The previous query output shows that the most recently applied archived redo log was sequence number 945.

6.5.5 Accessing the V$DATAGUARD_STATUS Fixed View The V$DATAGUARD_STATUS fixed view displays events that would typically be triggered by any message to the alert log or server process trace files. The following example shows output from the V$DATAGUARD_STATUS view on a primary database: SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE ------------------------------------------------------------------------------ARC0: Archival started ARC1: Archival started Archivelog destination LOG_ARCHIVE_DEST_2 validated for no-data-loss recovery Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2' ARCH: Transmitting activation ID 0 LGWR: Completed archiving log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2' LGWR: Transmitting activation ID 6877c1fe LGWR: Beginning to archive log 4 thread 1 sequence 12 ARC0: Evaluating archive log 3 thread 1 sequence 11 ARC0: Archive destination LOG_ARCHIVE_DEST_2: Previously completed ARC0: Beginning to archive log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/arch/arch_1_11.arc' ARC0: Completed archiving log 3 thread 1 sequence 11 ARC1: Transmitting activation ID 6877c1fe 15 rows selected.

The following example shows the contents of the V$DATAGUARD_STATUS view on a physical standby database: SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE ------------------------------------------------------------------------------ARC0: Archival started ARC1: Archival started RFS: Successfully opened standby logfile 6: '/oracle/dbs/sorl2.log'

ARC1: Evaluating archive log 6 thread 1 sequence 11 ARC1: Beginning to archive log 6 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/arch/arch_1_11.arc' ARC1: Completed archiving log 6 thread 1 sequence 11 RFS: Successfully opened standby logfile 5: '/oracle/dbs/sorl1.log' Attempt to start background Managed Standby Recovery process Media Recovery Log /oracle/arch/arch_1_9.arc 10 rows selected.

See Also: V$DATAGUARD_STATUS in Chapter 14