Why Oracle RAC Still Shines in 2025

---

TL;DR Summary

Oracle RAC continues to deliver zero-downtime clustering, linear scalability, and seamless maintenance in 2025—keeping it relevant for mission-critical workloads.

---

Introduction

In today’s cloud-native era, many argue that newer distributed databases have supplanted Oracle RAC. Yet, for enterprises demanding guaranteed uptime, sub-second failover, and mature support, RAC still solves real business pains.
DBAs and architects face pressure to keep systems online 24×7—RAC’s proven clusterware, ASM integration, and rolling-patch capabilities remain indispensable.

---

Architecture Overview

 


  ClientApp --> SCAN[SCAN VIP]
  SCAN --> RAC_Node1
  SCAN --> RAC_Node2
  RAC_Node1 --> ASM[ASM Diskgroup]
  RAC_Node2 --> ASM
  ASM --> Shared_Storage[(Shared Disks)]
  RAC_Node1 --> DG[Data Guard]
  RAC_Node2 --> DG

• ClientApp connects via a Single Client Access Name (SCAN) for load balancing.

• RAC_Node1/2 run independent Oracle instances accessing the same ASM-managed storage.

• ASM Diskgroup abstracts disk management and provides striping/mirroring.

• Shared Disks store datafiles, redo logs, and OCR.

• Data Guard provides disaster-recovery standby to the RAC primary.

---

Deep Dive

Memory & Process Architecture

• Global Cache Service (GCS): Coordinates block transfers between nodes.

• Global Enqueue Service (GES): Manages metadata locks.

• SGA Components: Shared by all instances, including library cache and buffer cache.

Component	Default Value	Purpose
CLUSTER_DATABASE	TRUE	Enables RAC mode
CACHE_FUSION	ENABLED	Inter-node block transfer
ASM_DISKGROUPS	(DATA, FRACTEMP)	ASM diskgroup list for data and temp

Redo Transport & Coordination

• Cache Fusion: Sends “dirty” blocks over the interconnect instead of disk.

• Interconnect: Private network (1–10 Gbps) dedicated for RAC heartbeat and block transfer.

• Redo Apply: Each instance writes local redo; ASM mirrors to shared storage.

---

Code & Configuration Samples

# Start the RAC database
srvctl start database -d ORCL       # Launches all instances in the cluster

# Check cluster status
crsctl check cluster               # Verifies CRS, voting disks, and OCR health

# Add a new SCAN listener
srvctl add scan_listener -l scan1 -p 1521  # Creates SCAN VIP

-- Enable Transparent Data Encryption (TDE) wallet
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "StrongPwd!";
ADMINISTER KEY MANAGEMENT CREATE KEY IDENTIFIED BY "StrongPwd!" WITH BACKUP;
-- Annotated: Opens wallet and creates TDE master key

---

Performance Tuning & Best Practices

1. Statistics Management: Automate DBMS_STATS.GATHER_DATABASE_STATS() weekly.

2. Interconnect Tuning: Use jumbo frames (MTU 9000) on the private network.

3. Adaptive Features: Enable MEMORY_TARGET with MEMORY_MAX_TARGET.

4. Instance Caging: Limit CPU per instance for balanced workload.

5. ASM Rebalance: Schedule low-priority rebalance to avoid IO spikes.

 

Parameter	Impact	Suggested Value
CLUSTER_INTERCONNECTS	Defines interconnect NICs	eth1,eth2
DB_CACHE_SIZE	Buffer cache per instance	25% total SGA
PGA_AGGREGATE_TARGET	Controls private memory for SQL	20% of SGA

---

Security Considerations

• Network ACLs:

  BEGIN
    DBMS_NETWORK_ACL_ADMIN.CREATE_ACL(
      acl         => 'rac_acl.xml',
      description => 'RAC network rules',
      principal   => 'RAC_USER',
      is_grant    => TRUE,
      privilege   => 'connect'
    );
  END;
  

• sqlnet.ora snippet:

  SQLNET.ENCRYPTION_SERVER = required
  SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
  

