11gR2 Oracle Local Registry

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).

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). The OCR still exists, but maintains only the cluster resources.

Why this distinction?

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 sepcific 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.

NOTE: OLR has to be *manually* backed up. There is no support for an automatic backup of OLR.

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

[root@linux2 linux2]# strings -a backup_20100422_152429.olr| grep ! | sort -u| grep -v type
!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


A similar peek at the OCR backup file shows:

[root@linux2 racnode-cluster]# strings -a backup_20100423_091503.ocr| grep -v type | grep ora!
ora!GREEN
ora!DATARAC10G!dg
ora!OLDSTYLE!lsnr
ora!LTEST!lsnr
ora!green!db
ora!LSNRGRID!lsnr
ora!LISTENERCUSTOM!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