OCR , OLR

 ORACLE LOCAL REGISTRY(OLR) contains node-specific information required by OHASD . Every node has its own dedicated OLR file.(not shared between the nodes).

As OCRs files are present in ASM diskgroup, While starting the CRS, it wont be able to Access OCR file to find the cluster resource information.

Because at this point ASM instance would also be down. So at this point OLR file ( which is present at normal file system) is accessed to start the required resources to start CRS

1. The default location of OLR:                  $GRID_HOME/cdata/*olr

2.View the available backups of OLR:     $GRID_HOME/bin/ocrconfig -local -showbackup

3. Take the backup of OLR manually: ( Need to done from ROOT user)

root# /crsapp/app/oracle/product/grid12c/bin/ocrconfig -local -manualbackup

 4. Verify integrity of the OLR

cluvfy comp olr

 5. Check the current OLR location:

$GRID_HOME/bin/ocrcheck -local

6. View OLR in text format:

$GRID_HOME/bin/ocrdump -local -stdout

 

OCR (Oracle Cluster Registry)

OCR will have all the cluster information. If the OCR is loss, the entire cluster will be affected. OCR is the central repository which stores the metadata, configuration, status of the clusterware resources.OCR is used to maintain application.resources and availability.It also stores configuration information for CRS daemons and clusterware managed applications.

Below are the information stored in the OCR.

·        Node membership information ex: which nodes are the part of the cluster

·        Software active version

·        Server pools

·        Status/Configuration for the cluster resources such as RAC databases, listeners, instances and services

·        ASM instance and disk groups

·        CRS application resource profiles such as VIP addresses etc..

·        Database services characteristics e.g preferred/available nodes, TAF, Load balancing, goal etc..

·        Information about clusterware processes

·        Information about interaction and management about third party applications controlled by clusterware

·        Details about network interfaces

·        Information about OCR backups

In Oracle Clusterware 11g Release 2 an additional component related to the OCR called the Oracle Local Registry (OLR)

You can view the status of the OLR file on each node by using the ocrcheck command with the –local parameter as seen here:

#ocrcheck -local

ocrdump can be used to dump the contents of the OLR to tthe text terminal:

#ocrdump -local -stdout

You can use the ocrconfig command to export and import the OLR as seen in these examples:

#ocrconfig -local -export <export file name >

#ocrconfig -local -import <file name>

And you can repair the OLR file should it become corrupted with the ocrconfig command as seen in this example:

#ocrconfig -local -repair olr <file name>

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.

To manually back up OLR:

# ocrconfig –local –manualbackup

To view the contents of the OLR backup file:

#ocrdump -local -backupfile olr_backup_file_name

To change the OLR backup location

#ocrconfig -local -backuploc new_olr_backup_path

To restore OLR:

 # crsctl stop crs

# ocrconfig -local -restore file_name

# ocrcheck -local

# crsctl start crs

$ cluvfy comp olr

Purpose of OLR

————–

It is the very first file that is accessed to startup clusterware when OCR is stored on ASM. OCR should be accessible to find out the resources

which need to be started on a node. If OCR is on ASM, it can’t be read until ASM (which itself is a resource for the node and this information is

stored in OCR) is up. To resolve this problem, information about the resources which need to be started on a node is stored in an operating system 

file which is called Oracle Local Registry or OLR. Since OLR is a file an operating system file, it can be accessed by various processes on the node

for read/write irrespective of the status of the clusterware (up/down). Hence, when a node joins the cluster, OLR on that node is read, various

resources ,including ASM are started on the node . Once ASM is up , OCR is accessible and is used henceforth to manage all the clusterware

resources. If OLR is missing or corrupted, clusterware can’t be started on that node!

Where is OLR located?

———————

The OLR file is located in the grid_home/cdata/<hostname>.olr . The location of OLR is stored in /etc/oracle/olr.loc.and used by OHASD .

What does OLR contain?

———————-

The OLR stores data about

ORA_CRS_HOME

localhost version

active version

GPnP details

OCR latest backup time and location

information about OCR daily, weekly backup location

 node name etc.

This information stored in the OLR is needed by OHASD to start or join a cluster.

A quick peek at the backup of the olr shows the resources that are being maintained.

[root@host01 ~]# ocrconfig -local -manualbackup

host01    2013/01/18 01:20:27    /u01/app/11.2.0/grid/cdata/host01/backup_20130118_012027.olr

[root@host01 ~]# strings /u01/app/11.2.0/grid/cdata/host01/backup_20130118_012027.olr |grep -v type |grep ora!

ora!drivers!acfs

ora!crsd

ora!asm

ora!evmd

ora!ctssd

ora!cssd

ora!cssdmonitor

ora!diskmon

ora!gpnpd

ora!gipcd

ora!mdnsd

 It is the very first file that is accessed to startup clusterware as/when OCR is stored on ASM.

Source : Linkedin Article