6
Using Recovery Manager in Real Application Clusters Environments

This chapter explains how to use Recovery Manager (RMAN) in Real Application Clusters environments. The topics in this chapter include:

• Configuring RMAN in Real Application Clusters: Overview
• Configuring the RMAN Snapshot Control File Location
• Configuring the RMAN Control File Autobackup Feature
• Managing Archived Logs in Real Application Clusters Environments
• RMAN Archiving Configuration Schemes
• Changing the Archiving Mode in Real Application Clusters
• Querying the Archiver Processes

Configuring RMAN in Real Application Clusters: Overview

Perform the procedures described in this chapter after installing the Oracle Enterprise Edition with Oracle Real Application Clusters and after reviewing the following documentation:

• Oracle9i Recovery Manager User's Guide
• Oracle9i Recovery Manager Reference

  See Also: Oracle Enterprise Manager Administrator's Guide to use Oracle Enterprise Manager for backup and recovery

The configuration procedures described in this chapter explain how to:

1. Configure the snapshot control file location.
2. Configure the control file autobackup feature.
3. Configure the archiving scheme.
4. Change the archiving mode of the database (optional)
5. Monitor the archiver processes.

Configuring the RMAN Snapshot Control File Location

In Real Application Clusters, identical copies of the snapshot control file must exist on every node that performs backups. Therefore, ensure that the same destination directory for a snapshot control file exists on all nodes used for backups.

RMAN creates a snapshot control file to obtain a consistent record of the contents of the target control file before making a backup. RMAN creates the snapshot control file on the node that performs backups. Run the following RMAN command to determine the default location of the snapshot control file:

SHOW SNAPSHOT CONTROLFILE NAME;

If needed, you can change the default location. For example, on UNIX you can specify the snapshot control file location as $ORACLE_HOME/dbs/scf/snap_prod.cf by entering the following at the RMAN prompt:

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '?/dbs/scf/snap_prod.cf';

This command globally sets the configuration for the location of the snapshot control file throughout your cluster database. Therefore, ensure that the directory $ORACLE_HOME/dbs/scf exists on all nodes that perform backups.

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

Configuring the RMAN Control File Autobackup Feature

The RMAN control file autobackup feature automatically creates backups of the control file after executing the BACKUP and COPY commands. This feature is important in disaster recovery because RMAN can restore the control file even without a recovery catalog.

If you set CONFIGURE CONTROLFILE AUTOBACKUP to ON, then RMAN automatically creates a control file and a server parameter file backup after you run the BACKUP or COPY commands. 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 on all nodes that perform 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.

Managing Archived Logs in Real Application Clusters Environments

After configuring the snapshot control file location and enabling the control file autobackup feature, decide how to configure your environment to manage the archived logs that each node generates.

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

The archived log naming scheme that you use is important because when a node writes to a log with a specific filename on its file system, the file must be readable by any node that needs to access this log. For example, if node 1 archives a log to /oracle/arc_dest/log_1_100.arc, then node 2 can only back up this log if it can read/oracle/arc_dest/log_1_100.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 performs archived log backups or all nodes perform archived log backups, you need to ensure that all logs are backed up. Because only one instance can perform recovery, the node performing recovery must have read access to all logs in your cluster.

Archiving in a Real Application Cluster Environment

Your primary configuration task is to ensure that all archived redo logs can be read from every node during recovery, and if possible during backups. This scenario illustrates the archived log naming issues for configuring archiving in your cluster database.

In this scenario, assume that the following conditions are met:

• You configure each node to write to a local archiving directory that is named the same on each node.
• You do not set up a cluster file system (in other words, each node can only read from and write to its own local file system).
• You do not use NFS or mapped drives to enable the nodes in the cluster to gain read/write access to one another.

Configure the initialization parameters file as:

sid1.log_archive_dest_1 = (location=/arc_dest)
sid2.log_archive_dest_1 = (location=/arc_dest)
sid3.log_archive_dest_1 = (location=/arc_dest)

Assume that the filenames of the archived logs are recorded in the control file as follows:

/arc_dest/log_1_62.arc 
/arc_dest/log_2_100.arc
/arc_dest/log_2_101.arc
/arc_dest/log_3_70.arc

/arc_dest/log_1_63.arc

