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).
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:
- 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.
- By default, OLR is located at Grid_home/cdata/host_name.olr on each node.
- Oracle recommends that you use the -manualbackup and -restore commands and not the -import and -export commands.
- 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 FileThe olr.loc in 11gr2 is located in /etc/oracle or /var/opt/oracle. It depends of OS.
Example of the olr.loc file
Useful InformationOracle Documentation
Cluster startup ASM find spfile in ASM