ORL Internal in Oracle RAC

 

OLR Internal

With 11gr2 Oracle introduced Oracle Local Registry (OLR), OLR is the OCR’s local counterpart and a new feature introduced with Grid Infrastructure. 

The OLR file is located in the grid_home/cdata/<hostname>.olr & 

the location of OLR is stored in /etc/oracle/olr.loc. 

Each node has its own copy of the file in the Grid Infrastructure software home. 

The OLR stores important security contexts used by the Oracle High Availability Service early in the start sequence of Clusterware. 

The information stored in the OLR is needed by the Oracle High Availability Services daemon (OHASD) to start; this includes data about GPnP wallets, Clusterware configuration, and version information. 

The information in the OLR and the Grid Plug and Play configuration file are needed to locate the voting disks. 

If they are stored in ASM, the discovery string in the GPnP profile will be used by the cluster synchronization daemon to look them up.

In the following post I’ll try to describe the purpose of OLR, why Oracle has to come up with this file, what is stored in this file.

To understand all these questions we need to understand what it contains, hence taking dump of OLR

ocrdump -local -stdout

[SYSTEM]
[SYSTEM.version]
[SYSTEM.version.activeversion]
[SYSTEM.version.hostnames.rac1]
[SYSTEM.version.hostnames.rac2]
[SYSTEM.ORA_CRS_HOME]
[SYSTEM.evm]
[SYSTEM.GPnP.profiles]
[SYSTEM.CRSADMIN]
[SYSTEM.CRSUSER]
[SYSTEM.CRSD]
[SYSTEM.CRSD.SERVERPOOLS]
[SYSTEM.CRSD.SERVERS]
[SYSTEM.CRSD.SERVERS.rac1.STATE]
[SYSTEM.CRSD.TYPES]
[SYSTEM.CRSD.TYPES.ora!local_resource!type.START_DEPENDENCIES]
[SYSTEM.CRSD.TYPES.ora!local_resource!type.START_DEPENDENCIES.CONFIG]
[SYSTEM.CRSD.TYPES.ora!local_resource!type.STOP_DEPENDENCIES]
[SYSTEM.CRSD.TYPES.ora!local_resource!type.STOP_DEPENDENCIES.CONFIG]
[SYSTEM.CRSD.TYPES.ora!network!type]
[SYSTEM.CRSD.TYPES.ora!cluster_resource!type.AUTO_START]
[SYSTEM.CRSD.TYPES.ora!database!type.INSTANCE_FAILOVER]
[SYSTEM.CRSD.TYPES.ora!database!type.ORACLE_HOME]
[SYSTEM.CRSD.RESOURCES.ora!net1!network]
[SYSTEM.CRSD.RESOURCES.ora!gsd]
[SYSTEM.CRSD.RESOURCES.ora!LISTENER_SCAN1!lsnr.INTERNAL]
[SYSTEM.CRSD.RESOURCES.ora!LISTENER_SCAN2!lsnr]
[SYSTEM.CRSD.RESOURCES.ora!oc4j]
[SYSTEM.CRSD.RESOURCES.ora!rac2!vip.INTERNAL]
[SYSTEM.CRSD.RESOURCES.ora!LISTENER!lsnr.INTERNAL]
[SYSTEM.CRSD.RESOURCES.ora!orcl!db.INTERNAL]
[DATABASE.NODEAPPS.rac2]
[DATABASE.VIP_RANGE]
[DATABASE.ASM]
[DATABASE.ASM.rac1.+asm1.VERSION]
[DATABASE.ASM.rac2.+asm2.ORACLE_HOME]
[CRS]
[CRS.CUR]
[CRS.HIS]
[CRS.SEC]
[CRS.STAGE]
[CRS.STAGE.node1]

I tried to format the output as much as I can for detailed output click here OLR Dump, the point here is to understand that there is a lot of information present in OLR like ---->

1) ORA_CRS_HOME, 2)Clusterware version, 3) Clusterware configuration, 4) localhost version, 5)activeversion, 6) GPnP details,     7) OCR latest backup time and location, 8) node name, 9) status of resources of the node as in which to be started and which not, and also 10) the start & stop dependencies of resources etc.

Start & Stop Dependencies are classified as weak (Should fulfill) & hard (Must fulfill).

