G Administering Oracle RAC

The Oracle Database 10g release 2 (10.2) includes the Oracle RAC option. Oracle RAC allows multiple database instances to share the same database files.

The information in this appendix supplements the detailed information in Oracle Real Application Clusters Administrator's Guide. Refer to that document as necessary when reading through this appendix.

In addition, there is important OpenVMS-specific installation and configuration information pertaining to Oracle RAC in chapters 5 and 6 of Oracle Database Installation Guide 10g.

G.1 Introduction to Oracle RAC Administration

Oracle Database 10g release 2 (10.2) uses Oracle Clusterware. Oracle Clusterware is a prerequisite for running Oracle RAC. Oracle Clusterware is installed separately.

Oracle RAC for Oracle Database 10g incorporates the Oracle Distributed Lock Manager. However, a limited number of native OpenVMS locks are also used in the clustering interface. The usage of OpenVMS locks has been greatly reduced from that of Oracle Parallel Server (OPS).

G.2 Changes from Oracle9i Database

The Oracle Database 10g release of Oracle RAC has many architectural changes from the version supplied with Oracle9i Database.

One of the changes is that the keywords used in the INIT.ORA parameter file of Oracle RAC have been changed. You should not copy a preexisting options file into a new installation.

G.3 Administering the Oracle Cluster Registry

This section describes how to administer the Oracle Cluster Registry. The Oracle Cluster Registry contains cluster and database configuration information for Oracle RAC and Oracle Cluster Ready Services. Some of this information includes the cluster node list, cluster database instance-to-node mapping information, and the Oracle Cluster Ready Services application resource profiles.

G.4 Managing Archived Redo Logs Using RMAN

Read this section in conjunction with Chapter 6, "Configuring Recovery Manager and Archiving" in Oracle Real Application Clusters Administrator's Guide.

After configuring the RMAN snapshot control file location and enabling the RMAN control file autobackup feature, you can decide how to configure the environment to manage the archived redo logs that each node generates. When a node generates an archived redo log file, 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 file names 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 device, the file must be readable by any node that must access this archived redo log. For example, if node 1 archives a log to device:[ORACLE.ARC_DEST]LOG_1_100.ARC, then node 2 can only back up this archived redo log if it can read device:[ORACLE.ARC_DEST]LOG_1_100.ARC on its own device. In general, this process is transparent in an operating system like OpenVMS, which has advanced clustering capabilities built into it.

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 redo log backups or all nodes perform archived redo log backups, you need to ensure that all archived redo logs are backed up. Because only one instance can perform recovery, the node of the instance performing recovery must have read access to all archived redo logs in the cluster.

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. This section illustrates the archived redo log naming issues for configuring archiving in the cluster database. The information in this section describes an archiving scheme in which the device to which each node is archiving is mounted and available only to that particular node of the cluster for Oracle RAC. Assume that the following conditions are met:

Configure each node to write to a local archiving directory that is named the same on each node.
Do not set up the device to be mounted and available across the OpenVMS cluster.

Example G-1 Example Configuration for the initialization Parameters File

sid1.LOG_ARCHIVE_DEST_1 = (LOCATION=DEVICE:[arc_dest])
sid2.LOG_ARCHIVE_DEST_1 = (LOCATION=DEVICE:[arc_dest])
sid3.LOG_ARCHIVE_DEST_1 = (LOCATION=DEVICE:[arc_dest])

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

device:[arc_dest]log_1_62.arc 
device:[arc_dest]log_2_100.arc
device:[arc_dest]log_2_101.arc
device:[arc_dest]log_3_70.arc
device:[arc_dest]log_1_63.arc

Given this scenario, assume that the Oracle RAC database performs recovery. If node 1 tries to read the logs for recovery, then it searches its local device:[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 device:[arc_dest]log_1_62.arc and device:[arc_dest]log_1_63.arc. However, node 1 cannot apply the other logs because the file names for these logs are not readable on the locally mounted disk. Therefore, the recovery stalls. Avoid this by implementing the naming conventions described in the next section and then configure the cluster according to the scenarios described in Chapter 6 of Oracle Real Application Clusters Administrator's Guide.

G.5 RMAN Archiving Configuration

This section describes the archiving configuration for a Oracle RAC database, which involves a three-node cluster for a Oracle RAC database. 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.

G.5.1 Cluster File System Archiving and Naming Scheme

Each node writes to a single cluster file system archived redo log destination and can read the archived redo log files of the other nodes. Read access is achieved for all nodes with a cluster file system. For example, if node 1 archives a log to device:[arc_dest]log_1_100.arc on the cluster file system, then any other node in the cluster can also read this file.

Figure G-1 shows a sample cluster file system archiving scheme.

Figure G-1 Cluster File System Archiving Scheme

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

G.5.1.1 Advantages and Disadvantages of the Cluster File System Archiving Scheme

The advantage of this scheme is that none of the nodes uses the network to archive logs. If each node has a local tape drive, then you can distribute an archived redo log backup so that each node backs up local logs without accessing the network. 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.

G.5.1.2 Initialization Parameter Settings for the Cluster File System Archiving Scheme

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. 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=CFS:[arc_dest]"
sid2.LOG_ARCHIVE_DEST_1="LOCATION=CFS:[arc_dest]"
sid3.LOG_ARCHIVE_DEST_1="LOCATION=CFS:[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:

CFS:[arc_dest]log_1_999.arc
CFS:[arc_dest]log_1_1000.arc
CFS:[arc_dest]log_1_1001.arc <- thread 1 archived in node 3
CFS:[arc_dest]log_3_1563.arc <- thread 3 archived in node 2
CFS:[arc_dest]log_2_753.arc <- thread 2 archived in node 1
CFS:[arc_dest]log_2_754.arc
CFS:[arc_dest]log_3_1564.arc

G.5.1.3 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 redo logs to the CFS:[arc_dest] directory in the cluster file system, each node can read the logs written by itself as well as any other node.