Overview of Oracle RAC

Oracle Real Application Clusters (RAC) is a powerful feature of Oracle Database that enables
high availability and scalability for mission-critical applications. By allowing multiple
instances of Oracle Database to run on separate servers, Oracle RAC provides a robust
solution that distributes workload across multiple nodes. This setup not only enhances
performance by balancing the load but also ensures minimal downtime, as even if one node
fails, others continue to manage the database operations. Ideal for environments requiring
24/7 availability and the capacity to handle large volumes of transactions, Oracle RAC is
commonly used in sectors like banking, telecom, and e-commerce. Its seamless integration
with Oracle Data Guard for disaster recovery further strengthens an organization’s resilience,
providing a reliable infrastructure for data-intensive operations.

Oracle Real Application Clusters (RAC) is a complex, high-availability solution designed for
Oracle databases to enhance reliability, availability, and scalability. By allowing multiple
servers to access a single Oracle database, RAC spreads the load across nodes and offers
failover capabilities. Here’s a comprehensive architectural overview of Oracle RAC, detailing
its components, services, and working functionalities.
1. Oracle RAC Architecture and Components
Cluster Nodes: Each node in the cluster runs its own instance of the Oracle database,
connected to other nodes by a private interconnect network.

Clusterware: Oracle Clusterware is the core of the RAC architecture, enabling multiple
servers to operate as a single system by coordinating cluster node resources and managing
cluster membership.
ASM (Automatic Storage Management): ASM manages database storage and provides file-
system-level redundancy, rebalancing, and mirroring across disk groups to avoid data loss in
case of disk failure.
Database Instances: Each node hosts an Oracle Database instance with its own memory
structures and background processes. These instances communicate with each other,
sharing data across the nodes.

2. Core Components and Processes

Oracle Clusterware Services (CRS): Oracle Clusterware manages node membership and
allows nodes to join and leave the cluster. CRS manages critical background processes and
handles failure scenarios.

Oracle Local Registry (OLR): The OLR is a local storage of clusterware configuration specific
to each node. It contains essential information about Oracle Clusterware and allows the
Clusterware to start in the absence of the Oracle Grid Infrastructure.
Voting Disk (VD): Voting Disks play a role in ensuring cluster consistency by maintaining
quorum among nodes. In case of a node failure, VD helps in deciding whether to evict a
node to avoid “split-brain” situations.

3. Networking and Communication

SCAN (Single Client Access Name): SCAN provides a single, unified entry point for the
cluster, balancing connection requests across nodes without relying on specific IP addresses.
VIP (Virtual IP): VIP addresses ensure client redirection in case a node fails. If a node goes
down, its VIP address migrates to a surviving node, ensuring minimal interruption in
connectivity.
Interconnect: This is a private network that provides fast and direct communication between
the nodes. The interconnect is crucial for RAC internode communication, allowing nodes to
exchange cache information and maintain a consistent database state.
4. Background Processes and Their Roles in RAC
Cluster Ready Services (CRS): CRS is responsible for managing resources, starting the Oracle
Clusterware, and ensuring that all required cluster services are up. It coordinates instance
restarts if there is a failure and manages voting disk activities.

Cluster Synchronization Service (CSS): CSS coordinates cluster node membership and
synchronizes heartbeat information among nodes, ensuring all instances are in sync.
Oracle High Availability Services (OHAS): OHAS manages other Oracle background
processes such as CSSD, CSS, and CRS and ensures they run consistently across nodes.

Grid Infrastructure: Grid Infrastructure underpins the RAC environment, supporting ASM
and Clusterware to handle storage and cluster configurations across nodes. It simplifies
management by providing a unified storage pool.
5. Oracle RAC Working Process

Step 1: Starting Clusterware Services

OHAS starts the Oracle Clusterware by initiating background processes like crsd.bin for
Cluster Ready Services and cssd.bin for the Cluster Synchronization Service.
CSSD checks the status of each node using heartbeats stored in the Voting Disk. It verifies
connectivity and cluster membership before proceeding with node startup.
CRS is initiated, which brings up essential resources and manages cluster components.
Step 2: ASM and Storage Management Initialization
ASM initializes, providing a volume manager and file system for database storage. It is
managed by the Oracle Clusterware and ensures consistent data access across nodes.

ASM starts its own set of background processes (ASM instance), managing disk groups and
rebalancing workloads across disks to prevent bottlenecks.
Step 3: Database Instance Startup
Each node starts its own instance of the Oracle database, connecting to the shared ASM
storage. Each instance has dedicated processes for memory and process management (e.g.,
DBWR, LGWR).
Cache Fusion, facilitated by the interconnect, allows instances to share data in real-time,
synchronizing blocks among nodes to ensure data consistency.
Step 4: SCAN and VIP Addressing

The SCAN service provides a single point of entry for clients. It allows connections to be
routed across nodes, depending on load and node availability.
VIPs facilitate quick redirection of connections in case a node goes down. If a node fails, its
VIP will move to another node, minimizing disruption for the clients.

