Oracle RAC Architecture: Understanding the Cluster from the Ground Up
Oracle Real Application Clusters (RAC) is one of Oracle’s technologies for high availability and scalability. It allows multiple database instances running on different servers to access the same database stored on shared storage.
Unlike a standby database, where only one database is active, every RAC instance is active and can process user transactions simultaneously.
For many DBAs, RAC initially appears complex because it introduces new components such as Clusterware, ASM, SCAN, VIPs, OCR, Voting Disks, and Cache Fusion. However, once you understand how these components work together, RAC becomes much easier to administer and troubleshoot.
In this first article, we’ll build a solid foundation by exploring the RAC architecture before moving on to installation and administration in the next parts.
Why Oracle RAC?
Traditional single-instance databases have one obvious limitation: the entire workload depends on a single server.
Users
|
|
+----------------+
| Oracle Database|
| Instance |
+----------------+
|
Database Files
If that server fails:
- The database becomes unavailable.
- All user sessions are disconnected.
- Applications stop until the server is restored.
Even with excellent hardware, a single server remains a single point of failure.
Oracle RAC Architecture
Oracle RAC eliminates this limitation by allowing multiple servers to work together as one database system.
Clients
|
-----------------------------
| |
+--------+ +--------+
| Node 1 | | Node 2 |
+--------+ +--------+
|Instance1| |Instance2|
+--------+ +--------+
\ /
\ /
\ /
+---------------------------+
| Shared Storage |
| Datafiles, Redo, Control |
+---------------------------+
Every node:
- Runs its own Oracle instance.
- Shares the same database.
- Can process user sessions.
- Can survive the failure of another node.
This architecture provides both high availability and horizontal scalability.
Oracle RAC Components
A RAC environment consists of several major components.
| Component | Purpose |
|---|---|
| Oracle Database | Stores application data |
| Oracle Instance | Processes user sessions |
| Oracle Clusterware | Manages the cluster |
| Grid Infrastructure | Provides cluster services |
| Oracle ASM | Manages shared storage |
| OCR | Stores cluster configuration |
| Voting Disks | Maintain cluster membership |
| SCAN | Simplifies client connectivity |
| VIP | Supports fast failover |
| Private Interconnect | Connects cluster nodes |
Each component plays a specific role. Removing or misconfiguring any one of them can affect the stability of the entire cluster.
Understanding an Oracle Instance
Each RAC node runs an independent Oracle instance.
An instance contains:
- SGA
- Background processes
- Redo generation
- Undo
- Database cache
Example:
Node 1 +----------------------+ | SGA | | DBWR | | LGWR | | CKPT | | PMON | | SMON | +----------------------+
Node 2 runs another independent instance with its own memory and background processes.
Although the instances are separate, they all access the same physical database.
Shared Database Storage
Unlike two independent databases, RAC nodes do not maintain separate copies of the data.
Instead, every instance accesses the same shared storage.
Shared storage typically contains:
- Datafiles
- Control files
- Online redo logs
- Tempfiles
- SPFILE
- Password file
Oracle ASM is the most common storage solution in modern RAC environments.
Oracle Grid Infrastructure
Grid Infrastructure is the foundation of every Oracle RAC cluster.
It includes:
- Oracle Clusterware
- Oracle ASM
- Cluster services
- Cluster resource management
Without Grid Infrastructure, Oracle RAC cannot function.
Think of Grid Infrastructure as the operating system for the Oracle cluster.
Oracle Clusterware
Clusterware monitors every node and every critical resource.
It is responsible for:
- Starting resources
- Stopping resources
- Restarting failed services
- Detecting node failures
- Managing failover
Examples of monitored resources:
- Listener
- VIP
- ASM
- Database
- Services
If a resource fails unexpectedly, Clusterware attempts to restart it automatically.
Oracle ASM
Oracle ASM (Automatic Storage Management) provides a logical layer between Oracle and the physical disks.
Instead of managing individual files manually, ASM organizes storage into disk groups.
Example:
+DATA Datafiles Redo Logs Control Files SPFILE
Advantages include:
- Automatic striping.
- Online rebalancing.
- Simplified storage administration.
- Better performance.
We’ll cover ASM in detail later in the series.
Public Network vs Private Interconnect
A RAC cluster uses at least two networks.
Public Network
Used for:
- Client connections
- Application traffic
- Administrative access
Example:
Application
|
Public Network
|
Node 1
Private Interconnect
Used only between RAC nodes.
Purpose:
- Cache Fusion
- Cluster synchronization
- Heartbeat communication
Example:
Node 1 <==========> Node 2
Private Interconnect
The private interconnect is one of the most critical components of RAC. Poor latency or packet loss on this network can have a direct impact on cluster performance.
Cache Fusion
Cache Fusion is one of the technologies that distinguishes RAC from other clustering solutions.
Instead of writing modified blocks to disk before another instance can use them, Oracle transfers data blocks directly through the private interconnect.
Traditional approach:
Node A
Disk
Node B
RAC approach:
Node A
|
Private Interconnect
|
Node B
Benefits:
- Faster block transfers.
- Reduced disk I/O.
- Better scalability.
Cache Fusion is often described as the “heart” of Oracle RAC because it allows all instances to behave as though they are working on a single shared memory system.
Oracle Cluster Registry (OCR)
The Oracle Cluster Registry stores cluster configuration information.
Examples include:
- Node names.
- Network configuration.
- Database resources.
- ASM configuration.
- Services.
Clusterware reads the OCR during startup to determine which resources need to be managed.
Voting Disks
Voting Disks help determine which nodes belong to the cluster.
They are used to:
- Detect node failures.
- Prevent split-brain conditions.
- Maintain cluster integrity.
Each node continuously exchanges heartbeat information through the Voting Disks and the private interconnect.
SCAN (Single Client Access Name)
Before SCAN, clients needed to know every node in the cluster.
Example:
Node1 Node2 Node3
With SCAN:
Application
|
SCAN
|
Oracle RAC Cluster
Clients connect to a single hostname, while Oracle automatically directs them to the appropriate node.
SCAN simplifies client configuration and supports cluster expansion without requiring application changes.
Virtual IP (VIP)
Each RAC node has a Virtual IP address in addition to its public IP.
If a node fails:
- The VIP is relocated to another node.
- Client connection failures are detected more quickly.
- Applications can reconnect without waiting for standard TCP timeouts.
This improves the overall user experience during failover events.
Oracle Services
Services provide a logical way to manage application workloads.
Instead of connecting to a specific instance, applications connect to a service.
Example:
Payroll Service
|
Instance 1
Instance 2
Benefits include:
- Workload balancing.
- High availability.
- Planned maintenance with minimal disruption.
High-Level Startup Sequence
When a RAC cluster starts, the process generally follows this order:
Operating System
|
v
Oracle Clusterware
|
v
Oracle ASM
|
v
Listeners
|
v
Database Instances
|
v
Database Services
Each layer depends on the previous one, which is why startup and shutdown operations are coordinated by Clusterware.
Common Misconceptions
RAC Is a Backup Solution
No. RAC provides high availability, not backup or disaster recovery. RMAN remains essential.
RAC Replaces Data Guard
No. RAC protects against server failures within a site, while Data Guard protects against site-level disasters. They are complementary technologies.
RAC Automatically Improves Every Workload
Not always. Applications with heavy block contention or frequent access to the same data may require tuning to take full advantage of RAC.
More Nodes Always Mean Better Performance
Adding nodes increases capacity, but performance depends on application design, interconnect quality, storage performance, and workload characteristics.
Best Practices
- Use redundant private interconnects.
- Deploy Oracle ASM for shared storage management.
- Configure SCAN correctly.
- Use services instead of connecting directly to instances.
- Monitor interconnect latency and packet loss.
- Keep Grid Infrastructure and Database Release Updates aligned with Oracle recommendations.
DBA Tip
One of the first checks I perform when troubleshooting a RAC environment is to determine where the problem is occurring.
Ask yourself:
- Is it a Clusterware issue?
- Is ASM healthy?
- Is the shared storage accessible?
- Is the private interconnect stable?
- Is the problem limited to one instance or affecting the entire cluster?
Breaking the problem into layers helps isolate the root cause much faster than treating RAC as a single component.
A RAC cluster is a collection of independent services working together. Understanding those services individually makes troubleshooting far more effective.
Conclusion
Oracle RAC is much more than multiple servers sharing a database. It is a tightly integrated architecture that combines Clusterware, ASM, shared storage, private networking, and Cache Fusion to provide high availability and scalability.
Understanding these building blocks is essential before diving into installation, administration, and troubleshooting. Every advanced RAC topic—from OCR recovery to Cache Fusion performance—depends on the concepts introduced in this article.
Google+
Facebook
