In Oracle Clusterware 11g Release 2 an additional component related to the OCR called the Oracle Local Registry (OLR) is installed on each node in the cluster. The OLR is a local registry for node specific resources. THe OLR is not shared by other nodes in the cluster. It is installed and configured when Oracle clusterware is installed.
Purpose of OLR
It is the very first file that is accessed to startup  clusterware when OCR is stored on ASM. OCR should be accessible to find out the resources which need to be started on a node. If OCR is on ASM, it can’t be read until ASM (which itself is a resource for the node and this information is stored in OCR) is up. To resolve this problem, information about the resources which need to be started on a node is stored in an operating system  file which is called Oracle Local Registry or OLR. Since OLR is a file an operating system file, it can be accessed by various processes on the node for read/write irrespective of the status of the clusterware (up/down). Hence, when  a node joins the cluster,  OLR on that node is read, various resources ,including ASM  are started on the node  . Once ASM is up , OCR is accessible and is used henceforth to manage all the clusterware resources. If OLR is missing or corrupted, clusterware can’t be started on that node!
Where is OLR located?
The OLR file is located in the grid_home/cdata/<hostname>.olr . The location of OLR is stored in /etc/oracle/olr.loc.and used by OHASD .
What does OLR contain?
The OLR stores data about
  • localhost version
  • active version
  • GPnP details
  • OCR latest backup time and location
  • information about OCR daily, weekly backup location
  •  node name etc.
This information stored in the OLR is needed by OHASD to start or join a cluster.
A quick  peek at the backup of the olr shows the resources that are being maintained.
[root@host01 ~]# ocrconfig -local -manualbackup

host01     2013/01/18 01:20:27     /u01/app/11.2.0/grid/cdata/host01/backup_20130118_012027.olr

[root@host01 ~]# strings /u01/app/11.2.0/grid/cdata/host01/backup_20130118_012027.olr |grep -v type |grep ora!

 OLR administration
You can view the status of the OLR file on each node by using the ocrcheck command with the –local parameter as seen here:
#ocrcheck -local
ocrdump can be used to  dump the contents of the OLR to tthe text terminal:
#ocrdump -local -stdout
You can use the ocrconfig command to export and import the OLR as seen in these examples:
#ocrconfig -local -export <export file name >
#ocrconfig -local -import <file name>
And you can repair the OLR file should it become corrupted with the ocrconfig command as seen in this example:
#ocrconfig -local -repair olr <file name>
The OLR is backed up at the end of an installation or an upgrade. After that time, you can only manually back up the OLR. Automatic backups are not supported for the OLR.

To manually back up OLR:
# ocrconfig –local –manualbackup

To view the contents of the OLR backup file:
#ocrdump -local -backupfile olr_backup_file_name
To change the OLR backup location
#ocrconfig -local -backuploc new_olr_backup_path

To restore OLR: 
 # crsctl stop crs
# ocrconfig -local -restore file_name 
# ocrcheck -local 
# crsctl start crs 
$ cluvfy comp olr


    1. Hi

      Backup of OLR is automatically taken at the time of clusterware installation. SInce OLR is stored as an O/S file, it case of loss, it can be recovered from O/S backup.

      Anju Garg

  1. NO backup of OLR…how to recover it. what happend incase if i lost OLR 1) before starting cluster 2) after starting cluster.

  2. Hi Anju, Really Nice Blog , I have one query .

    who exactly reads the OLR file at the time of cluster start and which file comes first to read OLR or Profile.xm?

  3. Hello Anju, Really nice blogs on RAC. I had a confusion between the functionality of OLR and GPNPD profile but now it’s very clear to me.

    OLR :- Contains info about resources needed to be started on a node, is employed to provide the same info as was provided by OCR prior to 11g R2. Since OLR is stored locally on filesystem on each node, it contains info about resources specific to that node only. Once clusterware knows about the resources to be started, it needs additional info required to start those resources which is provided by gpnp profile.

    Thanks again for your efforts.

Leave a Reply to Anju Garg Cancel reply