With 11gr2 Oracle introduced Oracle Local Registry (OLR), OLR is the OCR’s local counterpart and a new feature introduced with Grid Infrastructure. The OLR file is located in the grid_home/cdata/<hostname>.olr & the location of OLR is stored in /etc/oracle/olr.loc. Each node has its own copy of the file in the Grid Infrastructure software home. The OLR stores important security contexts used by the Oracle High Availability Service early in the start sequence of Clusterware. The information stored in the OLR is needed by the Oracle High Availability Services
daemon (OHASD) to start; this 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 discovery string in the GPnP profile will
be used by the cluster synchronization daemon to look them up.

In the following post I’ll try to describe the purpose of OLR, why Oracle has to come up with this file, what is stored in this file.
To understand all these questions we need to understand what it contains, hence taking dump of OLR

ocrdump -local -stdout

[SYSTEM]
[SYSTEM.version]
[SYSTEM.version.activeversion]
[SYSTEM.version.hostnames.rac1]
[SYSTEM.version.hostnames.rac2]
[SYSTEM.ORA_CRS_HOME]
[SYSTEM.evm]
[SYSTEM.GPnP.profiles]
[SYSTEM.CRSADMIN]
[SYSTEM.CRSUSER]
[SYSTEM.CRSD]
[SYSTEM.CRSD.SERVERPOOLS]
[SYSTEM.CRSD.SERVERS]
[SYSTEM.CRSD.SERVERS.rac1.STATE]
[SYSTEM.CRSD.TYPES]
[SYSTEM.CRSD.TYPES.ora!local_resource!type.START_DEPENDENCIES]
[SYSTEM.CRSD.TYPES.ora!local_resource!type.START_DEPENDENCIES.CONFIG]
[SYSTEM.CRSD.TYPES.ora!local_resource!type.STOP_DEPENDENCIES]
[SYSTEM.CRSD.TYPES.ora!local_resource!type.STOP_DEPENDENCIES.CONFIG]
[SYSTEM.CRSD.TYPES.ora!network!type]
[SYSTEM.CRSD.TYPES.ora!cluster_resource!type.AUTO_START]
[SYSTEM.CRSD.TYPES.ora!database!type.INSTANCE_FAILOVER]
[SYSTEM.CRSD.TYPES.ora!database!type.ORACLE_HOME]
[SYSTEM.CRSD.RESOURCES.ora!net1!network]
[SYSTEM.CRSD.RESOURCES.ora!gsd]
[SYSTEM.CRSD.RESOURCES.ora!LISTENER_SCAN1!lsnr.INTERNAL]
[SYSTEM.CRSD.RESOURCES.ora!LISTENER_SCAN2!lsnr]
[SYSTEM.CRSD.RESOURCES.ora!oc4j]
[SYSTEM.CRSD.RESOURCES.ora!rac2!vip.INTERNAL]
[SYSTEM.CRSD.RESOURCES.ora!LISTENER!lsnr.INTERNAL]
[SYSTEM.CRSD.RESOURCES.ora!orcl!db.INTERNAL]
[DATABASE.NODEAPPS.rac2]
[DATABASE.VIP_RANGE]
[DATABASE.ASM]
[DATABASE.ASM.rac1.+asm1.VERSION]
[DATABASE.ASM.rac2.+asm2.ORACLE_HOME]
[CRS]
[CRS.CUR]
[CRS.HIS]
[CRS.SEC]
[CRS.STAGE]
[CRS.STAGE.node1]

I tried to format the output as much as I can for detailed output click here OLR Dump, the point here is to understand that there is a lot of information present in OLR like ORA_CRS_HOME, Clusterware version, Clusterware configuration, localhost version, activeversion, GPnP details, OCR latest backup time and location, node name, status of resources of the node as in which to be started and which not, and also the start & stop dependencies of resources etc.
Start & Stop Dependencies are classified as weak (Should fulfill) & hard (Must fulfill).

Now we’ll understand the purpose of this file, we know that OCR needs to be accessible by Clusterware to know which resources to be started on a node, but as from 11gr2, Oracle has given the luxury to store OCR in ASM how does Clusterware accesses this information while ASM (which itself is a resource for the node) is Down, here comes the OLR. Since OLR is an locally available file on operating system there is no dependencies and this file could be read by any process with appropriate privileges.

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.

Now the question that comes to our mind is if we have OLR then why do we need OCR, to explain this we compared the keys of OLR & OCR.
Comparing the OCR with the OLR reveals that the OLR has far fewer keys; for example, ocrdump reported 704 different keys for the OCR vs. 526 keys for the OLR on our installation. If you compare only the keys again, you will notice that the majority of keys in the OLR deal with the OHASD process, whereas the majority of keys in the OCR deal with the CRSD. This confirms that you need the OLR (along with the GPnP profile) to start the High Availability Services stack.

I hope the above information helps you in understanding OLR, its purpose, its content, its usage and why was it required. Please comment below if you need more information as in the complete dump of OLR, the description of all the components & keys, how OHASD manages and maintains OLR on all the nodes, how is the content updated when you alter any Clusterware configuration of a node, what happens when OLR is lost or corrupted, how is OLR initialized, etc.

 

Related Articles:-

GPnP Profile Internals

Network & Disk Heartbeat

OCR Internals

OLR Internals

SCAN Internals

Split Brain

Voting Disk Internals