• Role Separation: Grant only SYSDBA on one node; use OPERATOR for maintenance scripts.

---

Real-World Case Study

Scenario: A global retailer migrated its 24×7 e-commerce platform to Oracle RAC on Exadata Cloud.

• Challenge: Single-instance DB caused 2–3 min outages per month during patching.

• Solution: Deployed 4-node RAC with rolling patching and ASM redundancy.

• Outcome: Achieved 99.999% availability, reduced patch-window to zero downtime, and saw a 30% improvement in average transaction throughput.

---

Common Pitfalls & Troubleshooting

1. ORA-16837: Host crashed

   • Diagnostics:

     crsctl check cluster -all
     

   • Fix: Verify underlying OS heartbeat, increase CRSCTL set cluster property -name 'auto_recovery' -value 'true'.

2. Cache Fusion Latency

   • Diagnostics:

     SELECT * FROM GV$GES_STATISTICS;
     

   • Fix: Optimize interconnect NIC teaming or switch to InfiniBand.

3. ASM Rebalance Slowness

   • Diagnostics:

     SELECT * FROM V$ASM_OPERATION;
     

   • Fix: Set ASM_POWER_LIMIT higher during off-peak hours.

---

FAQs

Q1: Is RAC overkill for small DBs?
A: If you need high availability and your SLAs demand zero downtime, RAC scales down—consider two-node deployments.

Q2: Can I run RAC on public cloud?
A: Yes—OCI, AWS, and Azure all support Oracle RAC, though network and storage configs vary.

Q3: How does RAC compare to Kubernetes-based DBs?
A: RAC offers deeper integration with ASM, rolling patches, and Oracle support—K8s DBs are emerging but less mature.

---

Conclusion & Call-to-Action

Oracle RAC remains a battle-tested solution in 2025, delivering unmatched uptime, linear scalability, and mature tooling. If uptime is non-negotiable for your enterprise, RAC deserves a spot in your architecture.
Share your RAC experiences below or contact us for an in-depth workshop!

---

References

1. Oracle RAC Concepts Guide – https://docs.oracle.com/en/database/oracle/oracle-database/19/radbi/index.html

2. ASM Administrator’s Guide – https://docs.oracle.com/en/database/oracle/oracle-database/19/asmag/index.html

3. Oracle Real Application Clusters Best Practices – Oracle White Paper

4. Data Guard Overview – https://docs.oracle.com/en/database/oracle/oracle-database/19/dgbkr/index.html

5. Managing Database Security – Oracle Database Security Guide

Steps to Handle Loss of Redo Log File

  Steps to Handle Loss of Redo Log File

 

1.  Identify the Lost Redo Log:

       - First, figure out which redo log group and member are missing. You can do this using SQL*Plus or SQL Developer connected to your Oracle database.

         SELECT group#, member   FROM v$logfile;

               This query will list the redo log groups and their members. Identify the missing one based on its group number and member path.

 

2.  Check Redo Log Status:

   - Next, verify the status of the remaining redo log groups and members to ensure they are intact and available.

      SELECT group#, status   FROM v$log;

 

3.  Restore Lost Redo Log:

   - If you have a backup of the lost redo log file, restore it from your backup solution (like RMAN) to its original location.

   - If no backup is available, you may need to recreate the lost redo log file. This involves dropping the damaged group and recreating it with the appropriate size and attributes.

4.  Recreate Redo Log Group:

   - To recreate a redo log group, use SQL commands while connected to SQL*Plus or SQL Developer:

      ALTER DATABASE ADD LOGFILE GROUP <group_number> ('path_to_redo_log_file_1', 'path_to_redo_log_file_2', ...);

    Replace `<group_number>` with the group number of the lost redo log group, and specify the paths to the redo log files you want to create.

 

5.  Switch and Open Database:

   - After adding or restoring the redo log file, perform a log switch to activate the new or restored redo log group.

      ALTER SYSTEM SWITCH LOGFILE;

      - Open the database in the appropriate mode (`OPEN` or `OPEN RESETLOGS`) depending on the recovery scenario.

 

