7 Configuring Recovery Manager and Archiving

You can configure Oracle Recovery Manager (Oracle RMAN) to support your Oracle RAC environment.

This chapter provides procedures for using for archiving in Oracle RAC environments and discusses online redo log and archived redo log considerations.

Note:

A multitenant container database is the only supported architecture in Oracle Database 21c. While the documentation is being revised, legacy terminology may persist. In most cases, "database" and "non-CDB" refer to a CDB or PDB, depending on context. In some contexts, such as upgrades, "non-CDB" refers to a non-CDB from a previous release.

• Overview of Configuring RMAN for Oracle RAC
  Oracle Recovery Manager (Oracle RMAN) enables you to back up, restore, and recover files and archived logs.
• Archiving Mode in Oracle RAC
  To archive redo log files, the Oracle RAC database must be in ARCHIVELOG mode.
• Configuring the RMAN Snapshot Control File Location
  The snapshot control file is a copy of a database control file that RMAN creates in an operating system-specific location.
• Configuring RMAN to Automatically Backup the Control File and SPFILE
  If you set CONFIGURE CONTROLFILE AUTOBACKUP to ON, then RMAN automatically creates a control file and an SPFILE backup after you run the BACKUP or COPY commands.
• Crosschecking on Multiple Oracle RAC Nodes
  When crosschecking on multiple nodes, and when operating RMAN in general, configure your cluster so that every node can access all of the backups, regardless of which node created the backups.
• Configuring Channels for RMAN in Oracle RAC
  Learn how to configure channels for RMAN in Oracle RAC.
• Managing Archived Redo Logs Using RMAN in Oracle RAC
  Learn about managing archived redo logs using RMAN in Oracle RAC.
• Archived Redo Log File Conventions in Oracle RAC
  For any archived redo log configuration, uniquely identify the archived redo logs with the LOG_ARCHIVE_FORMAT parameter.
• RMAN Archiving Configuration Scenarios
  Learn about the various RMAN archiving scenarios.
• Monitoring the Archiver Processes
  Learn how to monitor the archiver processes.

Overview of Configuring RMAN for Oracle RAC

Oracle Recovery Manager (Oracle RMAN) enables you to back up, restore, and recover files and archived logs.

RMAN enables you to back up, restore, and recover data files, control files, server parameter files (SPFILEs) and archived redo log files. RMAN is included with Oracle Database and does not require separate installation. You can run RMAN from the command line or use RMAN in the Backup Manager in Oracle Enterprise Manager.

Archiving Mode in Oracle RAC

To archive redo log files, the Oracle RAC database must be in ARCHIVELOG mode.

You can run the ALTER DATABASE SQL statement to change the archiving mode in Oracle RAC, because the database is mounted by the local instance but not open in any instances. You do not need to modify parameter settings to run this statement.

Note:

• The ARCHIVELOG mode is set at the database level, not the instance level. Either all instances archive or none do.

• You can also change the archive log mode by using the Recovery Settings page in the Maintenance tab of the Oracle Enterprise Manager Oracle RAC Database Home Page.

Configuring the RMAN Snapshot Control File Location

The snapshot control file is a copy of a database control file that RMAN creates in an operating system-specific location.

RMAN creates the snapshot control file so that it has a consistent version of a control file to use when either resynchronizing the recovery catalog or backing up the control file.

For effective backup and recovery operations, the RMAN snapshot control file must be on shared storage that is accessible by all database nodes in a cluster. Run the following RMAN command to determine the configured location of the snapshot control file:

SHOW SNAPSHOT CONTROLFILE NAME;

You can change the configured location of the snapshot control file. For example, on Linux and UNIX systems you can specify the snapshot control file location in Oracle ASM, for example, by entering the following at the RMAN prompt:

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+RECODG/Oracle SID/snap_prod.cf';

This command sets the configuration for the location of the snapshot control file for every instance of your cluster database. Therefore, ensure that the directory location is shared by all nodes that perform backups.

The CONFIGURE command creates persistent settings across RMAN sessions. Therefore, you do not need to run this command again unless you want to change the location of the snapshot control file.