Given this scenario, assume that your Real Application Clusters database performs recovery. If node 1 tries to read the logs for recovery, then it searches its local /arc_dest directory for the filenames as they are recorded in the control file. Using this data, node 1 only finds the logs that it archived locally, for example /arc_dest/log_1_62.arc and /arc_dest/log_1_63.arc. However, node 1 cannot apply the other logs because the filenames for these logs are not readable on its local file system. Thus, the recovery stalls. You can avoid this problem by configuring your cluster according to the schemes described in the following section.

RMAN Archiving Configuration Schemes

The two configuration schemes in this chapter describe a three-node UNIX system for a Real Application Clusters database. For both schemes, 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 files.

In Real Application Clusters, set the same value for the LOG_ARCHIVE_FORMAT parameter on all instances. You can specify a different value of LOG_ARCHIVE_DEST_n during recovery if the archived redo log files are not at their original archiving destinations.

This section contains the following topics:

• Cluster File System Archiving Scheme
• Non-CFS Local Archiving Scheme
• Archived Log File Format and Destinations in Real Application Clusters

Cluster File System Archiving Scheme

The preferred configuration for Real Application Clusters is to use a cluster file system archiving scheme. As shown in Figure 6-1, each node writes to a single CFS archived log destination and can read the archived log files of the other nodes. Read access is achieved with a cluster file system. For example, if node 1 archives a log to /arc_dest/log_1_100.arc on the CFS, then any other node in the cluster can also read this file.

Figure 6-1 Cluster File System Archiving Scheme

Text description of the illustration racad006.gif

Advantages and Disadvantages of the Cluster File System Archiving Scheme

The advantages of this scheme are:

• None of the nodes uses the network to archive logs.
• If each node has a local tape drive, then you can distribute an archived log backup so that each node backs up local logs without accessing the network.
• Because the filename 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 logs.

Initialization Parameter Settings for the Cluster File System Archiving Scheme

In the CFS scheme, each node archives to a directory that is identified with the same name on all instances within the cluster database. To configure this, set values for the LOG_ARCH_DEST_n parameter for each instance using the sid designator as in the following example:

sid1.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"
sid2.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"
sid3.LOG_ARCHIVE_DEST_1="LOCATION=/arc_dest"

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

/arc_dest/arc_1_999.arc
/arc_dest/arc_1_1000.arc
/arc_dest/arc_1_1001.arc <- thread 1 archived in node 3
/arc_dest/arc_3_1563.arc <- thread 3 archived in node 2
/arc_dest/arc_2_753.arc <- thread 2 archived in node 1
/arc_dest/arc_2_754.arc
/arc_dest/arc_3_1564.arc

Location of Archived Logs for the Cluster File System Archiving Scheme

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

Non-CFS Local Archiving Scheme

In the non-CFS local archiving scheme, each node archives to a uniquely named local directory as shown in Figure 6-2. 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 UNIX or shared drives on Windows platforms. Therefore, each node writes only to a local destination, but each node can also read archived log files in remote directories on the other nodes.

Figure 6-2 Non-CFS Local Archiving Scheme

Text description of the illustration rmanopsa.gif

To enable RMAN to back up and recover a Real Application Clusters database in one step, all archived logs must have uniquely identifiable names throughout the cluster. To do this, however, you cannot use the technique described in "Cluster File System Archiving Scheme" to have more than one node archive to a directory such as /arc_dest.

Advantages and Disadvantages of the Non-CFS Local Archiving Scheme

The advantage of this scheme is:

• If each node has a local tape drive, then you can distribute an archived log backup so that each node backs up local logs without accessing the network.

The disadvantages of this scheme are:

• In a media recovery scenario, you must configure the node performing recovery for remote access so that it can read the archived log files in the archiving directories on the other nodes.
• If only one node has a local tape drive, then you cannot back up all logs from a single node without configuring NFS or manually transferring the logs.
• This scheme has a single point of failure. If one node fails after the most recent backup, then the archived logs on this node that were generated after the backup are lost. If you are in a recovery situation and do not have all available logs, then you are forced to perform point-in-time recovery up to the first missing archived log sequence number.

  Note: : You do not have to use a specific configuration for this scheme. However, if you want to distribute the backup processing onto multiple nodes, the easiest method is to configure channels as described in the backup scenarios in Chapter 7, "Performing Backup and Recovery in Real Application Clusters Environments".

