Oracle RAC Tutorial

Oracle RAC isn't a new product. You wouldn't think of it as a mature product, especially when the largest companies in the world continue to place their heaviest workloads on it – and grow their business through its utilization.

In Oracle's SEC filing for fiscal year 2026 the company reported total revenue was up a remarkable $67.4 billion, an increase of 17% year-over-year. Cloud revenue was up an impressive 39% to $34 billion.

Operating cash flow soared 54% to $32 billion. Oracle is targeting $90 billion in total revenue by the 2027 fiscal year. CEO Safra Catz said after the FY25 earnings release that "FY26 will be even better as our revenue growth rates will be dramatically higher."

New to Oracle Database 23ai (now rolling out into 26ai), over 300 new features dropped including many that directly impact how RAC behaves. There’s Local Rolling Maintenance that takes away downtime while you patch the databases. 

This tutorial gives you an overview and talks about the fundamentals of Oracle RAC.

Table of Contents

• What is Oracle RAC?
• Architecture
• Components
• Disk Architecture
• Oracle Clusterware
• Oracle Kernel Components
• RAC Background Processes
• Installation
• Administration
• Debugging CRS and GSD
• Multitenant Architecture (CDB / PDB)
• Oracle 23ai/26ai RAC Enhancements
• Wrapping Up

What is Oracle RAC?

With Oracle Real Application Clusters (RAC), we can use multiple database instances across multiple servers that connect to a single,shared database concurrently. Most environments we find consist of a single instance attached to a single database. However, in a RAC setup we can have two, four, eight, or any number of instances concurrently attached to the same database instance. 

What does this help us with? Two things. First, if one server crashes, the other instances keep running. Users may not even notice. That is high availability. Second, you can spread workload across multiple nodes. That is scalability. You get both from the same architecture, which is why RAC has been the backbone of mission critical Oracle deployments for over two decades.

Oracle RAC Architecture

Oracle RAC is heavily dependent on an efficient, highly reliable, high-speed private network called the interconnect. When you are designing a RAC system, invest in the best interconnect you can afford. This is not the place to cut costs.

Here is how a standard single-instance Oracle database compares to a RAC environment.

Component	Single Instance Environment	RAC Environment
SGA	An instance has its own SGA	Each instance has its own SGA
Background processes	The instance has its own set of background processes	Each instance has its own set of background processes
Datafiles	Accessed by only one instance	Shared by all instances (shared storage)
Control Files	Accessed by only one instance	Shared by all instances (shared storage)
Online Redo Logfile	Dedicated for write/read to only one instance	Only one instance can write but other instances can be read during recovery and archiving. If an instance is shut down, log switches by other instances can force the idle instance to redo logs to be archived
Archived Redo Logfile	Dedicated to the instance	Private to the instance but other instances will need access to all required archive logs during media recovery
Flash Recovery Log	Accessed by only one instance	Shared by all instances (shared storage)
Alert Log and Trace Files	Dedicated to the instance	Private to each instance, other instances never read or write to those files.
ORACLE_HOME	Multiple instances on the same server accessing different databases cause the same executable files	Same as a single instance, plus it can be placed on a shared file system, allowing a common ORACLE_HOME for all instances in a RAC environment.

RAC Components

Every Oracle RAC system is built on four major components. Understanding these is foundational to everything else in this tutorial.

• Shared Disk System — All nodes access the same storage. This can be SAN, NAS, or ASM managed storage. Without shared storage, RAC does not work.
• Oracle Clusterware — The cluster management software that binds multiple servers together so they operate as one logical system. It handles node membership, resource management, and failover.
• Cluster Interconnect —  A private, high-speed network that instances use to synchronize data and transfer cache blocks between nodes. This needs to be fast and reliable. Low latency is critical.
• Oracle Kernel Components — The database-specific processes and mechanisms (like Cache Fusion) that make multi-instance access to a single database possible.

Disk Architecture

Shared storage is a requirement for RAC, and setting it up correctly has a direct impact on performance and availability. There are three common storage connectivity options.

• SAN (Storage Area Networks) uses fiber channels to connect servers to the storage array. A common and likely most seen environment when talking about enterprise RAC installs is an NAS setup.  
• NAS (Network Attached Storage) connects via network via NFS, iSCSI, etc. Typically cheaper and easier to deploy but often less performant when dealing with high-demand database transactions.

Both of these should be configured with multipathing to eliminate single points of failure. The cost of adding a second path is minimal compared to the cost of a storage outage on a production RAC cluster.

RAID Levels

