How to Convert a Single Instance Database to RAC in Oracle (Step-by-Step Guide)

Introduction

Single Instance Database to RAC conversion is a critical process for Oracle DBAs who need high availability, scalability, and performance in production environments.If you are running Oracle in production, chances are high that you’ve worked with both single instance databases and RAC (Real Application Clusters) environments. A single instance is simpler and easier to manage, but it lacks the high availability, scalability, and load balancing that Oracle RAC provides.

In many real-world cases, DBAs start with a single instance setup and later need to convert it into a RAC database. This often happens during system consolidation, cloud migrations, or when business requirements demand higher uptime.

In this guide, we’ll walk step-by-step through the process of converting a single instance Oracle database to RAC, explain the reasoning behind each step, and share troubleshooting insights from real experience.

---

Why Convert Single Instance to RAC?

Before diving into the commands, let’s first understand the benefits:

• High Availability (HA): RAC ensures the database remains available even if one node fails.
• Scalability: Workloads can be distributed across multiple nodes, improving performance.
• Flexibility: You can scale horizontally by adding new nodes.
• Load Balancing: Application connections can be distributed across instances, preventing bottlenecks.

This makes RAC ideal for mission-critical databases where downtime or performance degradation can impact the business significantly.

Before you begin the Single Instance Database to RAC conversion, you need a properly configured Oracle 19c environment. If you haven’t installed Oracle 19c yet or want to double-check the setup, follow this step-by-step guide on installing Oracle 19c Database on RHEL 9

---

Prerequisites and Setup

Before you start the conversion process, make sure you have:

1. Oracle RAC binaries installed on both nodes.
2. Shared storage configured (e.g., ASM or shared disks accessible by all nodes).
3. Password file available for your single instance database.
4. Oracle Grid Infrastructure installed and configured for cluster management.
5. Network configuration for both public and private (interconnect) networks.

With these prerequisites in place, we can begin the conversion.

---

Step 1: Copy the Password File

Copy your existing password file from the single instance environment to both RAC nodes. This ensures authentication works across nodes.

$ scp orapwdb oracle@test01:/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs scp orapwdb
$ scp orapwdb oracle@test02:/u01/app/oracle/product/11.2.0.4/dbhome_1/dbs

---

Step 2: Update Oratab Entries

On both nodes, create or edit the oratab entries:

$ vi $ORACLE_HOME/network/admin/etc/oratab

This ensures the Oracle environment recognizes your database.

---

Step 3: Update TNS Configuration

Add the TNS entries for both nodes so that client connections can be directed to the RAC environment.

DB1 =
 (DESCRIPTION =
  (ADDRESS = (PROTOCOL = TCP)(HOST = test01-vip)(PORT = 1521))
  (CONNECT_DATA = (SERVER = DEDICATED)(SID = db1))
 )

DB2 =
 (DESCRIPTION =
  (ADDRESS = (PROTOCOL = TCP)(HOST = test02-vip)(PORT = 1521))
  (CONNECT_DATA = (SERVER = DEDICATED)(SID = db2))
 )

Step 4: Shutdown the Single Instance Database

SQL> shutdown immediate;
SQL> exit

This is necessary to prepare the database for RAC conversion.

---

Step 5: Set Environment on Node 1

$ . oraenv
ORACLE_SID = [db] ? db1

This aligns your session with the RAC node 1 instance.

---

Step 6: Edit the PFILE for Cluster Database

Open your original parameter file (init.ora) and modify it:

*.cluster_database=true

Important: Remove *.interconnects lines, as they point to the single instance setup and can cause conflicts.

---

Step 7: Startup Database in Nomount Mode

SQL> startup nomount pfile=’$ORACLE_HOME/dbs/initdb.ora’

---

Step 8: Create SPFILE from PFILE

Move the parameters into ASM storage by creating an SPFILE:

SQL> create spfile=’+DATA_XDT/DB/PARAMETERFILE/spfiledb.ora’ from pfile;

---

Step 9: Restart the Database with SPFILE

