| Oracle® Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide 10g Release 2 (10.2) Part Number B14197-02 |
|
|
View PDF |
| Oracle® Database Oracle Clusterware and Oracle Real Application Clusters Administration and Deployment Guide 10g Release 2 (10.2) Part Number B14197-02 |
|
|
View PDF |
The Oracle Clusterware includes two important components: the voting disk and the Oracle Cluster Registry (OCR). The voting disk is a file that manages information about node membership and the OCR is a file that manages cluster and RAC database configuration information. This chapter describes how to administer the voting disks and the Oracle Cluster Registry (OCR) under the following topics:
Oracle recommends that you select the option to configure multiple voting disks during the Oracle Clusterware installation to improve availability. After installation, use the following procedures to regularly backup your voting disks and to recover them as needed:
|
Note: You can dynamically add voting disks after you complete the Oracle Clusterware and RAC installation processes. |
|
See Also: "Administering the Oracle Cluster Registry in Real Application Clusters" for more information about administering the OCR |
Run the following command to back up a voting disk. Perform this operation on every voting disk as needed where voting_disk_name is the name of the active voting disk and backup_file_name is the name of the file to which you want to back up the voting disk contents:
dd if=voting_disk_name of=backup_file_name
|
Note: You can use theocopy command in Windows environments or use the crsctl commands described in the following note. |
Run the following command to recover a voting disk where backup_file_name is the name of the voting disk backup file and voting_disk_name is the name of the active voting disk:
dd if=backup_file_name of=voting_disk_name
|
Note: If you have multiple voting disks, then you can remove the voting disks and add them back into your environment using thecrsctl delete css votedisk path and crsctl add css votedisk path commands respectively, where path is the complete path of the location on which the voting disk resides. |
You can dynamically add and remove voting disks after installing Real Application Clusters. Do this using the following commands where path is the fully qualified path for the additional voting disk. Run the following command as the root user to add a voting disk:
crsctl add css votedisk path
Run the following command as the root user to remove a voting disk:
crsctl delete css votedisk path
|
Note: If your cluster is down, then you can use-force option to modify the voting disk configuration with either of these commands without interacting with active Oracle Clusterware daemons. However, using the -force option while any cluster node is active may corrupt your configuration. |
This section describes how to administer the OCR. The OCR contains information about the cluster node list, instance-to-node mapping information, and information about Oracle Clusterware resource profiles for applications that you have customized as described in Chapter 14, "Making Applications Highly Available Using the Oracle Clusterware". The procedures discussed in this section are:
Managing Backups and Recovering the OCR Using OCR Backup Files
Diagnosing OCR Problems with the OCRDUMP and OCRCHECK Utilities
Overriding the Oracle Cluster Registry Data Loss Protection Mechanism
Implementing the Oracle Hardware Assisted Resilient Data Initiative for the OCR
Upgrading and Downgrading the OCR Configuration in Real Application Clusters
The Oracle installation process for RAC gives you the option of automatically mirroring the OCR. This creates a second OCR to duplicate the original OCR. You can put the mirrored OCR on an Oracle cluster file system disk, on a shared raw device, or on a shared raw logical volume.
You can also manually mirror the OCR if you:
Upgraded to release 10.2 but did not chose to mirror the OCR during the upgrade
Created only one OCR during the Oracle Clusterware installation
|
Note: Oracle strongly recommends that you use mirrored OCRs if the underlying storage is not RAID. This prevents the OCR from becoming a single point of failure. |
In addition to mirroring the OCR, you can also replace the OCR if Oracle displays an OCR failure alert in Enterprise Manager or in the Oracle Clusterware alert log file. You can also repair an OCR location if there is a mis-configuration or other type of OCR error. In addition, you can remove an OCR location if, for example, your system experiences a performance degradation due to OCR processing or if you transfer your OCR to RAID storage devices and chose to no longer use multiple OCRs. Use the following procedures to perform these tasks:
|
Note: The operations in this section affect the OCR cluster-wide: they change the OCR configuration information in theocr.loc file on UNIX-based systems and the Registry keys on Windows-based systems. However, the ocrconfig command cannot modify OCR configuration information for nodes that are shut down or for nodes on which the Oracle Clusterware is not running. |
You can add an OCR location after an upgrade or after completing the RAC installation. If you already mirror the OCR, then you do not need to add an OCR location; Oracle automatically manages two OCRs when it mirrors the OCR. RAC environments do not support more than two OCRs, a primary OCR and a second OCR.
|
Note: If your OCR resides on a cluster file system file or if the OCR is on an network file system, then create the target OCR file before performing the procedures in this section. |
Run the following command to add an OCR location using either destination_file or disk to designate the target location of the additional OCR:
ocrconfig -replace ocr destination_file or disk
Run the following command to add an OCR mirror location using either destination_file or disk to designate the target location of the additional OCR:
ocrconfig -replace ocrmirror destination_file or disk
|
Note: You must beroot user to run ocrconfig commands. |
You can replace a mirrored OCR using the following procedure as long as one OCR-designated file remains online:
Verify that the OCR that you are not going to replace is online.
Verify that the Oracle Clusterware is running on the node on which the you are going to perform the replace operation.
|
Note: The OCR that you are replacing can be either online or offline. In addition, if your OCR resides on a cluster file system file or if the OCR is on an network file system, then create the target OCR file before continuing with this procedure. |
Run the following command to replace the OCR using either destination_file or disk to indicate the target OCR:
ocrconfig -replace ocr destination_file or disk
Run the following command to replace an OCR mirror location using either destination_file or disk to indicate the target OCR:
ocrconfig -replace ocrmirror destination_file or disk
If any node that is part of your current RAC environment is shut down, then run the command ocrconfig -repair on any node that is stopped to enable that node to rejoin the cluster after you restart the stopped node.
You may need to repair an OCR configuration on a particular node if your OCR configuration changes while that node is stopped. For example, you may need to repair the OCR on a node that was not up while you were adding, replacing, or removing an OCR. To repair an OCR configuration, run the following command on the node on which you have stopped the Oracle Clusterware daemon:
ocrconfig –repair ocrmirror device_name
This operation only changes the OCR configuration on the node from which you run this command. For example, if the OCR mirror device name is /dev/raw1, then use the command syntax ocrconfig -repair ocrmirror /dev/raw1 on this node to repair its OCR configuration.
|
Note: You cannot perform this operation on a node on which the Oracle Clusterware daemon is running. |
To remove an OCR location, at least one other OCR must be online. You can remove an OCR location to reduce OCR-related overhead or to stop mirroring your OCR because you moved your the OCR to redundant storage such as RAID. Perform the following procedure to remove an OCR location from your RAC environment:
Ensure that at least one OCR other than the OCR that you are removing is online.
|
Caution: Do not perform this OCR removal procedure unless there is at least one other active OCR online. |
Run the following command on any node in the cluster to remove the OCR:
ocrconfig -replace ocr
Run the following command on any node in the cluster to remove the mirrored OCR:
ocrconfig -replace ocrmirror
These commands update the OCR configuration on all of the nodes on which the Oracle Clusterware is running.
|
Note: When removing an OCR location, the remaining OCR must be online. If you remove a primary OCR, then the mirrored OCR becomes the primary OCR. |
This section describes two methods for copying OCR content and using it for recovery. The first method uses automatically generated OCR file copies and the second method uses manually created OCR export files.
The Oracle Clusterware automatically creates OCR backups every four hours. At any one time, Oracle always retains the last three backup copies of the OCR. The CRSD process that creates the backups also creates and retains an OCR backup for each full day and at the end of each week.
You cannot customize the backup frequencies or the number of files that Oracle retains. You can use any backup software to copy the automatically generated backup files at least once daily to a different device from where the primary OCR resides.
The default location for generating backups on UNIX-based systems is CRS_home/cdata/cluster_name where cluster_name is the name of your cluster. The Windows-based default location for generating backups uses the same path structure.
|
Note: You must beroot user to run ocrconfig commands. |
If an application fails, then before attempting to restore the OCR, restart the application. As a definitive verification that the OCR failed, run an ocrcheck and if the command returns a failure message, then both the primary OCR and the OCR mirror have failed. Attempt to correct the problem using one of the following platform-specific OCR restoration procedures.
|
Note: You cannot restore your configuration from an automatically created OCR backup file using the -import option, which is explained in "Administering the Oracle Cluster Registry with OCR Exports". You must instead use the -restore option as described in the following sections. |
Use the following procedure to restore the OCR on UNIX-based systems:
Identify the OCR backups using the ocrconfig -showbackup command. Review the contents of the backup using ocrdump -backupfile file_name where file_name is the name of the backup file.
Stop the Oracle Clusterware software on all of the nodes in your RAC database by executing the init.crs stop command on all of the nodes.
Perform the restore by applying an OCR backup file that you identified in Step 1 using the following command where file_name is the name of the OCR that you want to restore:
ocrconfig -restore file_name
Restart the Oracle Clusterware on all of the nodes in your cluster by restarting each node or by running the init.crs start command.
Run the following command to verify the OCR integrity where the -n all argument retrieves a listing of all of the cluster nodes that are configured as part of your cluster:
cluvfy comp ocr -n all [-verbose]
Use the following procedure to restore the OCR on Windows-based systems:
Identify the OCR backups using the ocrconfig -showbackup command. Review the contents of the backup using ocrdump -backupfile file_name where file_name is the name of the backup file.
On all of the remaining nodes, disable the following OCR clients and stop them using the Service Control Panel: OracleClusterVolumeService, OracleCSService, OracleCRService, and the OracleEVMService.
Execute the restore by applying an OCR backup file that you identified in Step 1 with the ocrconfig -restore file name command.
Start all of the services that were stopped in step 2. Restart all of the nodes and resume operations in cluster mode.
Run the following command to verify the OCR integrity where the -n all argument retrieves a listing of all of the cluster nodes that are configured as part of your cluster:
cluvfy comp ocr -n all [-verbose]
|
See Also: "Cluster Verification Utility Oracle Clusterware Component Verifications" for more information about enabling and using CVU |
You can use the OCRDUMP and OCRCHECK utilities to diagnose OCR problems as described under the following topics:
Use the OCRDUMP utility to write the OCR contents to a file so that you can examine the OCR content.
The OCR has a mechanism that prevents data loss due to accidental overwrites. If you configure a mirrored OCR and if the OCR cannot access the two mirrored OCR locations and also cannot verify that the available OCR contains the most recent configuration, then the OCR prevents further modification to the available OCR. The OCR prevents overwriting by prohibiting the Oracle Clusterware from starting on the node on which the OCR resides. In such cases, Oracle displays an alert message in either Enterprise Manager, the Oracle Clusterware alert log files, or both.
Sometimes this problem is local to only one node and you can use other nodes to start your cluster database. In such cases, Oracle displays an alert message in Enterprise Manager, the Oracle Clusterware alert log, or both.
However, if you are unable to start any cluster nodes in your environment and if you cannot repair the OCR, then you can override the protection mechanism. This procedure enables you to start the cluster using the available OCR, thus enabling you to use the updated OCR file to start your cluster. However, this can result in the loss of data that was not available at the time that the previous known good state was created.
|
Note: Overriding the OCR using this procedure can result in the loss of OCR updates that were made between the time of the last known good OCR update made to the currently-accessible OCR and the time at which you performed this procedure. In other words, running theocrconfig -overwrite command can result in data loss if the OCR that you are using to perform the overwrite does not contain the latest configuration updates for your cluster environment. |
Perform the following procedure to overwrite the OCR if a node cannot start up and if the alert log contains a a CLSD-1009 or CLSD-1011 message.
Attempt to resolve the cause of the a CLSD-1009 or CLSD-1011 message. Do this by comparing the node's OCR configuration (ocr.loc on Unix-based systems and the Registry on Windows-based systems) with other nodes on which the Oracle Clusterware is running. If the configurations do not match, then run ocrconfig -repair. If the configurations match, then ensure that the node can access all of the configured OCRs by running an ls command on Unix-based systems or a dir command on Windows-based systems. Oracle issues a warning when one of the configured OCR locations is not available or if the configuration is incorrect.
Ensure that the most recent OCR contains the latest OCR updates. Do this by taking output from the ocrdump command and determine whether it has your latest updates.
If you cannot resolve the CLSD message, then run the command ocrconfig -overwrite to bring up the node.
In addition to using the automatically created OCR backup files, you should also export the OCR contents before and after making significant configuration changes, such as adding or deleting nodes from your environment, modifying Oracle Clusterware resources, or creating a database. Do this by using the ocrconfig -export command. This exports the OCR content to a file format.
Using the ocrconfig -export command enables you to restore the OCR using the -import option if your configuration changes cause errors. For example, if you have unresolvable configuration problems, or if you are unable to restart your clusterware after such changed, then restore your configuration using one of the following platform-specific procedures:
Importing Oracle Cluster Registry Content on UNIX-Based Systems
Importing Oracle Cluster Registry Content on Windows-Based Systems
|
Note: Most configuration changes that you make not only change the OCR contents, configuration changes also cause file and database object creation. Some of these changes are often not restored when you restore the OCR. Do not perform an OCR restore as a correction to revert to previous configurations if some of these configuration changes should fail. This may result in an OCR that has contents that do not match the state of the rest of your system. |
Use the following procedure to import the OCR on UNIX-based systems:
Identify the OCR export file that you want to import by identifying the OCR export file that you previously created using the ocrconfig -export file_name command.
Stop the Oracle Clusterware software on all of the nodes in your RAC database by executing the init.crs stop command on all of the nodes.
Perform the import by applying an OCR export file that you identified in Step 1 using the following command where file_name is the name of the OCR file from which you want to import OCR information:
ocrconfig -import file_name
Restart the Oracle Clusterware on all of the nodes in your cluster by restarting each node.
Run the following Cluster Verification Utility (CVU) command to verify the OCR integrity where the -n all argument retrieves a listing of all of the cluster nodes that are configured as part of your cluster:
cluvfy comp ocr -n all [-verbose]
|
Note: You cannot import an exported OCR backup file, which is described in "Managing Backups and Recovering the OCR Using OCR Backup Files". You must instead use the-import option as described in the following sections. |
Use the following procedure to import the OCR on Windows-based systems:
Identify the OCR export file that you want to import by running the ocrconfig -showbackup command. .
Stop the following OCR clients on each node in your RAC environment using the Service Control Panel: OracleClusterVolumeService, OracleCMService, OracleEVMService, OracleCSService, and the OracleCRService.
Import an OCR export file using the ocrconfig -import command from one node.
Restart all of the affected services on all nodes.
Run the following Cluster Verification Utility (CVU) command to verify the OCR integrity where node_list is a list of all of the nodes in your cluster database:
cluvfy comp ocr -n all [-verbose]
The Oracle Hardware Assisted Resilient Data (HARD) initiative prevents data corruptions from being written to permanent storage. If you enable HARD, then the OCR writes HARD-compatible blocks. To determine whether the device used by the OCR supports HARD and then enable it, review the Oracle HARD white paper at:
http://www.oracle.com/technology/deploy/availability/htdocs/HARD.html
When you install the Oracle Clusterware, Oracle automatically runs the ocrconfig -upgrade command. To downgrade, follow the downgrade instructions for each component and also downgrade the OCR using the ocrconfig -downgrade command. If you are upgrading the OCR to Oracle Database 10g release 10.2, then you can use the cluvfy command to verify the integrity of the OCR. If you are downgrading, you cannot use the Cluster Verification Utility (CVU) commands to verify the OCR for pre-10.2 release formats.
In Oracle9i, the OCR did not write HARD-compatible blocks. If the device used by OCR is enabled for HARD, then use the method described in the HARD white paper to disable HARD for the OCR before downgrading your OCR. If you do not disable HARD, then the downgrade operation fails.