Once storage is connected, you need to decide on the RAID configuration.

• RAID 0 (Striping) concatenates disks together for performance. No redundancy. If one disk fails, the volume fails. Not suitable for production databases.
• RAID 1 (Mirroring) mirrors every disk. If one fails, the mirror takes over. Highly available but requires double the disk count.
• RAID 5 (Striping with Parity) stripes data with parity across three or more disks. Good read performance. Write performance suffers due to parity calculation. A middle ground on cost.

Disk Management Options

After your storage is attached, you have three choices for how Oracle accesses it.

• Raw Volumes were historically used for performance. They are difficult to manage and have largely fallen out of favor.
• Cluster Filesystem can hold Oracle datafiles and is usable on both Windows and Linux, but adoption has been limited.
• ASM (Automatic Storage Management) is Oracle's recommended approach. Oracle ASM is a cluster file system, which is portable, optimized, and optimized specifically for Oracle database file placement. In 2026, if you're deploying a new RAC cluster and you are deciding on how to place your files on it, Oracle ASM would more than likely be the approach you want.

Oracle Clusterware

Oracle Clusterware is the underlying software that makes multiple disparate servers function as one large server, or "cluster." It is capable of supporting up to 64 nodes and may leverage other vendor-supplied clustering solutions such as Sun Cluster and Veritas Cluster. 

• Oracle Cluster Registry (OCR) is a file stored on shared storage and houses the information needed to define the cluster configuration, resources, and the status of nodes on the cluster. It will perform a backup automatically every four hours and should be at least 100MB in size.
• Voting Disk acts as a tiebreaker during communication failures. All nodes write heartbeat information to it continuously. If a node cannot access the voting disk, it is immediately evicted from the cluster. This protects against split-brain scenarios.

CRS Daemons

The Cluster Ready Services run as four daemon processes, and knowing what each one does will come up in both interviews and troubleshooting sessions.

