Configure Dataguard for a RAC Cluster

This document describes the different steps to follow to set up a standby database in standalone using Oracle dataguard, with production site set up with Oracle RAC cluster database.

The DR configuration assumes certain installations and configurations have already been completed, including:

  • Installation of the operating systems for the various database servers at both sites
  • Configuration of the Grid Infrastructure and ASM storage at both sites
  • Installation of the RAC Cluster database at the primary site
  • Installation of ORACLE_HOME at the DR site (for a standalone database on DR)
  • Existing network connection between the primary and secondary sites

Below is a summary of the main configuration parameters for the primary and secondary databases:

RAC Cluster nodes and ASM informations

Replication architecture

A. PRIMARY DATABASE PREPARATION

The production environment must be correctly configured to operate in Data Guard mode:

Enable Force Logging.

It is necessary to force the logging of actions even for objects where the NOLOGGING clause is enabled. This clause prevents the generation of records in the redo log for DDL queries. Replication is based on information from the redo logs archived in the archive files.

Modify the init file parameters

Below are the important parameters to consider for replication in the primary site’s init file:

Modify database parameters like below :

Enable Archivelog mode

Verify that the primary database is in archive log mode; if not, enable archiving for the cluster as shown below:

Disable archive mode from any node (ex: node1)

Stop all instances

Mount instance 1 and enable archiving

Re-enable cluster mode

Stop the instance

Restart all instances

Restart all services (if needed). Exple for service SERV :

Create Standby Redo Logs (SLRs)

It is necessary to create redo log files for the standby database on both the primary and secondary databases. The number of SLR groups to create must be greater than or equal to (threads) * (groups per thread + 1).

In our case: Threads = 2, Groups per thread = 2, so a minimum of 2 * (2 + 1) = 6 SLRs must be created.

Therefore, 6 SLR groups will be created, each with a size of 3 GB.
Note: Do not duplicate members within the SLR groups to be created.

To check actual prod redo groups and members, execute :

Create destination for SLRs in ASM :

Add SLRs for thread 1

Add SLRs for thread 2

Re-enable standby_file_management

Note: The redo and SLR files on the DR will be automatically created using the log_file_name_convert parameter in the DR initialization file.

Listener and tnsnames.ora

To avoid listener errors with the SCAN Listener, which redirects connections based on server load, it is recommended to create a local listener that points to one of the nodes. A common error with the SCAN Listener during RMAN duplication is copying the password file from the primary site to the DR site.

Create the LISTENER_N2 listener on the node-clu2 node, which listens on port 1530, with the following content in the file $ORACLE_HOME/network/admin/listener.ora.

The following should be done on Production node 2 :

Add these entries in TNS files on DR and node 2:

B. PREPARING THE SECONDARY DATABASE

Password File
Create the password file for the secondary database by either:

  • Copying the password file from the primary database

Use scp to copy the password file from $ORACLE_HOME/dbs on PROD to DR:

  • Creating the password file
    Use the orapwd command to create the file in $ORACLE_HOME/dbs:

Create pfile for DR

Create a file (exple initdup.ora) with entries similar to PROD but with some DR specs in italics:

Listener Configuration

Create a listener (here LISTENER_DG) as shown below, in the listener.ora file. Then start the listener with the lsnrctl command.

Create the necessary directories
Create the destination folders for audit files:

Prepare the script for duplication

Edit the duplication file to clone the primary database as a standby database. You can enforce certain parameters to be applied in the init file using the spfile clause.

The duplication file is shown below:

Start the instance on the DR using the initdup.ora file:

Defer the copy of the production archives to the DR to avoid potential errors:

Execute the standby database creation command (here in silent mode with nohup):

Enable the copy of the production archives to the DR:

Below is an example of the content of the dup.log file from the execution of the duplication command:

POST DUPLICATION OPERATIONS

Status of the standby database after duplication

Connect to the DR database and check that the database is created as PHYSICAL STANDBY. The redos of threads or nodes 1 and 2 have been created on the DR

Below is the list of redo and SLR files created by the duplication command :

SQL> select * from v$logfile order by 1,4;

Enabling Synchronization
Enable synchronization between the primary and secondary databases using the command below:

or

Synchronization Verification
Verify that synchronization is working correctly using the following command:

Note: APPLIED=’YES’ means that the archive file has been successfully copied and applied to the DR. If the archive has not yet been applied or is in the process of being applied, APPLIED=’NO’.

NB: We note archives of 22xx and 49xx sequences, coming from the 2 nodes of the clustered databases on production.

From different production databases nodes, execute the command below and check with command above that archive files are received and applied on the DR:

To check for dataguard issue, you can run below commands :