D Data Guard and Real Application Clusters

D.1.1 Setting Up a Multi-Instance Primary with a Single-Instance Standby

Figure D-1 illustrates a Real Application Clusters database with two primary database instances (a multi-instance primary database) transmitting redo data to a single-instance standby database.

Figure D-1 Transmitting Redo Data from a Multi-Instance Primary Database

Description of "Figure D-1 Transmitting Redo Data from a Multi-Instance Primary Database"

In this case, Instance 1 of the primary database archives redo data to local archived redo log files 1, 2, 3, 4, 5 and transmits the redo data to the standby database destination, while Instance 2 archives redo data to local archived redo log files 32, 33, 34, 35, 36 and transmits the redo data to the same standby database destination. The standby database automatically determines the correct order in which to apply the archived redo log files.

To set up a primary database in a Real Application Clusters environment

Follow the instructions in Chapter 3 (for physical standby database creation) or Chapter 4 (for logical standby database creation) to configure each primary instance.

To set up a single instance standby database

Follow the instructions in Chapter 3 (for physical standby database creation) or Chapter 4 (for logical standby database creation) to define the STANDBY_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT parameters to specify the location of the archived redo log files and standby redo log files.

D.1.2 Setting Up a Multi-Instance Primary with a Multi-Instance Standby

Figure D-2 shows a configuration where the primary and standby databases are in a Real Application Clusters environment. This enables you to separate the redo transport services processing from the log apply services processing on the standby database, thereby improving overall primary and standby database performance.

Figure D-2 Standby Database in Real Application Clusters

Description of "Figure D-2 Standby Database in Real Application Clusters"

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

In a Real Application Clusters environment, any standby instance can receive redo data from the primary database; this is a receiving instance. However, the archived redo log files must ultimately reside on disk devices accessible by the recovery instance. Transferring the standby database archived redo log files from the receiving instance to the recovery instance is achieved using the cross-instance archival operation.

The standby database cross-instance archival operation requires use of standby redo log files as the temporary repository of primary database archived redo log files. Using standby redo log files not only improves standby database performance and reliability, but also allows the cross-instance archival operation to be performed on clusters that do not have a cluster file system. However, because standby redo log files are required for the cross-instance archival operation, the primary database can use either the log writer process (LGWR) or archiver processes (ARCn) to perform the archival operations on the primary database.

When both the primary and standby databases are in a Real Application Clusters configuration, then a single instance of the standby database applies all sets of log files transmitted by the primary instances. In this case, the standby instances that are not applying redo data cannot be in read-only mode while Redo Apply is in progress.

To set up a standby database in a Real Application Clusters environment

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

1. Create the standby redo log files. In a Real Application Clusters environment, the standby redo log files must reside on disk devices shared by all instances. See Section 3.1.3 for more information.

2. On the recovery instance, define the LOCATION attribute of the LOG_ARCHIVE_DEST_1 initialization parameter to archive locally, because cross-instance archiving is not necessary.

3. On the receiving instance, define the SERVICE attribute of the LOG_ARCHIVE_DEST_1 initialization parameter to archive to the recovery instance.

4. Start log apply services on the recovery instance.

To set up a primary database in a Real Application Clusters environment

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

1. On all instances, define the LGWR attribute on the LOG_ARCHIVE_DEST_n parameter to designate that the LGWR process will perform the archival operation.

2. Configure each standby instance to send redo data to the receiving instance by setting the LOG_ARCHIVE_DEST_n parameter to an appropriate value.

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

D.2.1 Format for Archived Redo Log Filenames

The format for archived redo log filenames is in the form of log_%parameter, where %parameter can include one or more of the parameters in Table D-1.

For example:

LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc

The thread parameters %t or %T are mandatory for Real Application Clusters to uniquely identify the archived redo log files with the LOG_ARCHIVE_FORMAT parameter. See Section 5.7.1 for more information about storage locations for archived redo log files.

D.2.2 Archive Destination Quotas