6. Failover and Recovery in RAC

In the event of a node failure, Oracle Clusterware identifies the failed node and performs
eviction using the Voting Disk to prevent split-brain.
CRS automatically restarts the failed instance on another node, and VIP migrates, ensuring
high availability.

ASM rebalance may occur if disk groups are affected, ensuring continuous access to data
without impact on database operations.
Oracle RAC's combination of Clusterware, ASM, Grid Infrastructure, and network
components ensures a high-performing, resilient, and scalable database environment. By
balancing workloads and providing failover capabilities, Oracle RAC supports businesses with
demanding, always-available applications.

Oracle Real Application Clusters (RAC) employs various background processes across nodes
to ensure synchronization, data consistency, high availability, and efficient workload
distribution. Each instance in an Oracle RAC environment runs several background
processes, some of which are specific to RAC, allowing it to manage multiple nodes as a
cohesive cluster. Here’s an overview of key background processes and their roles in RAC:
1. Clusterware Processes

Cluster Ready Services (CRS): Manages high availability for Oracle Clusterware resources,
controlling startup and shutdown for resources like databases and instances. CRS is essential
in restarting components automatically when failures occur.
Cluster Synchronization Services Daemon (CSSD): Coordinates cluster membership, node
monitoring, and heartbeat communication. CSSD uses the voting disk to monitor
connectivity between nodes and prevents "split-brain" scenarios, ensuring only connected
nodes stay active in the cluster.
Oracle High Availability Service Daemon (OHASD): Manages Clusterware stack components
and starts other important services like CSSD, CRSD, and ASM. OHASD ensures the
availability of Oracle resources across the nodes.
Event Management Daemon (EVM): This process captures and publishes events (e.g., node
join, node leave) in the RAC environment, ensuring all cluster members are aware of state
changes.
2. Cache Fusion and Inter-Instance Coordination Processes
Global Cache Service Processes (LMSn): These are responsible for Cache Fusion, managing
data block transfers between instances. If one instance needs data held in the cache of
another instance, LMS processes facilitate the transfer, ensuring real-time data consistency
across nodes.
Global Enqueue Service Processes (LMD): Manages global locks and enqueues across
instances, allowing nodes to acquire necessary locks for data access and modification. LMD
processes synchronize global resource requests to prevent data conflicts.

Global Enqueue Service Daemon (LMON): Manages instance membership and enforces
consistent cache states across all instances. It tracks which instances are part of the cluster
and performs instance recovery if a node fails.
3. ASM and Storage Management Processes

ASM Rebalance (ARBn): ASM rebalance processes manage the distribution of data across
disks, ensuring balanced storage usage and consistent performance. If a disk is added or
removed, ARBn processes redistribute data without impacting the database.
ASM Background Processes (e.g., ASMB): ASMB coordinates with Cluster Synchronization
Services (CSS) to maintain information about the storage layout and ensures ASM remains
synchronized across instances.
4. Connection Management and Failover Processes
Virtual IP Processes (VIP): VIPs ensure clients connect seamlessly to the RAC cluster. If a
node fails, its VIP address transfers to another node, allowing client connections to persist
with minimal interruption.
Single Client Access Name (SCAN) Listener: The SCAN Listener listens for client connections
and routes them across available nodes, balancing the load. SCAN helps with dynamic
addition or removal of nodes, as clients do not need to be updated with IP addresses or
hostname changes.
5. Database Processes in RAC
DB Writer Process (DBWR): Manages writing dirty (modified) blocks from the cache to disk.
In RAC, DBWR works in sync with Cache Fusion to ensure modified blocks are accessible to
other nodes.

Log Writer Process (LGWR): Writes redo entries from the log buffer to the redo log file.
LGWR plays a critical role in redo log management across instances, helping to recover
transactions in the event of a failure.
Redo Transport Processes: In RAC, these processes synchronize redo logs across instances to
maintain data consistency. If a transaction involves multiple nodes, these logs allow
replaying the transaction on other nodes during recovery.
SMON (System Monitor) and PMON (Process Monitor): SMON handles instance recovery if
a node fails and manages resource cleanup across nodes, while PMON monitors and
recovers failed processes, managing session resources efficiently in a RAC setup.
6. Inter-Node Communication Processes
Private Interconnect (Network Channel): The private interconnect is a dedicated network
that allows fast communication between nodes, which is vital for Cache Fusion and real-time
data synchronization. This network keeps nodes in sync by passing data blocks and locks
quickly across instances.
Each of these background processes works in unison to ensure the RAC environment
maintains data consistency, high availability, and scalability. They help Oracle RAC achieve its
objectives of fault tolerance and high performance, which are essential for mission-critical,
multi-node databases.

Prepared By:

Zaheer Abbas Mitaigiri (OCA, OCP, OCE, OCS),

Oracle Certified Specialist.