D
Standby Database Real Application Cluster Support

Oracle9i provides the ability to perform true database archival from a primary database to a standby database when both databases reside on a Real Application Cluster. This allows you to separate the log transport services processing from the log apply services processing on the standby database, thereby improving overall primary and standby database performance. Figure D-1 illustrates a standby database configuration on a Real Application Cluster.

Figure D-1 Real Application Cluster Standby Database

Text description of the illustration rac_arch.gif

In Figure D-1, the numbers within circles indicate local connections and the numbers within boxes indicate remote connections.

When you use the standby database on a Real Application Cluster, any instance can receive archived logs from the primary database; this is the receiving instance. However, the archived logs must ultimately reside on disk devices accessible by the node on which the managed recovery operation is performed; this is the recovery instance. Transferring the standby database archived logs from the receiving instance to the recovery instance is achieved using the cross-instance archival operation, performed on the standby database.

See Also: Section 5.9.1

The standby database cross-instance archival operation requires use of standby redo logs as the temporary repository of primary database archived logs. Using the standby redo logs not only improves standby database performance and reliability, but also allows the cross-instance archival operation to be performed. However, because standby redo logs are required for the cross-instance archival operation, the primary database must use the log writer process (LGWR) to perform the primary database archival operation.

To set up a standby database in a Real Application Cluster environment:

Perform the following steps to set up log transport services on the standby database:

1. Create the standby redo logs. In a Real Application Cluster environment, the standby redo logs must reside on disk devices shared by all instances, such as raw devices.

2. On the recovery instance where the managed recovery process (MRP) is to operate, define the archived log destination to archive locally, because cross-instance archival is not necessary. This is accomplished using the LOCATION attribute of the LOG_ARCHIVE_DEST_1 initialization parameter.

   Note: Unlike a primary database, a standby database is not required to have a local archived log destination.

3. On the receiving instance, define the archived log destination to archive to the node where the MRP is to operate. This is accomplished using the SERVICE attribute of the LOG_ARCHIVE_DEST_1 initialization parameter.

4. Start the ARCn process on all standby database instances.

5. Start the MRP on the recovery instance.

To set up a primary database in a Real Application Cluster environment:

Perform the following steps to set up log transport services on the primary database:

1. On all instances, designate the LGWR process to perform the archival operation.

2. Designate the standby database as the receiving node. This is accomplished using the SERVICE attribute of the LOG_ARCHIVE_DEST_n initialization parameter.

Ideally, each primary database instance should archive to a corresponding standby database instance. However, this is not required.