CRS Process	Functionality	Failure of the Process	Run AS
OHASd	The root process starts and manages all other cluster daemons.	Bring down cluster services on the node.	root
OCSSd	Still manages cluster node membership and locking.	Causes a node restart	Grid User
CSSDAgent & CSSDMonitor	Monitors the OS and the OCSSd process.	Causes a node restart	root
CRSd	Resource monitoring, failover, and node recovery.	Auto-restarts (Doesn't restart the node)	root

Voting and Quorum

There seems to be confusion with these two words, so let's distinguish. 

• Voting is a formal expression of opinion in response to a proposed decision. In RAC, each node votes through the voting disk to confirm it is alive and participating. 
• Quorum is the minimum number of members required to form a legitimate cluster. Only quorum members' votes define the cluster. If a node or group of nodes cannot achieve quorum, they should not start services because they risk conflicting with the established cluster.

This is why the voting disk exists. It arbitrates ownership during communication failures. The group that can access the voting disk and achieves quorum keeps running. The other group gets evicted. It sounds harsh, but the priority is always data protection.

Oracle Grid Infrastructure and the OHASD Daemon Stack

A lot of older tutorials describe Oracle Clusterware and ASM as if they are separate installations that you manage independently. Well, that all changed with 11gR2. In pretty much all Oracle RAC environments today, Clusterware and ASM are a single installation known as Grid Infrastructure, and the installations occur in their own unique home location known as GRIDHOME (just as database installs get their own home known as ORACLEHOME).

Questions about what Grid Infrastructure is doing when it is coming up, and in particular what daemons it's starting, come up all the time in interviews and become crucial in diagnosing problems.

The OHASD Daemon Hierarchy

As a node comes up, the first Oracle process that kicks off is called OHASD (Oracle High Availability Services Daemon), which runs under root and acts as the parent process for all other processes. Consider OHASD the parent daemon that launches and monitors its other children daemons.

The Oracle Processes Started by OHASD Are As Follows:

• CSSD (Cluster Synchronization Services Daemon) - Manages node membership and heartbeat between nodes and maintains the state of whether or not a given node is a member of the cluster. If CSSD fails, the node reboots. That sounds aggressive, but the alternative is a split-brain scenario where two halves of the cluster think they are both the real cluster.
• CRSD (Cluster Ready Services Daemon) manages all cluster resources: databases, instances, services, listeners, VIPs, SCAN. When you use srvctl to start a database, CRSD is the daemon doing the actual work. If CRSD crashes, it restarts automatically without rebooting the node.
• DISKMON (Disk Monitor Daemon) monitors the storage subsystem. It is particularly important in Exadata environments where it handles I/O fencing to prevent data corruption during node failures.
• OSYSMOND (OS System Monitor Daemon) collects operating system metrics like CPU usage, memory, network throughput, and disk I/O. This data feeds into Cluster Health Monitor and is invaluable for diagnosing performance issues after the fact.

How the Startup Sequence Works

The startup is layered and sequential. Understanding this helps a lot when troubleshooting a node that will not join the cluster.

• The OS boots and starts the ohasd service (configured as a system service)
• OHASD spawns CSSD, which establishes cluster membership by contacting voting disks
• Once CSSD confirms the node is a valid cluster member, OHASD spawns CRSD
• CRSD reads the OCR (Oracle Cluster Registry) and starts the resources assigned to this node: ASM, database instances, listeners, VIPs, SCAN.

If the node hangs at step 2, your problem is voting disk connectivity or CSSD configuration. If it hangs at step 4, your problem is OCR corruption or a resource misconfiguration. Knowing which layer failed tells you exactly where to look.

Oracle Kernel Components

The kernel components relate to the background processes, buffer cache, and shared pool, and managing the resources without conflicts and corruption requires special handling.

In RAC, because more than one instance accesses the resource, the instances require better coordination at the resource management level. Each node will have its own set of buffers but will be able to request and receive data blocks currently held in another instance’s cache. Global Cache Services (GCS) manages data sharing and exchange.

All the resources in the cluster group form a central repository called the Global Resource Directory (GRD), which is distributed. Each instance masters some set of resources, and together all instances form the GRD. Resources are distributed equally among the nodes based on their weight.

The GRD is managed by two services called Global Caches Services (GCS) and Global Enqueue Services (GES), together they form and manage the GRD. When a node leaves the cluster, the GRD portion of that instance needs to be redistributed to the surviving nodes, a similar action is performed when a new node joins.

RAC Background Processes

RAC instances run all the standard Oracle background processes (PMON, SMON, DBWR, LGWR, etc.) plus several RAC specific processes.

• LMSn (Lock Manager Service) handles Cache Fusion block transfers between instances. Multiple LMS processes can run simultaneously, and the number is configurable.
• LMD (Lock Manager Daemon) manages global enqueue requests and deadlock detection across instances.
• LMON (Lock Monitor) monitors the cluster for instance failures and manages recovery. It also handles reconfiguration when nodes join or leave the cluster.
• LCK0 (Lock Process) manages non-Cache Fusion resource requests.
• DIAG (Diagnosability Daemon) captures diagnostic data for troubleshooting.

RAC Installation

I am not going to walk through a step-by-step installation here because there are excellent Oracle documents that do it better than I could. But I will point you to the things that matter.

• Before you start the installation, make sure you have your shared storage configured and accessible from all nodes. 
• Verify that your interconnect network is working with low latency. Set up DNS for all nodes to point to both public IPs and VIPs. 
• Ensure that you also have NTP (or chrony, better still!) up and running so that you do not have clock skew across the cluster – it’s just an ugly thing to debug. 
• The installation process is: Install the OS and its prerequisites → install Oracle Grid Infrastructure → install the Oracle Database software → then use DBCA to create the database (cluster-aware).
• You can also set up a “sandbox” RAC environment on VBox to save your money on expensive hardware. 
• You can use VirtualBox from Oracle. It has free VMs and step-by-step instructions on how to install RAC on Virtual Machines.

Learn Oracle RAC Interview Questions and Answers that help you grab high-paying jobs

RAC Administration

Day-to-day RAC administration revolves around a few key tools and commands.

SRVCTL (Server Control)

SRVCTL is the primary command-line tool for managing RAC databases, instances, and services.

# Check the status of a RAC database
srvctl status database -d PRODDB

# Start a specific instance
srvctl start instance -d PRODDB -i PRODDB1

# Stop a specific instance
srvctl stop instance -d PRODDB -i PRODDB2

# Add a service
srvctl add service -d PRODDB -s APP_SERVICE -r PRODDB1,PRODDB2

# Relocate a service to another instance
srvctl relocate service -d PRODDB -s APP_SERVICE -i PRODDB1 -t PRODDB2

CRSCTL (Cluster Ready Services Control)

CRSCTL manages the Clusterware stack itself.

# Check CRS status on the local node
crsctl check crs

# Check the status of all cluster resources
crsctl stat res -t

# Stop CRS on the local node
crsctl stop crs

# Start CRS on the local node
crsctl start crs

# Check the cluster interconnect status
oifcfg getif

SCAN (Single Client Access Name)

Before SCAN existed, connecting to a RAC database was a bit of a headache. Every time you added or removed a node, you had to update TNS connection strings on every single application server that talked to the database. With a dozen apps pointing at a four node cluster, that meant chasing down connection configs across the entire environment every time the cluster topology changed.

SCAN fixed that problem completely.

What SCAN Actually Does

SCAN gives your RAC cluster a single hostname that clients use for all connections. This single hostname actually resolves to three separate IP addresses – configured either through DNS or through Grid Naming Service. When a client connects, it connects to the SCAN listener on whatever IP it happens to hit, and that listener in turn routes it to the appropriate instance based on load and service definition.

The really nice part about this is that the client really has no concept of how many nodes are actually in the cluster. Whether you add a fifth node next Tuesday, or rip the third one out of service next Friday, no client application ever needs to change its connect string. They all still point at the same SCAN name.

How it Works Under the Hood

Three SCAN VIPs are registered in DNS, all pointing to the same hostname. For example:

rac-scan.company.com points to → 10.0.1.100 → 10.0.1.101 → 10.0.1.102 

DNS round robin distributes incoming connection requests across these three IPs. A SCAN listener runs on each IP. When a connection arrives, the SCAN listener checks which instances are running the requested service and redirects the connection to a local listener on the appropriate node.

A Simple TNS Entry Using SCAN

This is what a client-side connection looks like. Notice there is no mention of individual node names or IPs.

PRODDB =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan.company.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = app_service)
    )
  )

