Oracle RAC 19c Masterclass – Part 9

Oracle Local Registry (OLR): The First Component Every RAC Node Reads

Throughout this series, we’ve explored several critical Oracle RAC components:

• Oracle Clusterware
• ASM
• OCR
• Voting Disks
• GPnP

All of these depend on one small but essential component that many DBAs overlook: the Oracle Local Registry (OLR).

Unlike the OCR, which is shared across the cluster, the OLR exists on every RAC node and is the very first Oracle configuration file accessed during node startup.

Without the OLR, Oracle High Availability Services (OHAS) cannot initialize, and the RAC startup sequence stops before Clusterware can even locate ASM or the OCR.

In this article, we’ll examine the OLR architecture, its role in the startup process, and how to diagnose and recover OLR-related issues.

What is the Oracle Local Registry (OLR)?

The Oracle Local Registry (OLR) is a local repository that stores configuration information required to start Oracle High Availability Services (OHAS) on an individual node.

Unlike the OCR:

• Every node has its own OLR.
• The OLR is not shared.
• The OLR resides on the local filesystem.
• It is used before ASM and the OCR become available.

Why Does Oracle Need the OLR?

Consider what happens during a server reboot.

At this stage:

• ASM is not running.
• OCR is not accessible.
• Voting Disks have not been opened.

So how does Oracle know where to begin?

The answer is simple:

The node starts by reading its own OLR.

Startup Sequence

The startup order looks like this:

Linux
   |
   v
Oracle High Availability Services (OHASD)
   |
   v
Oracle Local Registry (OLR)
   |
   v
GPnP Profile
   |
   v
ASM
   |
   v
OCR
   |
   v
CSSD
   |
   v
CRSD
   |
   v
Database Resources

The OLR is the bridge between the operating system and the Clusterware stack.

OCR vs OLR

This is one of the most common interview questions for RAC administrators.

OCR	OLR
Shared across all nodes	Local to one node
Stored in ASM	Stored on the local filesystem
Contains cluster configuration	Contains node startup configuration
Used after ASM starts	Used before ASM starts
Managed by CRSD	Used by OHASD

A simple rule to remember:

OLR starts the node. OCR manages the cluster.

Where is the OLR Stored?

Unlike the OCR, which is usually stored in ASM, the OLR resides on the local operating system.

Check its location:

ocrcheck -local

Example:

Oracle Local Registry configuration is:
Device/File Name : /u01/app/grid/cdata/racnode1.olr

Since the OLR is local, each RAC node has its own independent copy.

Viewing OLR Status

Verify the local registry:

ocrcheck -local

Example:

Oracle Local Registry integrity check succeeded.

This command checks:

• Accessibility
• Integrity
• Basic consistency

It’s often the first command to run when investigating startup issues on a single node.

OLR Contents

The OLR stores information such as:

• Local Clusterware configuration
• Local resource definitions
• Node-specific startup parameters
• OHAS configuration
• GPnP initialization details

It does not store:

• Database objects
• ASM metadata
• Cluster-wide resources
• User data

Viewing Local Resources

Many Clusterware resources are local to a node.

Display local resources:

crsctl stat res -t -init

Example:

ora.asm
ora.cssd
ora.diskmon
ora.evmd
ora.gpnpd
ora.mdnsd
ora.ohasd

These are initialized before the full Clusterware stack is available.

OLR Backup

Oracle automatically maintains the OLR, but it can also be backed up manually.

Example:

ocrconfig -local -manualbackup

Verify backups:

ocrconfig -local -showbackup

Although manual backups are less common than OCR backups, creating one before significant Grid Infrastructure maintenance is a sensible precaution.

OLR Recovery

If the OLR becomes corrupted:

Symptoms may include:

• OHAS fails to start.
• CRS stack never initializes.
• GPnP cannot be loaded.
• ASM never starts.

A recovery may involve restoring the OLR from a valid backup using Oracle recovery procedures appropriate for your Grid Infrastructure version.

Because the OLR is local to a node, recovery generally affects only that node rather than the entire cluster.

Useful OLR Commands

Check OLR:

ocrcheck -local

Backup OLR:

ocrconfig -local -manualbackup

Display backups:

ocrconfig -local -showbackup

View local resources:

crsctl stat res -t -init

These are the commands you’ll use most frequently when working with the OLR.

Common OLR Problems

OLR Corruption

Symptoms:

• OHAS does not start.
• CRS stack unavailable.
• Startup stops very early.

Verify:

ocrcheck -local

Missing OLR File

Symptoms:

• Grid Infrastructure startup fails immediately.

Possible causes:

• File system corruption
• Accidental deletion
• Disk failure

Investigate the operating system logs before attempting recovery.

Permission Problems

Symptoms:

• OLR commands fail.
• OHAS startup errors.

Verify ownership:

ls -l /u01/app/grid/cdata

Ensure the Grid Infrastructure files are owned by the correct operating system user and groups.

Local Filesystem Failure

Because the OLR resides locally, failures affecting the local filesystem can prevent Clusterware from starting even if ASM and shared storage are healthy.

OLR and Troubleshooting

Suppose Node 2 does not start after a reboot.

A logical troubleshooting sequence is:

1. Verify Linux booted successfully.
2. Check whether OHAS is running.

crsctl check has

3. Verify the OLR.

ocrcheck -local

4. Review GPnP logs.
5. Verify ASM startup.
6. Check OCR accessibility.

Following this order prevents unnecessary troubleshooting of higher-level components when the problem exists at the beginning of the startup chain.

OLR Log Files

Useful log locations include:

$GRID_HOME/log/<hostname>/ohasd

Example:

ohasd.log

Additional startup information can be found under:

$GRID_HOME/log/<hostname>

Review these logs for:

• Startup failures
• Configuration errors
• Missing files
• Permission issues

Production Scenario

A customer reported that only one node in a two-node RAC cluster failed to start after an unexpected operating system crash.

The shared storage was healthy.

ASM was healthy.

The OCR was healthy.

However, crsctl check has returned an error.

Running:

ocrcheck -local

revealed that the OLR on the affected node had become corrupted following the filesystem issue.

After restoring the OLR from backup and restarting OHAS, the node rejoined the cluster successfully.

The remaining node had continued processing the workload throughout the incident because its own OLR was unaffected.

Best Practices

• Include ocrcheck -local in RAC health-check scripts.
• Create an OLR backup before major Grid Infrastructure maintenance.
• Protect the local filesystem with appropriate redundancy.
• Monitor OHAS startup logs after operating system changes.
• Never edit OLR files manually.
• Follow Oracle-supported recovery procedures when restoring the OLR.

DBA Tip

One of the easiest ways to save time during RAC troubleshooting is to determine whether the problem affects one node or the entire cluster.

• If every node is affected, investigate shared components such as ASM, OCR, or Voting Disks.
• If only one node fails to start, begin with the local components: the operating system, the OLR, OHAS, and GPnP.

This simple distinction often narrows the investigation from dozens of possibilities to just a few.

Shared problems usually point to shared components. Single-node problems usually begin with local components.

Conclusion

The Oracle Local Registry is one of the smallest components in Oracle RAC, but it performs one of the most important jobs. It enables Oracle High Availability Services to start, allowing the node to discover ASM, locate the OCR, and eventually join the cluster.

Although most administrators rarely interact directly with the OLR, understanding its role provides valuable insight into the RAC startup sequence and helps diagnose early-stage Clusterware failures with confidence.