D Oracle Data Guard and Oracle Real Application Clusters

An Oracle Data Guard configuration can consist of any combination of single-instance and Oracle Real Application Clusters (Oracle RAC) multiple-instance databases.

This appendix summarizes the configuration requirements and considerations that apply when using Oracle Data Guard with Oracle RAC databases. It contains the following sections:

• Configuring Standby Databases in an Oracle RAC Environment

• Configuration Considerations in an Oracle RAC Environment

Configuring Standby Databases in an Oracle RAC Environment

You can configure a standby database to protect a primary database using Oracle Real Application Clusters (Oracle RAC).

The following table describes the possible combinations of instances in the primary and standby databases:

Instance Combinations	Single-Instance Standby Database	Multi-Instance Standby Database
Single-instance primary database	Yes	Yes
Multi-instance primary database	Yes	Yes

In each scenario, each instance of the primary database transmits its redo data to an instance of the standby database. As of Oracle Database 12c release 2 (12.2.0.1) you can also perform multi-instance redo apply.

Setting Up Multi-Instance Redo Apply

As of Oracle Database 12c Release 2 (12.2.0.1), a new INSTANCES [ ALL | integer] clause is available on the SQL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE command.

To use In-Memory Column Store with multi-instance redo apply in an Active Data Guard environment, set the enable_imc_with_mira initialization parameter to TRUE.

The following restrictions apply:

• The clause is applicable only for Oracle Real Application Clusters (Oracle RAC) or Oracle RAC One Node databases.

• You cannot use multi-instance redo apply when you enable STANDBY NOLOGGING FOR DATA AVAILABILITY or STANDBY NOLOGGING FOR LOAD PERFORMANCE on the primary database.

The ALL option causes redo apply to run on all instances in an Oracle RAC standby database that are in an open or mounted state at the time recovery is started. All instances must be in the same state — either open or mounted. A mix of states is not allowed.

The integer option restricts the number of instances that redo apply uses to the number you specify. For integer, specify an integer value from 1 to the number of instances in the standby database. The database chooses the instances on which to perform Redo Apply; you cannot specify particular instances.

The V$RECOVERY_PROGRESS view is only populated on the instance where recovery was started (where the MRP0 process resides).

If you omit the INSTANCES clause, then recovery happens on only one instance where the command was issued.

Because recovery processes ship redo among instances, redo apply performance is directly related to network bandwidth and latency.

Setting Up a Multi-Instance Primary with a Single-Instance Standby

This figure illustrates an Oracle RAC 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.

Although Figure D-1 does not show standby redo logs, it is a best practice to configure standby redo logs at the standby for both instances of the primary. The redo from the primary online redo log files at Instance 1 and Instance 2 would then be received first in the standby redo logs for Instance 1 and Instance 2, respectively, and then archived.

To Configure a Primary Database in an Oracle RAC Environment

Before you create a standby database you must first ensure the primary database is properly configured. To do so, you must perform some preparatory steps, after which the database is prepared to serve as the primary database for one or more standby databases.

To Configure a Single Instance Standby Database

To specify the location of the archived redo log files and standby redo log files, define the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_FORMAT parameters.

See Also:

• Managing Standby Redo Logs for more information about standby redo logs

• Creating a Physical Standby Database for information about configuring a primary database when creating a physical standby database.

• Creating a Logical Standby Database for information about configuring a primary database when creating a logical standby database.

Setting Up Oracle RAC Primary and Standby Databases

An Oracle RAC primary database must be set up to send redo data to an Oracle RAC standby database, and an Oracle RAC standby database must be set up to receive redo data.

Configuring an Oracle RAC Standby Database to Receive Redo Data

These steps describe how to configure an Oracle RAC standby database to receive redo data from a primary database.

1. Create a standby redo log on the standby database. The redo log files in the standby redo log must reside in a location that can be accessed by all of the standby database instances, such as on a cluster file system or Oracle ASM instance. See Managing Standby Redo Logs for more information about creating a standby redo log.
2. Configure standby redo log archival on each standby database instance. The standby redo log must be archived to a location that can be accessed by all of the standby database instances, and every standby database instance must be configured to archive the standby redo log to the same location.

Configuring an Oracle RAC Primary Database to Send Redo Data

Configure each instance of the Oracle RAC primary database to send its redo data to the Oracle RAC standby database. These are the best practices that Oracle recommends you follow when you configure an Oracle RAC primary database to send redo data to an Oracle RAC standby database.

1. Use the same LOG_ARCHIVE_DEST_n parameter on each primary database instance to send redo data to a given standby database.

2. Set the SERVICE attribute of each LOG_ARCHIVE_DEST_n parameter that corresponds to a given standby database to the same net service name.

3. The net service name should resolve to an Oracle Net connect descriptor that contains an address list, and that address list should contain connection data for each standby database instance.

Configuring an Oracle Database to Send Redo Data describes how to configure an Oracle database instance to send redo data to another database.

Configuration Considerations in an Oracle RAC Environment

Oracle Real Application Clusters (Oracle RAC) have specific Oracle Data Guard configuration requirements regarding the format for archived redo log filenames, and for data protection modes.

See the following topics:

• Format for Archived Redo Log Filenames

• Data Protection Modes

Format for Archived Redo Log Filenames

The format for archived redo log filenames is in the form of log_%parameter.

The %parameter can include one or more of the parameters in Table D-1.

Table D-1 Directives for the LOG_ARCHIVE_FORMAT Initialization Parameter

Directives	Description
%a	Database activation ID.
%A	Database activation ID, zero filled.
%d	Database ID.
%D	Database ID, zero filled.
%t	Instance thread number.
%T	Instance thread number, zero filled.
%s	Log file sequence number.
%S	Log file sequence number, zero filled.
%r	Resetlogs ID.
%R	Resetlogs ID, zero filled.

For example:

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

The thread parameters %t or %T are mandatory for Oracle RAC to uniquely identify the archived redo log files with the LOG_ARCHIVE_FORMAT parameter.

Data Protection Modes

If any instance of an Oracle RAC primary database loses connectivity with a standby database, all other primary database instances stop sending redo to the standby database for the number of seconds specified on the LOG_ARCHIVE_DEST_n REOPEN attribute, after which all primary database instances attempt to reconnect to the standby database.

The following list describes the behavior of the protection modes in Oracle RAC environments:

• Maximum protection configuration

  If a lost destination is the last participating SYNC destination, then the instance loses connectivity and is shut down. Other instances in an Oracle RAC configuration that still have connectivity to the standby destinations recover the lost instance and continue sending redo to their standby destinations. Only when every instance in an Oracle RAC configuration loses connectivity to the last standby destination is the primary database shut down.

• Maximum availability and maximum performance configurations

  Other instances in an Oracle RAC configuration that still have connectivity to the standby destination recover the lost instance and continue sending redo to their standby destinations. When every instance in an Oracle RAC configuration loses connectivity to the standby destination, the primary database continues operation in maximum performance mode. The maximum performance mode ensures very minimal data loss except when the entire standby fails.

  The maximum availability protection mode ensures zero data loss except in the case of certain double faults, such as failure of the primary database after the failure of all standby databases.