One entry. Works regardless of how many nodes the cluster has. If you add two more nodes next month, this TNS entry stays exactly the same.

Key AWR Sections For RAC

When you pull an AWR report from a RAC database, pay special attention to these sections.

• Global Cache Transfer Stats shows the volume of blocks transferred between instances via Cache Fusion. High transfer rates are not necessarily bad, but high transfer times indicate interconnect problems.
• Global Cache and Enqueue Services reports wait events related to GCS and GES. Look for "gc buffer busy acquire," "gc buffer busy release," and "gc current block busy." High waits here point to contention between instances.
• Interconnect Statistics shows throughput and latency on the private interconnect. Average block transfer time should ideally be under 1 millisecond. Anything consistently above 2 milliseconds needs investigation.
• Instance Activity Stats lets you compare workload distribution across instances. Uneven distribution can lead to hotspots and unnecessary Cache Fusion traffic.

Debugging CRS and GSD

When things go wrong with Clusterware, the diagnostic information lives in several places.

CRS Alert Log

This is the first place to look. It records every significant event: node joins, node evictions, resource state changes, and error conditions. The default location depends on your Oracle version and platform but is typically under the Grid Infrastructure home.

# Typical location for CRS alert log
$GRID_HOME/log/<hostname>/alertlog/alert.log

Trace Files

Each CRS daemon writes its own trace files. When a specific daemon is misbehaving, check its trace directory.

# CRSd trace files
$GRID_HOME/log/<hostname>/crsd/

# OCSSd trace files
$GRID_HOME/log/<hostname>/ocssd/

# EVMd trace files
$GRID_HOME/log/<hostname>/evmd/

Common Debugging Commands

# Check if voting disk is accessible
crsctl query css votedisk

# Verify OCR integrity
ocrcheck

# Export OCR for backup
ocrconfig -export /tmp/ocr_backup.dmp

# Check cluster interconnect configuration
oifcfg getif

# View the CRS resource status in detail
crsctl stat res ora.crsd -p

GSD (Grid Services Daemon)

GSD handles backward compatibility with older management tools. GSD usage has been almost completely replaced with SRVCTL in newer Oracle versions (from 12c onwards) and in direct CRS administration for management purposes. If you have issues related to GSD, examine GSD’s logs located in your Grid Infrastructure home.

Oracle RAC with Multitenant Architecture (CDB / PDB)

This is not optional knowledge anymore. Starting with Oracle 21c, the old non CDB architecture was completely removed. Oracle 23ai and 26ai do not even allow you to create a non CDB database. Every RAC deployment in 2026 runs on the Multitenant architecture with a Container Database (CDB) and one or more Pluggable Databases (PDBs).

If you walk into a RAC interview and describe the database without mentioning CDB and PDB, the interviewer will assume you have not touched Oracle since 19c at the latest.

How Multitenant Works in RAC

In a standalone environment, you have one CDB with multiple PDBs. Each PDB is essentially a self contained database with its own schemas, tablespaces, and data. The CDB provides the shared infrastructure: the instance, the SGA, the background processes, the redo logs.

