11gR2 Clusterware :Oracle Local Registry (OLR)

In 11gR2, Oracle has introduced a new registry to maintain the clusterware resources (css, crs,evm,gip and more) in a new registry called Oracle Local Registry (OLR).
Multiple processes on each node have simultaneous read and write access to the OLR particular to the node on which they reside, regardless of whether Oracle Clusterware is running or fully functional.
By default, OLR is located at Grid_home/cdata/host_name.olr on each node.The OCR still exists, but maintains only the cluster resources.

Until Oracle Database 11gR1, the RAC configurations consisted of just one registry when running Oracle Clusterware. Shortly called OCR, Oracle Cluster Registry, maintained the cluster level resource information, privileges etc. To be precise, the OCR maintained information about 2 sets of node level resources, namely, the Oracle Clusterware Components (CRS, CSS, evm) as well as Cluster resources (DB, Listener etc).

Why this method

Before we get into this, we should see some of the improvements in Oracle 11gR2 RAC infrastructure. Until 11gR2, the CRS resources namely the OCR components and the voting disks were maintained in RAW or shared file systems. With the new 11gR2, the Oracle clusterware related files can be maintained in Oracle ASM (Automatic Storage Management). A feature that was introduced with Oracle 10g DB release. This ability to host OCR and Voting disks in ASM poses an interesting situation.
In order for the cluster resources to be up, the ASM needs to be up. If ASM needs to be up, the clusterware components should be functional. By having all the CRS and cluster resource information stored in OCR, this contradicting situation cannot be resolved unless somehow the cluster specific components detail is separately maintained from other resources/services.

As a solution, Oracle has come up with a new approach; the Oracle Local Registry. The Oracle Local registry maintains the node specific information and gets created with Oracle Clusterware installation of OCR. Since this maintains node specific resources, the clusterware components (crs,css,ctss,evm,gip, and asm) can be made available, with ASM being made available, this makes the OCR and voting disks access possible which eventually opens up the various cluster resources and components.

Without OLR, the clusterware resources will not start which in turn will not start the dependent components.

Important Notes for OLR:

1. 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. You should create a new backup when you migrate the OCR from Oracle ASM to other storage, or you migrate the OCR from other storage to Oracle ASM.
2. By default, OLR is located at Grid_home/cdata/host_name.olr on each node.
3. Oracle recommends that you use the -manualbackup and -restore commands and not the -import and -export commands.
4. When exporting OLR, Oracle recommends including "olr", the host name, and the timestamp in the name string.
   For example: olr_myhost1_20090603_0130_export

Information of the OLR:

A quick (dirty) peek at the olr shows the resources that are being maintained.

!DAEMON_TRACING_LEVELS
ora!asm
ora!crsd
ora!cssd
ora!cssdmonitor
ora!ctssd
ora!diskmon
ora!drivers!acfs
ora!evmd
ora!gipcd
ora!gpnpd
ora!mdnsd

Information of the OCR:

A quick (dirty) peek at the ocr shows the resources that are being maintained.

ora!LOCD
ora!locd!db
ora!LSNRGRID!lsnr
ora!LISTENER!lsnr
dora!FRADG!dg
fora!DATADG!dg
aora!linux2!vip
ora!oc4j
ora!LISTENER_SCAN1!lsnr
ora!scan1!vip
ora!registry!acfs
ora!CRS!dg
iora!asm
dora!eons
ora!ons
ora!gsd
ora!linux1!vip
ora!net1!network

Important File

The olr.loc in 11gr2 is located in /etc/oracle or /var/opt/oracle. It depends of OS.
Example of the olr.loc file

olrconfig_loc=/u01/rk/grid/cdata/rac1.olr
crs_home=/u01/rk/grid

Useful Information

Oracle Documentation
oracletechapp.blogspot.com
Cluster startup ASM find spfile in ASM