To delete a snapshot control file you must first change the snapshot control file location, then delete the file at the older location, as follows:

CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'new_name';
DELETE COPY OF CONTROLFILE;

Configuring RMAN to Automatically Backup the Control File and SPFILE

If you set CONFIGURE CONTROLFILE AUTOBACKUP to ON, then RMAN automatically creates a control file and an SPFILE backup after you run the BACKUP or COPY commands.

RMAN can also automatically restore an SPFILE, if this is required to start an instance to perform recovery, because the default location for the SPFILE must be available to all nodes in your Oracle RAC database.

Note:

If you back up the control file using the SQL*Plus ALTER DATABASE command, then you must also create the control file backup on a device shared by all nodes.

These features are important in disaster recovery because RMAN can restore the control file even without a recovery catalog. RMAN can restore an autobackup of the control file even after the loss of both the recovery catalog and the current control file. You can change the default name that RMAN gives to this file with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command. Note that if you specify an absolute path name in this command, then this path must exist identically on all nodes that participate in backups.

RMAN performs the control file autobackup on the first allocated channel. Therefore, when you allocate multiple channels with different parameters, especially when you allocate a channel with the CONNECT command, determine which channel will perform the control file autobackup. Always allocate the channel for this node first.

Besides using the RMAN control file, you can also use Oracle Enterprise Manager to use the RMAN features.

Crosschecking on Multiple Oracle RAC Nodes

When crosschecking on multiple nodes, and when operating RMAN in general, configure your cluster so that every node can access all of the backups, regardless of which node created the backups.

When the cluster is configured this way, you can allocate channels to any node in the cluster during restore or crosscheck operations.

If you cannot configure the cluster so that each node can access all backups, then during restore and crosscheck operations, you must allocate channels on multiple nodes by providing the CONNECT option to the CONFIGURE CHANNEL command, so that every backup can be accessed by at least one node. If some backups are not accessible during crosscheck because no channel was configured on the node that can access those backups, then those backups are marked EXPIRED in the RMAN repository after the crosscheck.

For example, you can use CONFIGURE CHANNEL ... CONNECT in an Oracle RAC configuration in which tape backups are created on various nodes in the cluster and each backup is only accessible on the node on which it is created.

Configuring Channels for RMAN in Oracle RAC

Learn how to configure channels for RMAN in Oracle RAC.

This section describes how to configure channels for RMAN. You can configure channels to use automatic load balancing or you can specify specific channels for specific instances as described in the following topics:

• Configuring Channels to Use Automatic Load Balancing
  Learn how to configure channels to use automatic load balancing.
• Configuring Channels to Use a Specific Node
  To configure one RMAN channel for each policy-managed Oracle RAC database instance, you must perform a one-time channel configuration.

Configuring Channels to Use Automatic Load Balancing

Learn how to configure channels to use automatic load balancing.

To configure channels to use automatic load balancing, use the following syntax:

CONFIGURE DEVICE TYPE [disk | sbt] PARALLELISM number_of_channels;
...

Where number_of_channels is the number of channels that you want to use for the operation. After you complete this one-time configuration, you can run the BACKUP or RESTORE commands.

Configuring Channels to Use a Specific Node

To configure one RMAN channel for each policy-managed Oracle RAC database instance, you must perform a one-time channel configuration.

Note:

Starting with Oracle Grid Infrastructure 21c, policy-managed databases are deprecated.

To configure one RMAN channel for each policy-managed Oracle RAC database instance, use the following syntax:

CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT '@racinst_1'
CONFIGURE CHANNEL DEVICE TYPE sbt CONNECT '@racinst_2'
...

After this one-time configuration step, you can issue the BACKUP or RESTORE commands.

Managing Archived Redo Logs Using RMAN in Oracle RAC

Learn about managing archived redo logs using RMAN in Oracle RAC.

When a node generates an archived redo log, Oracle Database always records the file name of the log in the control file of the target database. If you are using a recovery catalog, then RMAN also records the archived redo log filenames in the recovery catalog when a resynchronization occurs.