6.  Recovery and Testing:

   - Perform recovery checks to ensure the database is functioning correctly after restoring or recreating the redo log file.

   - Monitor the alert logs and database performance for any further issues or errors related to the recovery process.

 

Considerations

 

-  Backup Strategy:  Regularly back up your redo logs using RMAN to facilitate quick recovery in case of data loss scenarios.

-  Redo Log Architecture:  Understand your redo log architecture (group sizes, multiplexing, etc.) to ensure redundancy and quick recovery.

-  Database Protection:  Implement high availability (HA) solutions and data protection mechanisms to mitigate risks associated with redo log file loss.

 

 Keep learning 

Honored and Driven: The Impact of Earning the Top Database Administration Voice Title

 

Earning the title of "Top Database Administration Voice" is an incredible honor and a deeply humbling recognition of the dedication, passion, and countless hours I've invested in this field. But beyond the personal gratification, it serves as a powerful catalyst, propelling me forward in my journey and igniting a renewed sense of purpose within the vibrant and ever-evolving world of database administration (DBA).

A Heartfelt Expression of Gratitude

At the outset, I want to express my heartfelt gratitude to everyone who played a part in making this recognition possible. This includes everyone who nominated me, actively engaged with my work, or simply offered words of encouragement and support along the way. This achievement isn't solely a reflection of individual effort; it's a testament to the collaborative spirit and unwavering support of the entire DBA community.

Beyond Recognition: A Springboard for Growth

This recognition isn't merely a badge of honor; it's a potent source of motivation that fuels my desire to learn, contribute, and advocate for the DBA community:

• Staying Ahead of the Curve: The landscape of databases is a dynamic one, constantly evolving with new technologies and best practices emerging at a rapid pace. This recognition serves as a constant reminder of the importance of lifelong learning, pushing me to stay abreast of the latest trends and innovations that shape the future of data management.
• Empowering Others Through Knowledge Sharing: As someone recognized as a Top DBA Voice, I feel an even greater responsibility to share my knowledge and experience with others. This translates into actively seeking opportunities to empower the next generation of DBAs, whether through informative blog posts, engaging presentations, or dedicated mentorship programs.
• Championing the DBA Community: DBAs play an indispensable role within organizations, safeguarding the integrity, security, and accessibility of vital data. This recognition motivates me to become a stronger advocate for the DBA community, ensuring their vital contributions are valued and acknowledged at all levels.

The Ripple Effect of Recognition

This experience serves as a powerful illustration of the transformative impact that recognition can have. It transcends the act of simply acknowledging individual achievements; it has the potential to motivate individuals, foster collaboration, and strengthen communities as a whole. Let's strive to create a culture where we actively recognize and celebrate the contributions of others, regardless of their magnitude. After all, in the interconnected world of databases, just like in any other field, we are all stronger when we work together.

Looking forward for your suggestions.. please feel free to write to me.. Your help would definitely help to improve our blog. Chetan Yadav

SOP for Oracle to PostgreSQL Migration using ora2pg Tool

Introduction:

This SOP outlines the technical steps involved in migrating a standalone Oracle database version 11.2, running on a Linux operating system, to PostgreSQL versions 13 or 14 on the same Linux OS using the ora2pg migration tool.

Technical Steps:

1. Pre-Migration Assessment:

• Source Database Analysis:

• Conduct a thorough analysis of the Oracle 11.2 database to identify schema, data structures, and dependencies.

• Document Oracle-specific features and configurations.

• Target Environment Validation:

• Verify compatibility of PostgreSQL versions 13 and 14 with the existing Oracle database.

• Ensure the PostgreSQL environment meets the necessary prerequisites.

2. Install and Configure ora2pg:

• Tool Installation:

• Install the ora2pg migration tool on a dedicated server or workstation.

• Verify the installation and basic functionality of ora2pg.

• Configuration:

• Configure ora2pg by specifying Oracle connection details, including username, password, and connection string.

