Home
 | 
Articles
 | 
High Availability
 | 
Oracle Cluster Registry
 | 
Oracle Cluster Registry (OCR)
 
Overview
Recent Article
All Archives
Topics
Comments 
Last modified: August 2016
»»
Oracle Cluster Registry (OCR) is a critical component of RAC. OCR records cluster configuration information. If it fails, the entire clustered environment for Oracle 11g RAC will be adversely affected and a possible outage may result if OCR is lost.
OCR is the central repository for CRS, which stores the metadata, configuration and state information for all cluster resources defined in clusterware. It is a cluster registry used to maintain application resources and their availability within the RAC environment. Also stores configuration information for CRS daemons and clusterware managed applications.
Following client applications do maintain and update OCR:
  • CSSd during cluster setup
  • CSS during node addition/deletion
  • CRSd about status of nodes during failure/reconfiguration
  • OUI
  • SRVCTL
  • CRSCTL
  • EM
  • DBCA
  • DBUA
  • NETCA
  • ASMCA
The physical location of the OCR can be viewed using 'ocrcheck' utility.
$
[root@ol-beta cdata]# ocrcheck

Status of Oracle Cluster Registry is as follows :
         Version                  :          4
         Total space (kbytes)     :     409568
         Used space (kbytes)      :       1664
         Available space (kbytes) :     407904
         ID                       :  989059424
         Device/File Name         :     +OCRDG
                                    Device/File integrity check succeeded

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

                                    Device/File not configured

         Cluster registry integrity check succeeded

         Logical corruption check succeeded
Backing Up Oracle Cluster Registry:
Automatic backups:
Oracle Clusterware automatically creates OCR backups every four hours. At any one time, Oracle Database always retains the last three backup copies of 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. We cannot customize the backup frequencies or the number of files that Oracle Database retains.
Manual backups:
Manual backups can be run using 'ocrconfig -manualbackup' command on a node where the Oracle Clusterware stack is up and running to force Oracle Clusterware to perform a backup of OCR at any time, rather than wait for the automatic backup. This is quite useful before you make any changes to OCR.
Note: OLR only supports manual backups.
In addition to using the automatically created OCR backup files, we can also export OCR contents before and after making significant configuration changes, such as adding or deleting nodes from your environment, modifying Oracle Clusterware resources, and upgrading, downgrading or creating a database. Do this by using the 'ocrconfig -export' command, which exports OCR content to a file format.
For example,
$
[root@ol-beta cdata]# ocrconfig -export ocr_shanma-cluster_20170125_1836_export
[root@ol-beta cdata]# cd ..; ls -l ocr_shanma*
-rw-------. 1 root root        103478 Jan 25 18:36 ocr_shanma-cluster_20170125_1836_export
Caution: The file format generated by 'ocrconfig -restore' is incompatible with the file format generated by 'ocrconfig -export'. The 'ocrconfig -export' and 'ocrconfig -import' commands are compatible. The 'ocrconfig -manualbackup' and 'ocrconfig -restore' commands are compatible. The two file formats are incompatible and must not be interchangeably used.
Run the following command to list the backups (both auto and manual).
$<>  
[root@ol-alpha cdata]# ocrconfig -showbackup
PROT-24: Auto backups for the Oracle Cluster Registry are not available

ol-alpha     2017/01/25 17:55:06     /u01/app/12.1.0/grid/cdata/shanma-cluster/backup_20170125_175506.ocr     0
ol-alpha     2017/01/25 17:54:37     /u01/app/12.1.0/grid/cdata/shanma-cluster/backup_20170125_175437.ocr     0
ol-alpha     2017/01/23 05:19:05     /u01/app/12.1.0/grid/cdata/shanma-cluster/backup_20170123_051905.ocr     0
Note: Since mine is not a production environment, the automatic backups are not occuring.
Restoring Oracle Cluster Registry:
As a definitive verification that OCR failed, run 'ocrcheck' and if the command returns a failure message, then both the primary OCR and the OCR mirror have failed.
$
[root@ol-beta cdata]# olsnodes

ol-alpha
ol-beta
Stop Oracle Clusterware by running the followng command as root on all of the nodes:
$
[root@ol-beta ~]# crsctl stop crs
If the above command fails, retry as 'crsctl stop crs -f'
From one node, we need to start CRS in exclusive mode:
$
[root@ol-alpha ~]# crsctl start crs -excl

