In Oracle 11g Release 2, Oracle introduced the Oracle Local Registry (OLR), a new feature that complements the Oracle Cluster Registry (OCR) within the Grid Infrastructure. The OLR is an essential component stored locally on each node in the Grid Infrastructure home directory, specifically at 'grid_home/cdata/<hostname>.olr', with its location documented in '/etc/oracle/olr.loc'.
Each node maintains its unique OLR file within the Grid Infrastructure software home. The OLR contains critical security contexts required by the Oracle High Availability Service during the early stages of Clusterware startup. The data within the OLR is vital for the Oracle High Availability Services daemon (OHASD) to initialize, encompassing information about GPnP wallets, Clusterware configurations, and version details. This information, alongside the Grid Plug and Play (GPnP) configuration file, is crucial for locating the voting disks. If these disks are stored in ASM, the GPnP profile’s discovery string will be used by the cluster synchronization daemon for their retrieval.
In this post, I'll delve into the purpose of the OLR, its necessity, and the type of data it contains. To fully understand these aspects, we need to examine the contents of an OLR dump:
I've tried to format the output for clarity. The OLR contains extensive information, including ORA_CRS_HOME, Clusterware versions, configurations, local host versions, active versions, GPnP details, OCR latest backup times and locations, node names, and the status of node resources—whether they need to start or not—and the start & stop dependencies of these resources. These dependencies are classified as either weak (optional) or hard (mandatory).
Understanding the purpose of the OLR is crucial. Although the OCR needs to be accessible by Clusterware to determine which resources to start on a node, Oracle 11gR2 allows the OCR to be stored in ASM. This poses a challenge because ASM itself is a resource that must be started. Here, the OLR comes into play. Being a locally available file on the operating system, the OLR can be read by any process with the appropriate privileges, without any dependencies.
The High Availability Services stack comprises daemons that communicate with their counterparts on other nodes. Once the High Availability Services stack is operational, the cluster node can join the cluster and use shared components like the OCR. Part of the startup sequence for the High Availability Services stack is stored in the GPnP profile, but it also relies on information from the OLR.
A pertinent question is why OCR is still needed if we have OLR. Comparing the OLR and OCR reveals that the OLR contains fewer keys. For example, an 'ocrdump' might show 704 keys for the OCR versus 526 keys for the OLR. Most keys in the OLR pertain to the OHASD process, while those in the OCR are related to CRSD. This indicates the necessity of the OLR (along with the GPnP profile) for starting the High Availability Services stack.
I hope this explanation helps you understand the OLR, its purpose, its content, and why it is essential.
I hope this article helped you. Your suggestions/feedback are most welcome.
Keep learning... Have a great day!!!
Thank you,
Amit Pawar
Email: amitpawar.dba@gmail.com
WhatsApp No: +91-8454841011