The archived redo log naming scheme that you use is important because when a node writes to a log with a specific file name on its file system, the file must be readable by any node that must access this archived redo log. For example, if node1 archives a log to /oracle/arc_dest/log_1_100_23452345.arc, then node2 can back up this archived redo log only if it can read /oracle/arc_dest/log_1_100_23452345.arc on its own file system.

The backup and recovery strategy that you choose depends on how you configure the archiving destinations for each node. Whether only one node or all nodes perform archived redo log backups, you must ensure that all archived redo logs are backed up. If you use RMAN parallelism during recovery, then the node that performs recovery must have read access to all archived redo logs in your cluster.

Multiple nodes can restore archived logs in parallel. However, during recovery, only one node applies the archived logs. Therefore, the node that is performing the recovery must be able to access all of the archived logs that are needed for the recovery operation. By default, the database determines the optimum number of parallel threads to use during the recovery operation. You can use the PARALLEL clause in the RECOVER command to change the number of parallel threads.

Guidelines and Considerations for Archived Redo Logs

The primary consideration is to ensure that all archived redo logs can be read from every node during recovery, and, if possible, during backups. During recovery, if the archived log destinations are visible from the node that performs the recovery, then Oracle Database can successfully recover the archived log data.

Archived Redo Log File Conventions in Oracle RAC

For any archived redo log configuration, uniquely identify the archived redo logs with the LOG_ARCHIVE_FORMAT parameter.

The format of this parameter is operating system-specific and the format can include text strings, one or more variables, and a file name extension.

Table 7-1 Archived Redo Log File Name Format Parameters

Parameter	Description	Example
%r	Resetlogs identifier, not padded	log_1_62_23452345
%R	Resetlogs identifier, left-zero-padded	log_1_62_0023452345
%s	Log sequence number, not padded	log_251
%S	Log sequence number, left-zero-padded	log_0000000251
%t	Thread number, not padded	log_1
%T	Thread number, left-zero-padded	log_0001

All of the file name format parameters for the archive redo logs, in either upper or lowercase, are mandatory for Oracle RAC. These parameters enable Oracle Database to create unique names for archive logs across the incarnation. This requirement is in effect when the COMPATIBLE parameter is set to 10.0 or greater.

Use the %R or %r parameters to include the resetlogs identifier to avoid overwriting the logs from a previous incarnation. If you do not specify a log format, then the default is operating system-specific and includes %t, %s, and %r.

As an example, if the instance associated with redo thread number 1 sets LOG_ARCHIVE_FORMAT to log_%t_%s_%r.arc, then its archived redo log files are named:

log_1_1000_23435343.arc
log_1_1001_23452345.arc
log_1_1002_23452345.arc
...

RMAN Archiving Configuration Scenarios

Learn about the various RMAN archiving scenarios.

This section describes the archiving scenarios for an Oracle RAC database. The two configuration scenarios in this chapter describe a three-node UNIX cluster for an Oracle RAC database. For both scenarios, the LOG_ARCHIVE_FORMAT that you specify for the instance performing recovery must be the same as the format that you specified for the instances that archived the redo log files.

• Oracle Advanced Cluster File System Archiving Scheme
  The preferred configuration for Oracle RAC is to use Oracle Automatic Storage Management (Oracle ASM) for a recovery area using a disk group for your recovery set that is different from the disk group used for your data files.
• Noncluster File System Local Archiving Scheme
  Learn about the noncluster file system local archiving scheme.

Oracle Advanced Cluster File System Archiving Scheme

The preferred configuration for Oracle RAC is to use Oracle Automatic Storage Management (Oracle ASM) for a recovery area using a disk group for your recovery set that is different from the disk group used for your data files.

When you use Oracle ASM, it uses an Oracle Managed Files naming format. Alternatively, you can use a cluster file system archiving scheme. If you use a cluster file system, then each node writes to a single location on the cluster file system when archiving the redo log files. Each node can read the archived redo log files of the other nodes. For example, as shown in the following image, if Node 1 archives a redo log file to /arc_dest/log_1_100_23452345.arc on the cluster file system, then any other node in the cluster can also read this file.

Figure 7-1 Cluster File System Archiving Scheme

