Skip to main content

🔧 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!

Labels:

Comments

Post a Comment

Popular posts from this blog

🚀 Automating Oracle Database Patching with Ansible: A Complete Guide

Oracle database patching has long been the bane of DBAs everywhere. It's a critical task that requires precision, expertise, and often results in extended maintenance windows. What if I told you that you could automate this entire process, reducing both risk and downtime while ensuring consistency across your Oracle estate? 💡 In this comprehensive guide, I'll walk you through a production-ready Ansible playbook that completely automates Oracle patch application using OPatch. Whether you're managing a single Oracle instance or hundreds of databases across your enterprise, this solution will transform your patch management strategy! 🎯 🔥 The Challenge: Why Oracle Patching is Complex Before diving into the solution, let's understand why Oracle patching is so challenging: 🔗 Multiple dependencies : OPatch versions, Oracle Home configurations, running processes ⚠️ Risk of corruption : Incorrect patch application can render databases unusable ⏰ Downtime requirements : Da...
Post a Comment
Read more

Oracle RAC Switchover & Switchback: Step-by-Step Guide

 Ensuring business continuity requires regular Disaster Recovery (DR) drills. This guide covers the Switchover and Switchback process between Primary (DC) and Standby (DR) databases . Pre-checks Before Performing Switchover Before starting the activity, ensure there are no active sessions in the database. If any are found, share the session details with the application team, get their confirmation, and terminate the sessions. Primary Database Name: PRIMARY Standby Database Name: STANDBY  Identify Active Sessions set lines 999 pages 999 col machine for a30 col username for a30 col program for a30 compute sum of count on report break on report select inst_id,username,osuser,machine,program,status,count(1) "count" from gv$session where inst_id=1 and program like 'JDBC%' group by inst_id,username,osuser,machine,program,status order by 1,2; select inst_id,username,osuser,machine,program,status,count(1) "count" from gv$session where inst_id=2 and program lik...
Post a Comment
Read more

Mastering Oracle RAC with SRVCTL Commands

Oracle Real Application Clusters (RAC) provide high availability, scalability, and manageability for databases. One of the most powerful tools for managing RAC databases is srvctl , a command-line utility that allows administrators to control various database services. This blog explores essential srvctl commands to help you efficiently manage Oracle RAC environments. 1. Checking Database Configuration and Status  List all available databases on the host:                  srvctl config database   Check the status of a specific database and its instances:                    srvctl status database -d <database_name>   Retrieve detailed status information about a database, including its instances and states:                    srvctl status database -d <database_name> -v 2. Stopping and Starting Databases   ...
Post a Comment
Read more