SQL> shutdown immediate;
SQL> startup;

Verify RAC instance properties:

SQL> select * from v$instance;

---

Step 10: Configure Node 2

Copy the init.ora from Node 1 to Node 2 and rename it:

$ scp initdb1.ora xdt*dbadm02:$ORACLE_HOME/dbs/initdb2.ora

---

Step 11: Register Database with SRVCTL

Add the database to Oracle Clusterware:

$ srvctl add database -d db -o /u01/app/oracle/product/11.2.0.4/dbhome_1

Add both RAC instances:

$ srvctl add instance -d db -i db1 -n test01
$ srvctl add instance -d db -i db2 -n test02

---

Step 12: Update TNS Configuration

Comment out the single instance tnsnames.ora entry to prevent accidental external connections outside RAC.

---

Final Verification

At this point, your database has been successfully converted into a RAC environment. Verify using:

SQL> select instance_name, host_name, parallel, thread# from gv$instance;

You should now see multiple instances across your cluster nodes.

---

Troubleshooting Tips

• Datafile issues: Ensure all datafiles are accessible from both nodes.
• Network issues: Verify VIPs and SCAN listeners are correctly configured.
• Parameter conflicts: Double-check cluster-related parameters in the SPFILE.
• SRVCTL errors: Always ensure Grid Infrastructure services are running.

---

Best Practices

• Always backup your single instance database before conversion.
• Keep ASM redundancy in place for resilience.
• Document your RAC configuration (TNS, SRVCTL, init parameters).
• Regularly test failover scenarios to validate HA.

---

Insight: What If All Datafiles, SPFILE, and Redo Logs Are Inside ASM?

When you’re converting a single instance database to RAC, one of the biggest factors that influences the complexity of the process is where your critical files are stored. If your datafiles, SPFILE, and redo logs are already inside ASM, the conversion process becomes much smoother and faster.

Why?

• Shared Storage Across Nodes:
  ASM automatically provides shared disk access. This means every RAC node can see and access the same datafiles, control files, SPFILE, and redo logs without additional manual copying.
• No Need to Relocate Files:
  If your single instance database was using filesystem-based storage, you’d need to manually migrate datafiles and redo logs into ASM first. Since they’re already there, RAC can directly use them.
• SPFILE in ASM Simplifies RAC Configuration:
  Having the SPFILE in ASM means all nodes automatically reference the same parameter file. Any cluster-wide parameter changes made using ALTER SYSTEM are synchronized across instances.
• Redo Logs in ASM Ensure Cluster Awareness:
  Redo logs stored in ASM are automatically shared, removing the need to recreate or copy redo logs for each node. This avoids mismatch issues that often occur when converting from filesystem-based redo logs.

What Changes in the Conversion Steps?

1. SPFILE Step Becomes Easier
   • You don’t need to create a new SPFILE in ASM if it’s already there.
   • Just ensure srvctl is aware of its location (+DATA/.../spfile.ora).
2. Datafile Access Is Automatic
   • RAC nodes can see all datafiles through ASM, so no extra configuration is needed.
3. Redo Log Groups Already Available
   • Existing redo log groups in ASM are usable across all instances, unless you want to resize or add groups for performance tuning.
4. Simplified Troubleshooting
   • File location consistency is guaranteed by ASM, which removes a class of errors where one node can’t locate a file.

Best Practice in This Scenario

• Confirm all required disk groups (+DATA, +FRA, +REDO, etc.) are mounted on each node.
• Validate that your SPFILE points to ASM and not a filesystem-based copy.
• Use srvctl config database -d <db_name> after conversion to confirm ASM file paths are correctly registered.

---

Conclusion

Converting a single instance database to RAC is a structured process that, once understood, is straightforward. The key steps involve adjusting parameter files, configuring RAC-aware services, and using SRVCTL to register the database and instances.

With this setup, your environment is now more resilient, scalable, and enterprise-ready. Whether you’re preparing for higher workloads, improving HA, or moving toward cloud-ready architecture, RAC conversion is a critical step in modern Oracle database management.