In RAC, the CDB runs across multiple instances on multiple nodes. Each PDB inside that CDB can have its own service, and you control which instances that service runs on. This gives you granular control over where each PDB's workload executes.

For example, your finance PDB might run on nodes 1 and 2, while your HR PDB runs on nodes 3 and 4. Same cluster, same CDB, but the workloads are isolated to specific nodes.

PDB Services in RAC

Every PDB needs at least one service for application connectivity, and you manage these through srvctl just like any other RAC service.

# Create a service for the finance PDB running on nodes 1 and 2
srvctl add service -d PRODCDB -s finance_svc -pdb FINANCE_PDB \
  -r PRODCDB1,PRODCDB2

# Start the service
srvctl start service -d PRODCDB -s finance_svc

# Check service status
srvctl status service -d PRODCDB -s finance_svc

Clients connect to a PDB through SCAN using the service name. The TNS entry looks exactly like any other SCAN connection, with the service name pointing to the PDB's service.

FINANCE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan.company.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = finance_svc)))

PDB Online Relocation

One of the genuinely useful features in RAC Multitenant is the ability to relocate a PDB from one instance to another while it is still online. Users stay connected during the move. Sessions drain gracefully from the old instance and reconnect on the new one.

ALTER PLUGGABLE DATABASE finance_pdb RELOCATE TO 'PRODCDB3';

This is useful during maintenance windows when you need to take a node offline but do not want to disrupt the PDBs running on it. Relocate them first, then take the node down.

Per PDB Undo Tablespaces

In the old shared undo model, a single undo tablespace per instance handled undo for all PDBs. Starting with Oracle 21c, each PDB can have its own dedicated undo tablespace. This improves isolation because one PDB's heavy transaction workload cannot fill the undo tablespace and affect other PDBs.

-- Check if local undo is enabled
SELECT PROPERTY_NAME, PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'LOCAL_UNDO_ENABLED';

Oracle 23ai has local undo enabled by default. You do not need to set it up manually on new installations.

PDB Resource Management

When multiple PDBs share the same CDB in a RAC environment, you need to make sure one PDB cannot consume all the CPU or memory and starve the others. Oracle handles this through CDB Resource Plans.

-- Create a simple resource plan
BEGIN
  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
    plan => 'RAC_PDB_PLAN',
    comment => 'Resource plan for RAC PDBs');

  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan => 'RAC_PDB_PLAN',
    pluggable_database => 'FINANCE_PDB',
    shares => 3,
    utilization_limit => 60);

  DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN_DIRECTIVE(
    plan => 'RAC_PDB_PLAN',
    pluggable_database => 'HR_PDB',
    shares => 1,
    utilization_limit => 30);
END;
/

In this example, the finance PDB gets three times the CPU shares of the HR PDB, and neither can exceed its utilization limit. This prevents noisy neighbor problems across PDBs.

Oracle 23ai/26ai RAC Enhancements

Oracle Database 23ai introduced several important RAC specific improvements that are worth knowing about.

• Local Rolling Maintenance allows you to patch individual nodes without affecting the rest of the cluster. The database stays available throughout the patching process.
• Two Stage Rolling Updates reduce downtime during upgrades by eliminating the need for full cluster restarts.
• Raft Replication enables ultra fast failover with zero data loss across nodes or data centers. It does support the active layout and that is huge as far as disaster recovery concerns go. 
• Smart Connection Rebalancing intelligently reroutes the database session should a node go down or a node come up to maintain a more balanced workload for you with absolutely no user interaction required. 
• Ordered Sequences Optimization increases performance of any workload that depends a lot of sequence numbers from the database which is often an important requirement for high- throughput OLTP systems.

Overall, these two features are a welcome step for the entire RAC patch/failover/workload management perspective. If you are studying for an Oracle Certification and are on this exam or interviewing for DBA roles be ready to answer questions about these.

If you want a structured path through all of this with hands-on labs on actual cluster environments, MindMajix's Oracle RAC Training program covers every topic in this tutorial and more. The curriculum aligns with Oracle certification exam objectives and is designed around what production DBAs actually need to know from day one.

Wrapping Up

Oracle RAC is one of those technologies where the fundamentals have stayed remarkably stable while the platform around them keeps evolving. The core concepts of shared storage, Cache Fusion, interconnect based block transfers, and Clusterware managed node membership are the same today as they were ten years ago. 

But the tooling, the performance optimizations, and the high availability features have advanced significantly with 23ai/26ai.