Initialization Parameter Settings for the Non-CFS Local Archiving Scheme

You can set the archiving destination values as follows in the initialization parameter file:

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"

The following list shows possible archived log entries in the database control file. Note that any node is able to archive logs from any of the threads:

/arc_dest_1/arc_1_1000.arc
/arc_dest_2/arc_1_1001.arc <- thread 1 archived in node 2
/arc_dest_2/arc_3_1563.arc <- thread 3 archived in node 2
/arc_dest_1/arc_2_753.arc <- thread 2 archived in node 1
/arc_dest_2/arc_2_754.arc
/arc_dest_3/arc_3_1564.arc

Location of Archived Logs in the Non-CFS Local Archiving Scheme

As illustrated in Table 6-1, each node has a directory containing the locally archived logs. Additionally, if you mount directories on the other nodes remotely through NFS or shared drives, then each node has two remote directories through which RMAN can read the archived log files that are archived by the remaining nodes in the cluster.

Table 6-1 Location of Logs in the Non-CFS Local Archiving Scheme

Node ...	Can read the archived 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 the Non-CFS Local Archiving Scheme

Because NFS is not required to perform backups, node 1 can back up its local logs to its tape drive, node 2 can back up its local logs to its tape drive, and so on. However, if you are performing recovery and a surviving instance must read all the logs that are on disk but not yet backed up, then you should configure NFS as shown in Table 6-2.

Table 6-2 NFS Configuration for Shared Read Local Archiving Scheme

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

Archived Log File Format and Destinations in Real Application Clusters

For any archived log configuration, uniquely identify the archived redo logs with the LOG_ARCHIVE_FORMAT parameter. The format of this parameter is operating system-specific and it can include text strings, one or more variables, and a filename extension. LOG_ARCHIVE_FORMAT can also have variables as shown in Table 6-3. Examples in Table 6-3 assume that LOG_ARCHIVE_FORMAT=log_%parameter and that the length limits for sequence values is ten characters and thread values is four characters.

Table 6-3 Archived Redo Log Filename Format Parameters

Parameter	Description	Example
%T	Thread number, left-zero-padded	log_0001
%t	Thread number, not padded	log_1
%S	Log sequence number, left-zero-padded	log_0000000251
%s	Log sequence number, not padded	log_251

The thread parameters %t or %T are mandatory for Real Application Clusters. For example, if the instance associated with redo thread number 1 sets LOG_ARCHIVE_FORMAT to log_%t_%s.arc, then its archived redo log files are named:

log_1_1000.arc
log_1_1001.arc
log_1_1002.arc
.
.
.

Changing the Archiving Mode in Real Application Clusters

After configuring your Real Application Clusters environment for RMAN, you can alter the archiving mode if needed. For example, if your Real Application Clusters database uses NOARCHIVELOG mode, then follow these steps to change the archiving mode to ARCHIVELOG mode:

1. Shut down all instances.
2. Reset the CLUSTER_DATABASE parameter to false on one instance. If you are using the server parameter file, then make a sid-specific entry for this.
3. Add settings in the parameter file for the LOG_ARCHIVE_DEST_n, LOG_ARCHIVE_FORMAT, and LOG_ARCHIVE_START parameters. You can multiplex the destination to use up to ten locations. The LOG_ARCHIVE_FORMAT parameter should contain the %t parameter to include the thread number in the archived log file name. You must configure an archiving scheme before setting these parameter values.
4. Start the instance on which you have set CLUSTER_DATABASE to false.
5. Run the following statement in SQL*Plus:

   SQL>ALTER DATABASE ARCHIVELOG;
   
   

6. Shut down the instance.
7. Change the value of the CLUSTER_DATABASE parameter to true.
8. Restart your instances.

You can also change the archiving mode from ARCHIVELOG to NOARCHIVELOG. To disable archiving, follow the preceding steps with the following changes:

1. Delete the archiving settings that you created in step 3.
2. Specify the NOARCHIVELOG keyword in step 5:

   ALTER DATABASE NOARCHIVELOG;
   

Querying the Archiver Processes

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