Description of "Figure 7-1 Cluster File System Archiving Scheme"

Note:

The archive log naming format in this example is only for a cluster file system example.

If you do not use a cluster file system, then the archived redo log files cannot be on raw devices. This is because raw devices do not enable sequential writing of consecutive archive log files.

• Advantages of the Cluster File System Archiving Scheme
  The main advantage of the cluster file system arcvhiving scheme is that any node can read the achive logs.
• Initialization Parameter Settings for the Cluster File System Archiving Scheme
  Learn about parameter settings for cluster file system archiving.
• Location of Archived Logs for the Cluster File System Archiving Scheme
  Any node can read the archive logs, regarless of which node created the logs.

Advantages of the Cluster File System Archiving Scheme

The main advantage of the cluster file system arcvhiving scheme is that any node can read the achive logs.

The advantage of this scheme is that none of the nodes uses the network to archive logs. Because the file name written by a node can be read by any node in the cluster, RMAN can back up all logs from any node in the cluster. Backup and restore scripts are simplified because each node has access to all archived redo logs.

Initialization Parameter Settings for the Cluster File System Archiving Scheme

Learn about parameter settings for cluster file system archiving.

In the cluster file system scheme, each node archives to a directory that is identified with the same name on all instances within the cluster database (/arc_dest, in the following example). To configure this directory, set values for the LOG_ARCH_DEST_1 parameter, as shown in the following example:

*.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"

The following list shows archived redo log entry examples that would appear in the RMAN catalog or in the control file based on the previous example. Note that any node can archive logs using any of the threads:

/arc_dest/log_1_999_23452345.arc
/arc_dest/log_1_1000_23435343.arc
/arc_dest/log_1_1001_23452345.arc <- thread 1 archived in node3
/arc_dest/log_3_1563_23452345.arc <- thread 3 archived in node2
/arc_dest/log_2_753_23452345.arc <- thread 2 archived in node1
/arc_dest/log_2_754_23452345.arc
/arc_dest/log_3_1564_23452345.arc

Location of Archived Logs for the Cluster File System Archiving Scheme

Any node can read the archive logs, regarless of which node created the logs.

Because the file system is shared and because each node is writing its archived redo logs to the /arc_dest directory in the cluster file system, each node can read the logs written by itself and any other node.

Noncluster File System Local Archiving Scheme

Learn about the noncluster file system local archiving scheme.

When archiving locally to a noncluster file system, each node archives to a uniquely named local directory. If recovery is required, then you can configure the recovery node so that it can access directories on the other nodes remotely. For example, use NFS on Linux and UNIX computers, or mapped drives on Windows systems. Therefore, each node writes only to a local destination, but each node can also read archived redo log files in remote directories on the other nodes.

• Considerations for Using Noncluster File System Local Archiving
  If you use noncluster file system local archiving for media recovery, then you must configure the node that is performing recovery for remote access to the other nodes so that the node can read the archived redo log files in the archive directories on the other nodes.
• Initialization Parameter Settings for Non-Cluster File System Local Archiving
  You can set the archiving destination values as follows in the initialization parameter file for either policy-managed or administrator-managed databases.
• Location of Archived Logs for Noncluster File System Local Archiving
  Learn about the location of archived logs for noncluster file system local archiving.
• File System Configuration for Noncluster File System Local Archiving
  Use NFS to perform recovery using a surviving instance to read logs that are not yet backed up.

Considerations for Using Noncluster File System Local Archiving

If you use noncluster file system local archiving for media recovery, then you must configure the node that is performing recovery for remote access to the other nodes so that the node can read the archived redo log files in the archive directories on the other nodes.

In addition, if you are performing recovery and you do not have all of the available archive logs, then you must perform an incomplete recovery up to the first missing archived redo log sequence number. You do not have to use a specific configuration for this scheme. However, to distribute the backup processing onto multiple nodes, the easiest method is to configure channels as described in the backup scenarios in "Managing Backup and Recovery".

Note:

Because different file systems are used in a noncluster case, the archive log directories must be unique on each node. For example, /arc_dest_1 is only available on node1, /arc_dest_2 is only directly mounted on node2, and so on.

