Master Oracle 19c RAC Architecture in 41 Diagrams – Quick Technical Guide

Architecture Diagram 01: Oracle Database Configurations

Oracle databases can be deployed as a single‑instance (SI) database or as a Real Application Cluster (RAC) database. In a single‑instance setup, the software, files, memory, and processes reside on one server, establishing a one‑to‑one relationship between instance and database. In RAC, a database can have up to 100 instances, all accessing the same set of data files, and all servers must belong to the same RAC cluster.

Architecture Diagram 02: RAC Overview

Every RAC cluster installs the Grid Infrastructure (GI) on each node, which includes Automatic Storage Management (ASM) and Oracle Clusterware (Clusterware). Instances access shared storage via local ASM instances, and each node must have both public and private network interfaces, with multiple NICs recommended for redundancy.

Architecture Diagram 03: RAC Database

A RAC database consists of multiple instances that share the same database files on shared storage, typically provided by local ASM instances on each node. Oracle ASM 19c supports only Flex ASM, which controls the number of ASM instances in the cluster.

Architecture Diagram 04: RAC Database Instances

Each RAC instance runs its own set of processes and memory, but all instances share the same data files. Cache fusion provides a disk‑less cache‑coherency mechanism that transfers data blocks directly between instance memory caches.

Architecture Diagram 05 & 06: RAC One Node Overview

RAC One Node is a single‑instance version of RAC that runs on one node but can be moved to another node for failover. Only one instance is active at a time; if it crashes, there is a brief outage before the instance restarts on another node.

Architecture Diagram 07: RAC Tools

Management utilities include SRVCTL, Oracle Enterprise Manager, SQL*Plus, and the Cluster Verification Utility (CVU). CVU validates storage, network, and software prerequisites before and after RAC installation.

Architecture Diagram 08: Database Files in RAC

All instances must access every data file, control file, and redo log. Each instance has its own rollback tablespace, but all rollback tablespaces reside on shared storage. Redo logs are multiplexed and mirrored when ASM provides redundancy.

Architecture Diagram 09: Server Parameter File in RAC

RAC uses a common SPFILE stored in ASM or a shared file system. Parameters such as CLUSTER_DATABASE=TRUE and CLUSTER_DATABASE_INSTANCES control cluster behavior. Use ALTER SYSTEM SET with an optional SID='' clause to apply changes to all instances.

Architecture Diagram 10: TDE Keystores in RAC

Transparent Data Encryption (TDE) wallets can be stored as a shared copy on ASM or as local copies on each node. When using a shared wallet, no extra configuration is required.

Architecture Diagram 11: Undo Tablespaces in RAC

Each instance has its own undo tablespace, but all instances can read any undo block. Undo tablespaces can be assigned via the UNDO_TABLESPACE parameter in the SPFILE or PFILE, and can be switched dynamically with ALTER SYSTEM SET UNDO_TABLESPACE=....

Architecture Diagram 12: Redo and Redo Threads

Each instance runs at least two redo log groups, each with at least two members (primary and mirror). DBCA creates compliant configurations automatically; manual creation is required only for administrator‑managed databases.

Architecture Diagram 13: Backup Files in RAC

Backup files have the same characteristics as in a single‑instance database but must be placed on shared storage so that any RAC instance can access them for restore operations.

Architecture Diagram 14: RAC and Database Features

When using RAC with a multitenant container database (CDB), each pluggable database (PDB) can be served by any instance or subset of instances. Services are defined dynamically to route client connections.

Architecture Diagram 15: Listeners in RAC

SCAN (Single Client Access Name) provides a virtual IP that resolves to multiple IPs. SCAN listeners route client connections to the least‑loaded local listener on a node.

Architecture Diagram 16–18: Cluster Nodes and Storage Options

Clustered nodes run Grid Infrastructure, store local copies of the OCR and OLR, and must have access to shared storage. Supported shared storage includes ASM (recommended), NFS (Linux on POWER excluded), OCFS2, GPFS, and ACFS. Storage must be cluster‑aware and certified for RAC.

Architecture Diagram 19–21: Cluster Domains and Extended Clusters

Standalone clusters consist of nodes with shared storage, interconnects, and ASM. Extended clusters span multiple geographic sites, providing site‑level redundancy. Domain Services Clusters (DSC) offer centralized services to member clusters.

Architecture Diagram 22–24: OCR, Voting Disks, and Clusterware Tools

The OCR (Oracle Cluster Registry) stores cluster configuration on shared storage, with up to five locations. Voting disks provide a fallback mechanism for node health detection. Tools such as crsctl, srvctl, asmcmd, and Enterprise Manager manage resources, services, and ASM.

Architecture Diagram 25–28: Network Configuration and Cluster Services

Each node requires at least one public and one private network interface; multiple NICs and link aggregation are recommended. Cluster Ready Services (CRS) and High Availability Services (HAS) run as daemon processes to monitor and restart resources.

Architecture Diagram 29–31: ONS, Global Names Service, and Server Pools

Oracle Notification Service (ONS) delivers HA events to client applications via the Fast Application Notification (FAN) framework. Server pools group nodes for resource isolation; RAC can be managed in policy‑based or administrator‑managed modes.

Architecture Diagram 32–38: ASM Architecture and Tools

ASM provides shared storage management. An ASM instance includes a small SGA (default 256 MB) with Shared Pool, Large Pool, ASM Cache, and Free Memory. Background processes (CKPT, DBWn, LGWR, SMON, etc.) manage I/O and metadata. ACFS (ASM Cluster File System) offers POSIX‑compliant file services on top of ASM, while ADVM enables dynamic volume management.

Architecture Diagram 39–41: Fleet Patching and Provisioning (FPP)

FPP provides centralized patching and configuration for Grid Infrastructure nodes. It relies on ASM/ACFS for storing golden images and uses commands such as rhpctl import, rhpctl add client, and rhpctl add workingcopy to manage images and client nodes.

Reference

Original source: Oracle Real Application Clusters 19c Technical Architecture.

https://www.oracle.com/webfolder/technetwork/tutorials/architecture-diagrams/19/rac/main.html