You can specify the amount of physical storage on a disk device to be available for an archiving destination using the QUOTA_SIZE attribute of the LOG_ARCHIVE_DEST_n initialization parameter. An archive destination can be designated as being able to occupy all or some portion of the physical disk represented by the destination. For example, in a Real Application Clusters environment, a physical disk device can be shared by two or more separate nodes. As there is no cross-instance initialization parameter knowledge, none of the Real Application Clusters nodes is aware that the physical disk device is shared with other instances. This leads to substantial problems when the destination disk device becomes full; the error is not detected until every instance tries to archive to the already full device. This affects database availability.

D.2.3 Data Protection Modes

In a Real Application Clusters configuration when running in either maximum protection or maximum availability mode, any instance that loses connectivity with a standby destination will cause all other instances to stop sending data to that destination (this maintains the integrity of the data that has been transmitted to that destination).

When the failed standby destination comes back up, Data Guard runs the site in resynchronization mode until no gaps remain. Then, the standby destination can participate in the Data Guard configuration again.

The following list describes the behavior of the protection modes in Real Application Clusters environments:

• Maximum protection configuration

  If a lost destination is the last participating LGWR SYNC destination, the instance loses connectivity and will be shut down. Other instances in a Real Application Clusters configuration that still have connectivity to the standby destinations will recover the lost instance and continue sending to their standby destinations. Only when every instance in a Real Application Clusters configuration loses connectivity to the last standby destination will the primary database be shut down.

D.2.4 Role Transitions

This section contains the following topics:

• Switchovers

• Failovers

D.3.1 Switchover Fails in a Real Application Clusters Configuration

When your database is using Real Application Clusters, active instances prevent a switchover from being performed. When other instances are active, an attempt to switch over fails with the following error message:

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY; 
ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY * 
ORA-01105: mount is incompatible with mounts by other instances 

Action: Query the GV$INSTANCE view as follows to determine which instances are causing the problem:

SQL> SELECT INSTANCE_NAME, HOST_NAME FROM GV$INSTANCE 
  2> WHERE INST_ID <> (SELECT INSTANCE_NUMBER FROM V$INSTANCE);
INSTANCE_NAME HOST_NAME 
------------- --------- 
INST2         standby2 

In the previous example, the identified instance must be manually shut down before the switchover can proceed. You can connect to the identified instance from your instance and issue the SHUTDOWN statement remotely, for example:

SQL> CONNECT SYS/CHANGE_ON_INSTALL@standby2 AS SYSDBA 
SQL> SHUTDOWN;
SQL> EXIT

D.3.2 Avoiding Downtime in Real Application Clusters During a Network Outage

If you configured Data Guard to support a primary database in a Real Application Clusters environment and the primary database is running in maximum protection mode, a network outage between the primary database and all of its standby databases will disable the primary database until the network connection is restored. The maximum protection mode dictates that if the last standby database becomes unavailable, processing halts on the primary database.

If you expect the network to be down for an extended period of time, consider changing the primary database to run in either the maximum availability or the maximum performance mode until network connectivity is restored. If you change the primary database to maximum availability mode, it is possible for there to be a lag between the primary and standby databases, but you gain the ability to use the primary database until the network problem is resolved.

If you choose to change the primary database to the maximum availability mode, it is important to use the following procedures to prevent damage to your data.

The following steps describe what to do if the network goes down and you want to change the protection mode for the Real Application Clusters configuration. The example assumes you are using a server parameter file (SPFILE), not a PFILE.

1. At this point all Real Application Clusters primary instances are shut down. Issue the STARTUP MOUNT command to start one instance:

   STARTUP MOUNT;
   

2. Follow the instructions in Section 5.6.2 (or, if you are using the broker, see Oracle Data Guard Broker) to change the mode from the maximum protection mode to either maximum availability or maximum performance mode. For example, the following statement sets the maximum availability protection mode:

   ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE AVAILABILITY;
   

3. Open the Real Application Clusters primary database for general access.

Later, when the network comes back up, perform the following steps to revert to the maximum protection mode:

1. Shut down all instances of the Real Application Clusters primary database.

2. Mount a single instance of the Real Application Clusters primary database, without opening it for general access.

3. Change mode on the Real Application Clusters primary database from its current (maximum availability or maximum performance) mode to the maximum protection mode.

4. Open the Real Application Clusters primary database for general access.