Introduction to Oracle RAC

Provides an overview of Oracle Real Application Clusters (Oracle RAC) installation and administration, and various components and functions.

Note:

A multitenant Container Database (CDB) is the only supported architecture in Oracle Database 21c and later releases.

Overview of Oracle RAC

Oracle Real Application Clusters (Oracle RAC) enables multiple database instances running on separate servers to access one shared database, providing scalability, higher throughput, and protection from single-server failure. Each instance has its own redo thread and undo tablespace, while Oracle Clusterware and Oracle ASM provide clustered infrastructure and storage management. RAC supports transparent application operation, Cache Fusion coordination, and extended clusters for enhanced site availability, although comprehensive disaster recovery may require Oracle Data Guard.

Overview of Oracle Multitenant with Oracle RAC

A multitenant container database can run on Oracle RAC, with each pluggable database (PDB) available on all instances or a selected subset. Dynamic database services control application access to PDBs and determine where they are available, while PDB isolation supports workload consolidation. Newly plugged PDBs are not automatically started until an appropriate dynamic service runs, although administrators can manually enable access on individual instances.

Overview of Installing Oracle RAC

Oracle RAC deployment requires installing Oracle Grid Infrastructure and Oracle AI Database software, then creating the database with Oracle DBCA; Fleet Patching and Provisioning can automate and standardize these activities. Grid Infrastructure must be installed first and be the same version or newer than the database software, and mixed database releases in one cluster require Grid Infrastructure at least as new as the highest database release. Database software is installed cluster-wide, generally into separate read-only Oracle homes, and database creation requires a default Grid Infrastructure listener. Oracle RAC clusters can later be extended through Fleet Patching and Provisioning, cloning scripts, or node-addition utilities after Grid Infrastructure and database homes are deployed on the new nodes.

Overview of Oracle Real Application Clusters One Node

Oracle RAC One Node runs a single instance of an RAC-enabled database on one cluster node during normal operation while retaining the infrastructure and flexibility of a full RAC environment. It supports online relocation without application downtime, resource control through Instance Caging, and later online conversion to multi-instance RAC as workloads grow. SCAN, Application Continuity, Fast Application Notification, and Transparent Application Failover help minimize client disruption, while administrators must maintain an available candidate node and configure at least one dynamic database service for failover.

Overview of Oracle Clusterware for Oracle RAC

Oracle Clusterware supplies the integrated infrastructure for RAC, managing node membership, global resources, high availability, and dependencies among databases, instances, PDBs, services, listeners, VIPs, SCAN components, and applications. These CRS resources are configured in the Oracle Cluster Registry and administered primarily with SRVCTL, with resources automatically starting and restarting as needed. The page also describes RAC temporary tablespaces, including instance-specific and shared storage, allocation priorities, per-instance temporary files, atomic DDL management from read-write instances, user and database defaults, and dictionary views that expose sharing and instance information.

Overview of Oracle RAC Architecture and Processing

Oracle RAC requires cluster-aware shared storage, public and private networks, interprocess communication, multiple coordinated database instances, and node-status monitoring. All database files must reside on supported shared storage such as Oracle ASM, ACFS, certified cluster file systems, or qualified NFS solutions. Public networks provide client access, while the private interconnect carries Cache Fusion and cluster communications and must not be used for user traffic. Dynamic database services and SCAN provide controlled, load-balanced connectivity, with VIPs enabling rapid failure detection and connection redirection. Cache Fusion, supported by GCS, GES, and the GRD, transfers blocks between instance caches and coordinates global resources; RAC background processes perform cache, transaction, monitoring, recovery, and management functions.

Overview of Automatic Workload Management with Dynamic Database Services

Dynamic database services group application workloads, define availability and performance characteristics, route work to selected instances, and enable workload prioritization through Resource Manager consumer groups. Applications and server-side components connect through service names, while services support connection load balancing, Load Balancing Advisory, FAN, Fast Connection Failover, Runtime Connection Load Balancing, Transaction Guard, Application Continuity, SCAN, and AWR-based service metrics. Administrators should create and manage cluster services for application connectivity rather than relying on automatically created default services, which do not support the full workload-management feature set.

Overview of Blocker Resolver

Blocker Resolver automatically detects, analyzes, and attempts to resolve system delays in both single-instance and RAC databases. It scans processes for resource holders causing waits, evaluates local and cross-instance blocking conditions, applies heuristics, and can terminate a blocking holder so subsequent work can proceed. It also automates diagnostic collection formerly requiring manual support intervention and reports actions or detected delays to administrators through ORA-32701 messages in the alert log.

Overview of Database In-Memory and Oracle RAC

Each RAC node maintains its own In-Memory column store, with objects distributed across the cluster by default and ideally sized consistently across nodes. Administrators can disable the store on selected nodes, use the Base Level feature with up to 16 GB per instance, and control distribution with the INMEMORY DISTRIBUTE clause. On engineered systems, DUPLICATE options can mirror objects for redundancy or populate complete copies on every node; on non-engineered systems, DUPLICATE is treated as NO DUPLICATE.

Overview of Managing Oracle RAC Environments

Effective RAC management begins with analyzing business availability requirements and selecting an architecture that balances protection, cost, and operational objectives. Administrators use SRVCTL, Fleet Patching and Provisioning, Enterprise Manager, SQL*Plus, Configuration Verification Utility, DBCA, and NETCA for deployment and administration, with Enterprise Manager recommended for centralized management. Monitoring relies on Enterprise Manager, global GV$ views containing instance identifiers, and diagnostic tools such as ADDM and AWR. RAC generally requires no special application tuning, while Cache Fusion, dynamic resource allocation, and RAC-specific performance views support scalable performance evaluation.