Oracle Local Registry ( OLR ) in Oracle 11g R2/12c

Oracle Local Registry ( OLR ) in Oracle 11g R2/12c :

With reference to my previous blog post of GPnP Profile , there are two new additional components have been introduced in Oracle Clusterware 11g R2, one is GPnP profile and another one is Oracle local registry ( OLR ). GPnP Profile , we have already discussed. Through this post, I shall try to put some view on OLR.

What is Oracle cluster registry ( OLR )?

OLR is an operating system file which resides on every node in the cluster and manages Oracle Clusterware configuration  information for each particular node. It contains manageability information about Oracle Clusterware, including dependencies between various services. Oracle High Availability Services (OHASD) uses these information. This file contains the local registry information of node specific resources and is not shared by other nodes in the cluster. It is installed and configured at the time of OCR installation during Oracle clusterware installation. OLR is similar to OCR in terms of internal structure because it stores information in keys. Same tool can be used either check or dump the data of OLR, which we used to check and dump OCR.

What is the Location of OLR file?

 OLR is located on local storage on each node in a cluster. Its default location is in the path $GRID_HOME/cdata/HOST_NAME.olr, where GRID_HOME is the Oracle Grid Infrastructure home, and HOST_NAME is the host name of the node. The location of OLR is stored in /etc/oracle/olr.loc and used by OHASD .

Why OLR Required ?

 Prior to Oracle Clusterware 11gR2, the OCR and the voting disks ( Both are main CRS resources ) , were maintained in RAW or shared file system. As I have mentioned above , starting with Oracle cluster 11gR2, the Oracle clusterware related files ( OCR and Voting Disks )  can be stored in Oracle ASM, so for making cluster resources to be up, the ASM needs to be up and started but  ASM itself  is a resource managed by OHASD , so If ASM needs to be up, the clusterware components (OCR) should be up . This produces a contradictory situation because all the CRS and cluster resource information stored in OCR and OCR stored in ASM.

So to resolve this contradictory situation Oracle come up with two new node specific files in Oracle Clusterware 11g R2 i.e. one is GPnP profile and another one is Oracle local registry ( OLR ), both files separately maintain cluster specific components detail from other resources and services. As I have already told OLR is an locally available file on operating system, so  there is no dependencies and this file could be read by any process with appropriate privileges.

How OLR Used by Oracle Clusterware 11g R2 ?

The High Availability Services stack consists of daemons that communicate with their peers on the other nodes. As soon as the High Availability Services stack is up, the cluster node can join the cluster and use the shared components (e.g., the OCR). The startup sequence of the High Availability Services stack is stored partly in the Grid Plug and Play profile, but that sequence also depends on information stored in the OLR.

The OLR stores important security contexts information used by the Oracle High Availability Service, initially in the start sequence of Clusterware. The information stored in the OLR is needed by the Oracle High Availability Services daemon (OHASD) to start, includes data about GPnP wallets, Clusterware configuration, and version information. The information in the OLR and the Grid Plug and Play configuration file are needed to locate the voting disks. If they are stored in ASM, the ASM discovery string stored in the GPnP profile will be used by the cluster synchronization daemon to look them up.

What Information Exist in OLR ?

There are some of the following information present in OLR:

• ORA_CRS_HOME
• Clusterware Version
• Clusterware Configuration
• Localhost Version
• Active Version
• GPnP profile Details
• OCR latest backup time and location
• Information about OCR daily, weekly backup location
• Node Name
• Status of resources of the node as in which to be started and which not
• Start & stop dependencies of resources , Start and Stop Dependencies are classified as,
  • Weak Dependency ( Means It Should fulfill)
  • Hard Dependency (Means It Must fulfill)

Why do we need OCR, If we have OLR?

Basically the information present in OLR deal with the OHASD process, whereas the information present in the OCR deal with the CRSD that means OHASD process mostly manages this OLR file. The OCR in turn is managed by the CRSD processes. This confirms that we need the OLR along with the GPnP profile, to start the Oracle High Availability Services stack.

If OLR is missing or corrupted then the clusterware resources will not start which in turn will not start the dependent components that means clusterware can’t be started on that node.

Hope, I have given above sufficient  theory to understand what is Oracle Local Registry ( OLR ) and what its purpose of existence in Oracle Clusterware 11g R2. In my next post , I will explain the command line tools to access OLR.

Thank you for Reading...!