🔧 Understanding OCR Primary and Secondary Files in Oracle RAC – A Deep Dive

Oracle RAC (Real Application Clusters) provides high availability and scalability by allowing multiple nodes (servers) to access a single database instance concurrently. A key component of Oracle RAC's underlying infrastructure is the Oracle Cluster Registry (OCR).

In this blog, we will explore:

• What OCR is
• How OCR files are structured (Primary and Secondary)
• The architecture of node writes to OCR
• An example to understand which node performs writes
• Best practices and commands to verify OCR configuration

📘 What is OCR?

The Oracle Cluster Registry (OCR) is a critical component of Oracle Clusterware. It stores important metadata and configuration information used by Clusterware, such as:

• Cluster node membership
• Cluster resource configurations (VIPs, SCANs, services, etc.)
• ASM configuration
• Voting disk locations
• Oracle Home inventory
• Dependency relationships among resources

Without a functioning OCR, Clusterware cannot start or operate.

📂 Primary and Secondary OCR Files – What’s the Deal?

Oracle RAC ensures high availability of the OCR by maintaining more than one copy:

OCR Type	Description
Primary	The main OCR file used by Clusterware for reads/writes.
Secondary (Mirror)	Acts as a backup or mirror to provide redundancy.

✅ Default Behavior

During Grid Infrastructure installation:

• Oracle automatically creates one primary OCR.
• It prompts to create a mirrored (secondary) OCR.
• You can configure up to 5 OCR locations (1 primary + 4 mirrors).

Examples:

Primary OCR     : +DATA
Secondary OCR   : +FRA

Primary OCR     : /dev/raw/raw1
Secondary OCR   : /dev/raw/raw2

🧱 OCR Architecture – Who Writes to the OCR?

🧠 The Concept of the "Master Node"

Oracle Clusterware uses a master node architecture to coordinate OCR updates.

• At any given time, only one node in the cluster (designated as the OCR master) performs write operations to the OCR.
• All other nodes read from OCR but do not write.
• The master is elected based on internal logic and voting mechanisms.

🔄 OCR Master Role Fails Over

If the OCR master node crashes or is rebooted:

• Another node is elected as the new OCR master.
• This ensures continuous cluster operations without interruption.

🔍 Example: 3-Node RAC Cluster

Assume we have a 3-node RAC cluster:

Node	Role	Can Write to OCR?
node1	OCR Master	✅ Yes
node2	Member	❌ No
node3	Member	❌ No

Scenario:

A DBA adds a new service using srvctl add service on node2.

What happens?

1. node2 sends the configuration update to the OCR master (node1).
2. node1 writes the update to the primary OCR (+DATA), and then to the mirror (+FRA).
3. Both copies are updated atomically.

If node1 crashes:

• Clusterware elects a new OCR master (e.g., node2).
• node2 now handles all subsequent OCR writes.

🧪 How to Check OCR Locations

Use the following command to check OCR configuration:

ocrcheck

Sample output:

OCR integrity check succeeded

Device/File Name         : +DATA
Device/File integrity check succeeded

Device/File Name         : +FRA
Device/File integrity check succeeded

🛡 Best Practices

• ✅ Always use mirrored OCR for high availability.
• 🛠 Do not manually edit OCR files – use Oracle tools (srvctl, crsctl).
• 📦 Keep OCR on highly available storage – e.g., ASM with Normal/High Redundancy.
• 🔄 Regularly backup OCR using:

  ocrconfig -manualbackup

• Or verify automatic backups in:

  $GRID_HOME/cdata/<cluster_name>

🧭 Conclusion

The Oracle Cluster Registry (OCR) is the heart of Oracle Clusterware, and understanding its primary/mirror file structure is vital for any Oracle DBA working with RAC.

By design:

• Only one node (OCR master) performs writes to the OCR at any given time.
• The master role is highly available and automatically managed.
• Mirroring ensures that the cluster survives individual file or disk failures.

Keep your OCR protected and monitored — and your cluster will thank you!