Then node1 mounts /arc_dest_2 from node2 and /arc_dest_3 from node3 through NFS.

Initialization Parameter Settings for Non-Cluster File System Local Archiving

You can set the archiving destination values as follows in the initialization parameter file for either policy-managed or administrator-managed databases.

Note:

Starting with Oracle Grid Infrastructure 21c, policy-managed databases are deprecated.

Set the SID.LOG_ARCH_DEST parameter for each instance using the SID designator, as shown in the following example:

sid1.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_1"
sid2.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_2"
sid3.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest_3"

For policy-managed databases, manually create a node and instance binding to ensure that sid1 always runs on the same node, as follows:

$ srvctl modify database -d mydb -n node1 -i sid1
$ srvctl modify database -d mydb -n node2 -i sid2
$ srvctl modify database -d mydb -n node3 -i sid3

The following list shows the possible archived redo log entries in the database control file. Note that any node can read archived redo logs from any of the threads, which must happen in order for the database to recover after a failure.

/arc_dest_1/log_1_1000_23435343.arc
/arc_dest_2/log_1_1001_23452345.arc <- thread 1 archived in node2
/arc_dest_2/log_3_1563_23452345.arc <- thread 3 archived in node2
/arc_dest_1/log_2_753_23452345.arc <- thread 2 archived in node1
/arc_dest_2/log_2_754_23452345.arc
/arc_dest_3/log_3_1564_23452345.arc

Location of Archived Logs for Noncluster File System Local Archiving

Learn about the location of archived logs for noncluster file system local archiving.

As illustrated in the following table, each of three nodes has a directory containing the locally archived redo logs. Additionally, if you mount directories on the other nodes remotely through NFS or mapped drives, then each node has two remote directories through which RMAN can read the archived redo log files that are archived by the remaining nodes.

Note:

The archive log destinations, similar to those shown in the following table, must be different on each node so that if you mount the NFS directory on a different node, then it does not conflict with an existing archive log directory

Table 7-2 UNIX/NFS Location Log Examples, Noncluster File System Local Archiving

Node	Reads the archived redo log files in the directory	For logs archived by node
1	/arc_dest_1	1
1	/arc_dest_2	2 (through NFS)
1	/arc_dest_3	3 (through NFS)
2	/arc_dest_1	1 (through NFS)
2	/arc_dest_2	2
2	/arc_dest_3	3 (through NFS)
3	/arc_dest_1	1 (through NFS)
3	/arc_dest_2	2 (through NFS)
3	/arc_dest_3	3

File System Configuration for Noncluster File System Local Archiving

Use NFS to perform recovery using a surviving instance to read logs that are not yet backed up.

If you are performing recovery and a surviving instance must read all of the logs that are on disk but not yet backed up, then you should configure NFS as shown in the following table.

Table 7-3 UNIX/NFS Configuration for Shared Read Local Archiving Examples

Node	Directory...	Is configured...	And mounted on...	On node...
1	/arc_dest_1	Local read/write	n/a	n/a
1	/arc_dest_2	NFS read	/arc_dest_2	2
1	/arc_dest_3	NFS read	/arc_dest_3	3
2	/arc_dest_1	NFS read	/arc_dest_1	1
2	/arc_dest_2	Local read/write	n/a	n/a
2	/arc_dest_3	NFS read	/arc_dest_3	3
3	/arc_dest_1	NFS read	/arc_dest_1	1
3	/arc_dest_2	NFS read	/arc_dest_2	2
3	/arc_dest_3	Local read/write	n/a	n/a

Note:

Microsoft Windows users can achieve the same results depicted in the examples in this section by using mapped drives.

Monitoring the Archiver Processes

Learn how to monitor the archiver processes.

After your RMAN configuration is operative in your Oracle RAC environment, use the GV$ARCHIVE_PROCESSES and V$ARCHIVE_PROCESSES views to determine the status of the archiver processes. Depending on whether you query the global or local views, these views display information for all database instances, or for only the instance to which you are connected.

Note:

If you use the kill command to stop the archiver process, then the database instance will fail.