CRS-4123: Oracle High Availability Services has been started.
CRS-2672: Attempting to start 'ora.evmd' on 'ol-alpha'
CRS-2672: Attempting to start 'ora.mdnsd' on 'ol-alpha'
CRS-2676: Start of 'ora.mdnsd' on 'ol-alpha' succeeded
CRS-2676: Start of 'ora.evmd' on 'ol-alpha' succeeded
CRS-2672: Attempting to start 'ora.gpnpd' on 'ol-alpha'
CRS-2676: Start of 'ora.gpnpd' on 'ol-alpha' succeeded
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'ol-alpha'
CRS-2672: Attempting to start 'ora.gipcd' on 'ol-alpha'
CRS-2676: Start of 'ora.cssdmonitor' on 'ol-alpha' succeeded
CRS-2676: Start of 'ora.gipcd' on 'ol-alpha' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'ol-alpha'
CRS-2672: Attempting to start 'ora.diskmon' on 'ol-alpha'
CRS-2676: Start of 'ora.diskmon' on 'ol-alpha' succeeded
CRS-2676: Start of 'ora.cssd' on 'ol-alpha' succeeded
CRS-2672: Attempting to start 'ora.crf' on 'ol-alpha'
CRS-2672: Attempting to start 'ora.ctssd' on 'ol-alpha'
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'ol-alpha'
CRS-2676: Start of 'ora.crf' on 'ol-alpha' succeeded
CRS-2676: Start of 'ora.ctssd' on 'ol-alpha' succeeded
CRS-2676: Start of 'ora.cluster_interconnect.haip' on 'ol-alpha' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'ol-alpha'
CRS-2676: Start of 'ora.asm' on 'ol-alpha' succeeded
CRS-2672: Attempting to start 'ora.storage' on 'ol-alpha'
CRS-2676: Start of 'ora.storage' on 'ol-alpha' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'ol-alpha'
CRS-2676: Start of 'ora.crsd' on 'ol-alpha' succeeded
Then we must ensure ASM diskgroup is mounted. Login as 'sysasm'.
$
[grid@ol-alpha ~]$ su - grid
[grid@ol-alpha ~]$ sqlplus / as sysasm

select name, state from v$asm_diskgroup;

NAME                           STATE
------------------------------ -----------
OCRDG                          MOUNTED
Note: If you want to restore OCR to an ASM diskgroup, then you must first create a diskgroup using SQLPlus that has the same name as the diskgroup you want to restore and mount it on the local node.
In case, you can't mount the diskgroup locally, then try this:
SQL>
SQL> drop diskgroup <dg> force including contents ;
Before restoring, stop crs daemon otherwise we will encounter following error.
$<>  
[root@ol-alpha shanma-cluster]# ocrconfig -restore /u01/app/12.1.0/grid/cdata/shanma-cluster/backup_20170125_175506.ocr

PROT-19: Cannot proceed while the Cluster Ready Service is running
$
[root@ol-alpha shanma-cluster]# crsctl stop resource ora.crsd -init

CRS-2673: Attempting to stop 'ora.crsd' on 'ol-alpha'
CRS-2677: Stop of 'ora.crsd' on 'ol-alpha' succeeded
This time it should succeed:
CODE: $<>  
[root@ol-alpha shanma-cluster]# ocrconfig -restore /u01/app/12.1.0/grid/cdata/shanma-cluster/backup_20170125_175506.ocr
We need to stop the crs which is running in exclusive mode:
$
[root@ol-alpha shanma-cluster]# crsctl stop crs
Finally, we can manually restart the crs on all nodes:
$
[root@ol-alpha shanma-cluster]# crsctl start crs
$
[root@ol-beta shanma-cluster]# crsctl start crs
$
[root@ol-beta cdata]# crsctl check cluster -all

**************************************************************
ol-alpha:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
ol-beta:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
**************************************************************
Take the backup of OLR:
$
[root@ol-beta cdata]# ocrconfig -local -manualbackup
Note: Never make changes to the cluster configuration when a node is down. If you do so, you will need to use '-repair' option to repair the OCR. For example, if another OCR location was added while a node was down, to repair the OCR, use 'ocrconfig -repair' as shown below:
$
[root@ol-alpha shanma-cluster]# ocrconfig -repair -add /u01/app/oracle/ocr
Please write your comment if this article was useful.

Shannura

/
You might want to read this:
How to recover OCR from loss and recreate Votedisk?