OCR Internals

With Oracle Grid Infrastructure 11gr2, Oracle ASM and Oracle Clusterware are installed into a single home directory known as Grid Infrastructure Home.
Oracle Clusterware consists of 2 stacks:-
1) The Cluster Ready Service Stack ( CRS Stack ) :- It manages (start, stop, monitor, and failover operations) the cluster resources based on the configuration information stored in OCR for each resource.
2) The Oracle High Availability Service Stack:- It is responsible for monitoring and maintaining high availability of Oracle ASM and Clusterware itself.

The Oracle Cluster Registry (OCR) file is a key component of Oracle Clusterware. It maintains information about the high-availability components in your cluster, such as the voting file details, cluster database instance to node mapping, and CRS application resource profiles (such as services, Virtual Interconnect Protocol addresses, and so on),Above highlighted information and the part of dump is to just give you an idea about how the information is stored in OCR. In reality OCR uses a file based repository to store configuration information in a series of key-value pairs using a directory tree like structure. So now after scanning the whole dump I can say that the OCR contains information about the resources controlled by Oracle Clusterware, including the following:

RAC databases and instances
SCAN listeners and local listeners
SCAN VIPs and local VIPs
Nodes and node apps types
ASM disk groups, volumes, file systems, and instances
OCRs Automatic and Manual backups information

Now that we have understood what is inside OCR the next natural curiosity is who maintains OCR who updates all this information in OCR, the answer is CRSd Process (and CSSd only during cluster startup), so even if you modify OCR via SRVCTL, CRSCTL, EM etc they communicate via CRSd. To explain this we need to know that Oracle uses a distributed shared cache architecture during cluster management to optimize queries against the cluster repository i.e. each node maintains a copy of the OCR in memory. Only one CRSd process (designated as the master) in the cluster performs any disk read/write activity. This master CRSd process refreshes the OCR cache on all cluster nodes. Clients (SRVCTL, CRSCTL etc) communicate with the local CRSd process to access the local copy of the OCR and contact the master CRSd process via the local CRSd process for any updates on the physical OCR binary file.

Because of this concept it is said that one should not modify OCR while any node is down ( as CRSd is down for that node ), so if need arises that one has to change the configuration in OCR when any node is down then a manual repair on the stopped node should be performed.

OCR and voting disks can be stored in Oracle ASM because the ASM’s partnership and status table is replicated on multiple disks and is extended to store OCR, the OCR can tolerate the loss of the same number of disks as are in the underlying disk group and can be relocated in response to disk failures.