The Oracle Cluster Registry

---

As you can see from the HA Workshop earlier in this chapter, and the discussion of services in the following section, much information is kept and maintained in the Oracle Cluster Registry, or OCR. Whether using the DBCA to create the services or using SRVCTL to create and/or display information, the OCR is used heavily by these operations, and also by CRS to manage the availability and accessibility of the database (the instances and services defined within it). In this section, we will spend some time discussing how the information in the OCR can be maintained, backed up, and/or reviewed

Information in the OCR

As we have seen, the OCR contains information on our services, our database itself (all databases that are part of the cluster), and the instances that are part of the databases. In addition to this application information, the clusterware itself (primarily CSS) uses the OCR when starting up. In addition, information on dependencies between applications (such as a database instance being dependent on an ASM instance) and the states of individual applications are stored in the OCR. This information must be maintained cluster-wide, so that all nodes have access to the same information when needed. No specific user configuration is needed. This is all handled by the CRS install and by the various applications that we have already discussed, such as the DBCA and SRVCTL utilities. We have also seen that the OCR can exist on either a cluster file system (where supported) or on RAW devices. Aside from the ability to work on multiple storage subsystems, the information maintained in the OCR is, for the most part, the same regardless of platform.

Physically Backing Up the OCR

Given the importance of the OCR to your cluster, it is obviously essential that the information there be backed up frequently. In fact, automatic backups of the OCR disk are taken every four hours-these backups are stored by default in the CRS_HOME directory, under the cdata/<clustername> directory. By default, the last three backups are stored in that directory, though not always on the same node, as well as a day-old backup and a week-old backup. To view the backups, and which node is keeping them, you can run the following command:

ocrconfig -showbackup private1     2004/02/15 18:24:15     /u01/app/oracle/CRS/cdata/crs_lnx private2     2004/02/15 11:30:04     /u01/app/oracle/CRS/cdata/crs_lnx private2     2004/02/15 07:30:03     /u01/app/oracle/CRS/cdata/crs_lnx private2     2004/02/14 03:29:55     /u01/app/oracle/CRS/cdata/crs_lnx private2     2004/02/13 19:29:53     /u01/app/oracle/CRS/cdata/crs_lnx 

Note that the SHOWBACKUP command lists the times that each backup was taken, as well as the directory in which the backup is stored. In our case, the directory name is crs_lnx, as that is the name of the cluster. The other key piece of information is the node_name where that particular backup exists-using the private node name. In this case, you can see that the majority of the backups exist on Node2. A directory listing will show what type of backup each one is:

ls -al total 45900 drwxrwxr-x    2 oracle   oinstall     4096 Feb 15 11:30 . drwxrwxr-x    3 oracle   oinstall     4096 Feb 13 15:16 .. -rw-r-----    1 root     root      9170944 Feb 15 11:30 backup00.ocr -rw-r-----    1 root     root      9170944 Feb 15 07:30 backup01.ocr -rw-r-----    1 root     root      9170944 Feb 15 03:30 backup02.ocr -rw-r-----    1 root     root      9170944 Feb 15 03:30 day_.ocr -rw-r-----    1 root     root      5500928 Feb 14 03:29 day.ocr -rw-r-----    1 root     root      4718592 Feb 13 19:29 week.ocr

This directory listing was taken on Node2, where you can see a backup for each of the preceding two days, as well as the weekly backup taken on the 13^th of February. What you do not see is the most recent backup-we know from the SHOWBACKUP command that a backup was taken at 18:24 on the 15th. We also know from that output that the particular backup in question exists on Node1.

If you do not like this default location for the automatic backups, you can modify the location using the OCRCONFIG command. The switch needed is the -backuploc option, followed by the new directory:

ocrconfig -backuploc /u02/backups

It is also prudent to occasionally move these backups to another machine or off-site location that is not part of the cluster.

Restoring the OCR  If you think you need to restore the OCR because of a suspected corruption problem, you should first run the OCRCHECK utility (as discussed in the next section) to confirm if the OCR is in good shape. If the OCR integrity check fails, you will need to determine which of the preceding backups to restore from. You will first want to identify which node has the most recent backup, or which node has the backup taken at a known good time in the past (for example, check the CRS_HOME/crs/log/<nodename.log> to determine a time when the cluster was functioning normally). Once you have determined which node to restore from, all other nodes in the cluster will need to be shut down. On the remaining node (the node with the desired OCR backup), boot up in single-user mode. This will bypass the inittab, meaning that the CSS and CRS daemons will not start up. Alternatively, you can simply back up the current inittab, and then copy over the original inittab (inittab.orig) prior to rebooting. Once booted without the CRS daemons, do the restore using OCRCONFIG with the -restore option as root:

ocrconfig -restore /u01/app/oracle/CRS/cdata/crs_lnx/backup00.ocr

You should be sure that this is done as root and that you are using the OCRCONFIG in the CRS_HOME/bin directory. Once the restore completes, run OCRCHECK again to confirm that the OCR passes the integrity checks. Then copy back the inittab with the CRS entries (inittab.crs), shut back down, and reboot in normal mode. Finally, bring up the remaining nodes in the cluster.

Note 

If you wish to change the location to which the OCR is restored, the ocrconfig_loc setting can be modified to control that. This pointer will be found in the ocr.loc file. Depending on the platform, this file may be found in /var/opt/oracle, or /etc/oracle. On Windows, the location for the file will be found in the registry under HKLM\Software\Oracle\OCR, in a registry value called ocrconfig_loc.

Logical Backups and Restores of the OCR

In addition to the automatic physical backups, you can take a logical backup at any time by using an export switch for OCRCONFIG. The syntax of the export is, again, very straightforward:

ocrconfig -export /tmp/ocr_logical_export

Should you wish to restore from that export, it is recommended that you again follow the preceding steps of shutting down all nodes, and then booting up one node in single-user mode. Import with OCRCONFIG and the import switch:

ocrconfig -import /tmp/ocr_logical_export

After the import, restart the nodes in normal mode.

Dumping the Oracle Cluster Registry

Aside from taking backups, it is possible to dump all of the information in the Oracle Cluster Registry to an ASCII file. While the information therein cannot be used to rebuild the OCR, it has value for debugging purposes, and can be used by Oracle Support or Oracle Development to help troubleshoot problems. To dump out the OCR information, use the OCRDUMP command. Again, the syntax is quite simple:

ocrdump <filename> ocrdump /tmp/ocrdump.txt

If no filename is specified, the default name is OCRDUMPFILE, and it will be placed in the current directory where the command was issued from.

OCRCHECK  The last OCR utility that we will discuss is the OCRCHECK utility. It is run stand-alone, with no switches, and performs two basic operations. First, it will check the integrity of the OCR blocks, looking for any possible problems. Second, it checks the used and available space within the ocr file. The output should look similar to this:

oracle@/tmp>: ocrcheck Status of Oracle Cluster Registry is as follows :          Version                  :          2          Total space (kbytes)     :     262144          Used space (kbytes)      :       9252          Available space (kbytes) :     252892          Cluster registry integrity check succeeded

This is particularly handy if your ocr file is on a RAW device, and you are concerned that you are running out of space (which may happen if you have many nodes, many instances, many services, and a relatively small slice allocated for the OCR). If the used space is approaching the total space available on the RAW slice, you may want to consider relocating the OCR by changing the ocrconfig_loc and then restoring or reimporting the ocr file.

---