• Set PostgreSQL connection parameters for the target database.

3. Schema and Data Migration:

• Schema Conversion:

• Utilize ora2pg to analyze and convert Oracle schemas to equivalent PostgreSQL schemas.

• Handle specific data types, constraints, and triggers during the conversion.

• Data Extraction and Load:

• Extract data from Oracle tables using ora2pg, considering large datasets.

• Load the extracted data into corresponding PostgreSQL tables.

4. Post-Migration Validation:

• Data Integrity Checks:

• Conduct data integrity checks to ensure accuracy in the migrated data.

• Use checksums and row count verification for validation.

• Object Verification:

• Validate the migration of database objects (indexes, views, stored procedures) from Oracle to PostgreSQL.

• Address any discrepancies or errors.

5. Performance Tuning:

• Optimize PostgreSQL Settings:

• Fine-tune PostgreSQL settings based on the workload and usage patterns.

• Adjust parameters such as shared_buffers, effective_cache_size, and work_mem.

• Query and Index Optimization:

• Review and optimize SQL queries and indexes for PostgreSQL compatibility.

• Ensure optimal performance for the migrated database.

6. Application Integration:

• Update Connection Strings:

• Coordinate with application teams to update connection strings and configurations.

• Test application connectivity with the PostgreSQL database.

7. Documentation:

• Create Migration Documentation:

• Develop detailed documentation covering all migration steps, configurations, and validations.

• Include rollback procedures in case of unforeseen issues.

8. Post-Migration Support:

• Monitoring and Troubleshooting:

• Implement monitoring for the PostgreSQL environment to identify potential issues.

• Establish a troubleshooting plan and support mechanism for post-migration challenges.

----------------------------------------------------------------------------------

Below are the technical commands corresponding to the steps outlined in the SOP for migrating a database from Oracle to PostgreSQL using the ora2pg tool:

 

  1. Pre-Migration Assessment:

Source Database Analysis:

Conduct a manual analysis of the Oracle database schema and configurations.

Target Environment Validation:

Verify compatibility and prerequisites manually.

2. Install and Configure ora2pg:

Tool Installation:

# Install ora2pg using package manager (example for Debian/Ubuntu)

sudo apt-get install ora2pg

Configuration:

# Edit ora2pg configuration file (ora2pg.conf)

nano /path/to/ora2pg.conf

# Set Oracle and PostgreSQL connection parameters

3. Schema and Data Migration:

Schema Conversion:

# Run schema analysis and conversion

ora2pg -t SHOW_SCHEMA -c /path/to/ora2pg.conf

Data Extraction and Load:

 # Extract data from Oracle

ora2pg -t TABLE -c /path/to/ora2pg.conf

# Load data into PostgreSQL

psql -U postgres -d your_target_database -f /path/to/ora2pg/sql/ora2pg_your_schema.sql

4. Post-Migration Validation:

Data Integrity Checks:

Perform manual SQL queries or use PostgreSQL tools for data integrity checks.

Object Verification:

Validate migrated objects manually or use PostgreSQL query tools.

5. Performance Tuning:

Optimize PostgreSQL Settings:

Edit PostgreSQL configuration file (postgresql.conf) and adjust parameters.

# Example: Adjust shared_buffers

echo "shared_buffers = 4GB" >> /etc/postgresql/your_version/main/postgresql.conf

Query and Index Optimization:

Use PostgreSQL tools like EXPLAIN to analyze and optimize queries.

6. Application Integration:

Update Connection Strings:

Coordinate with application teams to update connection strings in application configuration files.

7. Documentation:

Create detailed documentation manually using a text editor.

8. Post-Migration Support:

Monitoring and Troubleshooting:

Implement monitoring tools manually or use existing PostgreSQL monitoring solutions.

 Conclusion:

This SOP provides a structured approach to migrating an Oracle 11.2 database to PostgreSQL 13 or 14 using the ora2pg tool. Thorough testing, documentation, and post-migration support are crucial for a successful migration process.