Now we’ll understand the purpose of this file, we know that OCR needs to be accessible by Clusterware to know which resources to be started on a node, but as from 11gr2, Oracle has given the luxury to store OCR in ASM how does Clusterware accesses this information while ASM (which itself is a resource for the node) is Down, here comes the OLR.

 Since OLR is an locally available file on operating system there is no dependencies and this file could be read by any process with appropriate privileges.

The High Availability Services stack consists of daemons that communicate with their peers on the other nodes. 

As soon as the High Availability Services stack is up, the cluster node can join the cluster and use the shared components (e.g., the OCR). 

The startup sequence of the High Availability Services stack is stored partly in the Grid Plug and Play profile, but that sequence also depends on information stored in the OLR.

Now the question that comes to our mind is if we have OLR then why do we need OCR, to explain this we compared the keys of OLR & OCR.

Comparing the OCR with the OLR reveals that the OLR has far fewer keys; for example, ocrdump reported 704 different keys for the OCR vs. 526 keys for the OLR on our installation. 

If you compare only the keys again, you will notice that the majority of keys in the OLR deal with the OHASD process, whereas the majority of keys in the OCR deal with the CRSD. 

This confirms that you need the OLR (along with the GPnP profile) to start the High Availability Services stack.

1. Management and Maintenance of OLR by OHASD

• The Oracle Local Registry (OLR) is a local configuration file on each node that contains node-specific information necessary to start and manage Oracle Clusterware processes, independent of the shared Oracle Cluster Registry (OCR).
• OHASD is the first component started in Oracle Clusterware and relies on the OLR to retrieve essential local configuration data to bootstrap the local node's services, especially before the OCR becomes accessible.
• The OLR is stored locally (typically in $GRID_HOME/cdata/<hostname>/olr.<hostname>.dat), and OHASD directly reads from it to initialize services like the Cluster Synchronization Services Daemon (CSSD) and Cluster Ready Services (CRS) on each node.

2. Updating OLR Content during Configuration Changes

• Any changes made to the Oracle Clusterware configuration that impact node-specific settings will also trigger updates in the OLR.
• For example, adding new resources, modifying the node network settings, or changing service start/stop configurations on a particular node might require the OLR to be updated with the latest node-specific settings.
• Process for Updating OLR:
• Changes are generally first made in the Oracle Cluster Registry (OCR), which is the cluster-wide registry for shared configuration data.
• OHASD periodically synchronizes relevant parts of the OCR with the OLR on each node.
• For real-time or critical updates, OHASD can directly apply necessary configuration changes to the OLR, ensuring the local node’s configuration is up to date.

3. What Happens When OLR is Lost or Corrupted

• Loss or Corruption: If the OLR file becomes corrupted or is accidentally deleted, the local node may face issues starting Oracle Clusterware services, as OHASD relies on the OLR during initialization.
• Recovery from OLR Backup:
  • OHASD maintains automatic backups of the OLR at regular intervals (typically in $GRID_HOME/cdata/<hostname>/olr_backup.<timestamp>.dat).
  • If the OLR is corrupted, OHASD can attempt to restore the most recent valid backup.
• Manual Restoration:
• If automatic recovery is not possible, a DBA can manually restore the OLR from a backup file.
• In some cases, it may be necessary to recreate the OLR by running the ocrconfig -local command, which regenerates the OLR using information from the OCR.

4. Initialization of OLR

• The OLR is initialized during the Oracle Grid Infrastructure installation. When Grid Infrastructure is installed on a node, Oracle automatically creates the OLR file with the essential node-specific configuration settings.
• During the initialization, the OLR is populated with information about local resources, node name, and necessary metadata that OHASD needs to bootstrap the local services.
• OHASD Initialization:
  • Upon system boot, OHASD starts and reads from the OLR to load initial configurations for essential Clusterware services.
  • OHASD can then start other components like CSSD and CRS using the OLR’s node-specific configuration data, enabling these services to function even if shared storage (and therefore OCR) is temporarily inaccessible.

Summary

In summary:

• OHASD manages and maintains the OLR on each node to ensure the node-specific configuration is accessible during Clusterware startup.

• When cluster configuration changes are made, relevant updates are synchronized from the OCR to the OLR.

• If the OLR is lost or corrupted, OHASD can restore it from an automatic backup, or a DBA can manually recreate it if necessary.

• The OLR is initialized during Oracle Grid Infrastructure installation, allowing OHASD to read node-specific configurations during Clusterware startup, ensuring that each node operates independently until it can access the shared OCR.