Monitoring Events That Affect the Standby Database

To prevent possible problems, you should be aware of events that affect a standby database and learn how to monitor them. Most changes to a primary database are automatically propagated to a standby database through archived redo logs and so require no user intervention. Nevertheless, some changes to a primary database require manual intervention at the standby site.

This section contains the following topics: ■ Dynamic Performance Views (Fixed Views) ■ Monitoring the Primary and Standby Databases

■ Determining Which Logs Have Been Applied to the Standby Database ■ Determining Which Logs Have Not Been Received by the Standby Site

5.7.1 Dynamic Performance Views (Fixed Views)

The Oracle database server contains a set of underlying views that are maintained by the server. These views are often called dynamic performance views because they are continuously updated while a database is open and in use, and their contents relate primarily to performance. These views are also called fixed views, because they cannot be altered or removed by the database administrator. These view names are prefixed with either V$ or GV$, for example, V$ARCHIVE_ DEST or GV$ARCHIVE_DEST.

Standard dynamic performance views (V$ fixed views) store information on the local instance. In contrast, global dynamic performance views (GV$ fixed views), store information on all open instances. Each V$ fixed view has a corresponding GV$ fixed view.

The following fixed views contain useful information for monitoring the Data Guard environment:

■ V$ARCHIVE_DEST

Describes the archived redo log destinations associated with the current instance on the primary site. You can use this view to find out the current settings of your archived redo log destinations.

See Also: Oracle9i Recovery Manager User’s Guide for more details

about RMAN backup and recovery of a primary database using a standby database and Section 6.12 for a relevant scenario

Monitoring Events That Affect the Standby Database

■ V$ARCHIVE_DEST_STATUS

This view, an extension of the V$ARCHIVE_DEST view, displays runtime and configuration information for the archived redo log destinations. You can use this view to determine the progress of archiving to each destination. It also shows the current status of the archive destination.

■ V$ARCHIVE_GAP

Provides information about archive gaps. You can use this view to find out the current archive gap that is blocking recovery.

■ V$ARCHIVED_LOG

Displays archived redo log information from the control file, including archived log names. This view gives you information on which log has been archived to where on your primary database. On the primary database, this view describes the logs archived to both the local and remote destinations. On a standby database, this view provides information about the logs archived to this standby database. You can use this fixed view to help you to track archiving progress to the standby site.

■ V$DATABASE

Contains database information from the control file. You can use this view to quickly find out if your database is a primary or a standby database, as well as its switchover status.

■ V$DATAFILE

Contains datafile information from the control file. You can query this fixed view to verify that the standby datafiles are correctly renamed after your standby database is instantiated.

■ V$LOG

Contains log file information from the online redo logs. You can use the information about the current online log on the primary database from this view as a reference point to determine how far behind your standby database is in receiving and applying logs.

■ V$LOGFILE

Contains information about the online redo logs and standby redo logs.

See Also: Table 6–1 and Section 6.3.2 for information on renaming standby datafiles when instantiating a standby database

Monitoring Events That Affect the Standby Database

■ V$LOG_HISTORY

Contains log history information from the control file, including a record of the latest archived log that was applied.

■ V$MANAGED_STANDBY

Displays current and status information for some Oracle database server processes related to Data Guard. This view can show both foreground and background processes. You can use this view to monitor the various Data Guard recovery and archiving processes.

■ V$STANDBY_LOG

Provides information about the standby redo logs. Standby redo logs are similar to online redo logs, but they are only used on a standby database receiving logs from the primary database using the log writer process.

5.7.2 Monitoring the Primary and Standby Databases

Table 5–4 indicates whether a primary database event is automatically administered by log transport services and log apply services or requires additional intervention by the database administrator (DBA) to be propagated to the standby database. It also describes how to respond to these events.

See Also: Chapter 10, "Fixed Views" and the Oracle9i Database

Monitoring Events That Affect the Standby Database

Table 5–4 Troubleshooting Primary Database Events Primary

Database Event

Primary Site Problem Report Location

Standby Site Problem

Report Location Recommended Response Archiving errors ■ ERROR column of

V$ARCHIVE_DEST view ■ Alert log ■ ARCHIVED column of V$LOG view ■ Archiving trace files

Remote file server (RFS) process trace file

Fix the problem reported in the alert log file or trace file and resume archiving to the destination. If the problem persists or archiving performance is degraded, you can create scripts to send the archived redo logs.

Thread events ■ Alert log ■ V$THREAD view

Alert log Thread events are automatically propagated through archived logs, so no extra action is necessary. Redo log changes Alert log

V$LOG view and

STATUS column of

V$LOGFILE view

Alert log Redo log changes do not affect the standby database unless a redo log is cleared or lost. In these cases, you must rebuild the standby database. See Section 2.3.

Pre-clear the logs on the standby database with the ALTER DATABASE CLEAR LOGFILE statement. See

Section 5.8.9. Issue aCREATE

CONTROLFILE

statement

Alert log Database functions

normally until it encounters redo depending on any parameter changes.

Re-create the standby control file. See Section 5.8.8.

Re-create the standby database if the primary database is opened with the

RESETLOGS option. See Section 2.3. Managed

recovery performed

Alert log Alert log Re-create the standby database if the

RESETLOGS option is utilized. See

Section 2.3. Tablespace status changes (made read/write or read-only, placed online or offline) ■ DBA_ TABLESPACES view ■ Alert log

■ Verify that all datafiles are online.

■ V$RECOVER_FILE

view

Status changes are automatically propagated, so no response is necessary. Datafiles remain online.