| Oracle® Database Administrator's Reference 10g Release 2 (10.2) for hp OpenVMS Part Number B25416-02 |
|
|
View PDF |
| Oracle® Database Administrator's Reference 10g Release 2 (10.2) for hp OpenVMS Part Number B25416-02 |
|
|
View PDF |
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.
See Also:
For more information about configuring and using Oracle RAC, refer to Oracle Real Application Clusters Installation and Configuration GuideThis appendix contains the following sections:
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).
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.
See Also:
The "New Features" section of Oracle Real Application Clusters Installation and Configuration Guide for a complete discussion of these changesThis 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.
See Also:
Chapter 3, "Administering Storage" of Oracle Real Application Clusters Administrator's GuideThere are two methods of copying Oracle Cluster Registry content and using the content for recovery. The first method uses automatically generated physical Oracle Cluster Registry file copies, and the second method uses manually created logical Oracle Cluster Registry export files as described in this section.
To move the Oracle Cluster Registry on OpenVMS-Based Systems:
Stop the Oracle Cluster Ready Services software on all the nodes in the cluster database by running the INIT_CRS STOP command on each node.
Edit the ORA_VAR_OPT:OCR.LOC file on all the nodes and set the ocrconfig_loc parameter to ocr_config_loc=new_location where new_location is the path to the new location of the Oracle Cluster Registry.
Restore the Oracle Cluster Registry from one of the automatic physical backups by using the OCRCONFIG -RESTORE command.
Run the OCRCHECK command to verify the new Oracle Cluster Registry location.
Restart the Oracle Cluster Ready Services software on all the nodes in the cluster.
You do not need to restart each node on OpenVMS systems.
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.
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.
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
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.
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
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.
