Oracle Real Application Clusters (RAC) is a database clustering solution that enables multiple servers to operate as a single, unified system. Designed to deliver instance resiliency, scalability, and fault tolerance, Oracle RAC allows a single database to run across multiple interconnected nodes. With a myriad of features and architecture designs to meet a variety of needs, this architecture is a unique solution with optimal performance, which makes it an ideal choice for many mission-critical applications.

From RAC flex clusters, RAC for Multitenant, to RAC One-node, RAC has come a long way since its introduction in Oracle 9i. For this article, a standard RAC, 2-node database environment will be used with the simplest architecture. No Automatic Storage Management(ASM) for file system management or multiple voting disks, (we’ll assume that mirroring at the file system level has been implemented) and we’ll only have two nodes, when in truth, RAC can scale to as many nodes as 100 in Oracle 19c.

Fig. 1, Non-Multitenant, 2-Node, RAC Database

As for a disclaimer: Anyone who has done extensive optimization in relational systems will recognize that scaling compute will not guarantee performance, but when used as part of a full optimization exercise, (infrastructure, code, application, and database design is all optimized) RAC can provide unique value at the database level to scale, especially around transactional or analytics workloads when used correctly.

At its core, Oracle RAC uses a shared-everything architecture, where all nodes in the cluster access the same set of database files stored on shared storage. This configuration provides the foundation for seamless scalability and dynamic workload management, which are essential for many mission-critical Oracle workloads.

In this article I will cover how RAC can help when scale Oracle workloads.

Horizontal Scalability

Oracle RAC excels at horizontal scaling by allowing additional nodes to be added to the cluster as workload demands grow. Horizontal scaling differs from vertical scaling, which uses a single, higher resource machine to achieve scaling needs. RAC distributes the workload across multiple nodes, is seamless and can be performed with minimal disruption to ongoing operations. If distributed dynamically or manually configured with even distribution across each node, Oracle RAC ensures that no single node becomes a performance bottleneck.

Each node in the cluster runs an Oracle Database instance, and these instances communicate with one another to coordinate access to shared data. This design ensures that applications can utilize the combined processing power of all nodes, delivering improved performance and responsiveness.

From a technical perspective, Oracle RAC uses a Global Cache Service (GCS) and Global Enqueue Service (GES) to manage data access and locking across nodes. These services coordinate memory and disk access, ensuring that all nodes have a consistent view of the database. This architecture supports efficient scaling while maintaining data integrity.

Shared Global Cache

The shared global cache is a pivotal component of Oracle RAC’s architecture, enabling efficient data sharing across all nodes in the cluster. Managed by the Global Cache Service (GCS), the shared cache ensures that data blocks accessed by one node are instantly available to other nodes, eliminating the need for redundant reads from disk.

This is achieved through a sophisticated mechanism of cache fusion, where data is transferred directly between nodes over the high-speed interconnect. The shared global cache not only reduces disk I/O but also ensures data consistency by implementing a global lock management system through the Global Enqueue Service (GES). This architecture supports low-latency access to shared data, making it possible to scale workloads effectively while maintaining optimal performance.

Dynamic Workload Distribution

Oracle RAC employs sophisticated workload distribution mechanisms to ensure optimal resource utilization. Using features like instance-level load balancing and database services, Oracle RAC dynamically assigns workloads to nodes with the best available capacity. This ensures that user sessions and transactions are evenly distributed, minimizing latency and maximizing throughput.

Additionally, Oracle RAC allows administrators to define specific services for different workloads, such as OLTP and analytics. These services can be mapped to specific nodes or distributed across the cluster, providing granular control over workload management.

As the workload increases, additional nodes can be added to scale the RAC database. Parallel processing can distribute across multiple nodes, eliminating cross competition when executed on a single host.

Fig. 2, Adding a Third Node to a RAC Cluster

Although nodes can be increased to scale, it’s important to identify the amount of IO that will be required and to distribute datafiles across the shared storage optimally. My experience has shown that scaling is limited if storage isn’t able to scale at the same rate as nodes added to the RAC environment.

Instance Resiliency with Failover Capabilities

Instance resiliency is a cornerstone of Oracle RAC’s design, but it shouldn’t be confused with full high availability but viewed as part of the overall architecture. In the event of a node failure, the workload is automatically redistributed to the remaining nodes in the cluster, dependent on the resources available. Node eviction is handled by the Voting Disks, which is an essential component of RAC shared storage. The recommended practice is to have mirroring set up to protect this vital component of RAC as the Voting Disks manage which nodes are part of the RAC cluster and communicates with each node via a heartbeat to the Cluster Services Sync Daemon (CSSD), which monitors the health of the RAC environment. If a quorum isn’t met, (minimum number of votes) for the cluster to continue operating the node in question, an eviction will occur.

In a well-architected RAC environment after a node eviction, the additional workload is handled seamlessly by the remaining nodes and the application tier reconnects to the database, with the session commencing again. This failover capability ensures little to no interruption to database operations, safeguarding against hardware or software failures with modern applications.

The active-active configuration of Oracle RAC—where all nodes handle workloads simultaneously—maximizes availability while maintaining efficient resource usage. An additional benefit of RAC is the ability to perform rolling batches and upgrades, allowing little to no downtime while performing regular maintenance. This capability is critical for many enterprises that require 24/7 database up time.

Shared-Everything Architecture

The shared-everything architecture of Oracle RAC enables all nodes to access the same database files stored on shared storage. This design eliminates the need for data replication between nodes, reducing complexity and ensuring data consistency.

From a technical perspective, Oracle RAC uses a Global Cache Service (GCS) and Global Enqueue Service (GES) to manage data access and locking across nodes. These services coordinate memory and disk access, ensuring that all nodes have a consistent view of the database. This architecture supports efficient scaling while maintaining data integrity.

Conclusion

Oracle RAC is a unique relational database architecture for scaling workloads in enterprise environments. By leveraging its shared-everything architecture, dynamic workload management, and horizontal scalability, Oracle RAC delivers impressive performance, availability, and flexibility. Its ability to grow with your workloads, maintain availability, and optimize performance makes it a popular solution for transactional Oracle workloads.