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 19c Database Deployment with Docker

Oracle 19c Database Deployment with Docker 🐳 Oracle 19c Database Deployment with Docker Welcome to this comprehensive guide on deploying, configuring, and managing Oracle 19c Database using Docker containers. This blog will walk you through the entire process from setup to production best practices with practical code examples. Docker provides an excellent way to run Oracle databases in isolated, portable containers, making it easy to deploy and manage Oracle 19c instances for development, testing, and production environments. This approach offers numerous benefits: 🔒 Isolation : Run Oracle in a containerized environment without affecting your host system 🚚 Portability : Easily move your database between different environments 🔄 Reproducibility : Quickly spin up identical database instances ⚡ Resource Efficiency : Use Docker's resource management capabilities to control CPU, memory, and stor...
Post a Comment
Read more

Oracle Enterprise Manager: A Step-by-Step Guide to Agent Patching

Keeping your Oracle Enterprise Manager (OEM) agents up-to-date is crucial for maintaining system security and performance. In this blog post, we'll walk through the complete process of applying patches to OEM agents using the Enterprise Manager interface. This guide is suitable for database administrators and IT professionals who manage Oracle environments. Prerequisites Before starting the patching process, ensure you have: Administrator access to Oracle Enterprise Manager The latest patch files downloaded from Oracle Support A maintenance window scheduled for your target systems The Patching Process Step 1: Navigate to Patches & Updates Begin by accessing the Enterprise Manager console and navigating to the Enterprise → Patches & Updates section. This is your central hub for all patching operations. Step 2: Upload the Latest Patch Click the UPLOAD button in the interface Select the patch file from your local system Wait for the upload process to complete ...
Post a Comment
Read more