# Real Application Clusters Administration and Deployment Guide

This file contains the text from each Real Application Clusters Administration and Deployment Guide article landing page, release 26ai.

# 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.

Read More: [Overview of Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-oracle-rac.html)

## 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.

Read More: [Overview of Oracle Multitenant with Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-oracle-multitenant-with-oracle-rac.html)

## 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.

Read More: [Overview of Installing Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-installing-oracle-rac.html)

## 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.

Read More: [Overview of Oracle Real Application Clusters One Node](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-oracle-real-application-clusters-one-node.html)

## 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.

Read More: [Overview of Oracle Clusterware for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-oracle-clusterware-for-oracle-rac.html)

## 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.

Read More: [Overview of Oracle RAC Architecture and Processing](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-oracle-rac-architecture-and-processing.html)

## 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.

Read More: [Overview of Automatic Workload Management with Dynamic Database Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-automatic-workload-management-with-dynamic-database-services.html)

## 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.

Read More: [Overview of Blocker Resolver](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-blocker-resolver.html)

## 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.

Read More: [Overview of Database In-Memory and Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-database-in-memory-and-oracle-rac.html)

## 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.

Read More: [Overview of Managing Oracle RAC Environments](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/introduction-to-oracle-rac/overview-of-managing-oracle-rac-environments.html)


# Administering Storage in Oracle RAC

Oracle recommends Oracle Automatic Storage Management (Oracle ASM) as a storage management solution that provides an alternative to conventional volume managers, file systems, and raw devices.

## About Oracle ASM

Oracle Automatic Storage Management (Oracle ASM) is a volume manager and file system for Oracle AI Database files in single-instance and Oracle RAC environments. It organizes storage into disk groups, distributes file contents evenly for consistent performance, supports online disk addition and removal with automatic rebalancing, and provides normal, high, or external redundancy options. Together with Oracle Managed Files, ASM simplifies file creation, naming, deletion, and storage administration while supporting coexistence with raw disks and third-party file systems and management through SQL\*Plus, ASMCMD, and ASMCA.

Read More: [About Oracle ASM](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-storage-in-oracle-rac/about-oracle-asm.html)

## Overview of Storage Management for Oracle RAC

Oracle RAC requires all data files, instance undo tablespaces, and redo logs to reside on shared storage accessible by every instance. Oracle recommends Oracle ASM disk groups, although certified cluster file systems are also supported, along with a shared SPFILE containing instance-specific settings. Raw block storage is no longer supported by Oracle AI Database or Oracle Clusterware, while storage features such as Oracle ASM, Oracle Managed Files, and automatic segment-space management generally operate in RAC as they do in single-instance databases.

Read More: [Overview of Storage Management for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-storage-in-oracle-rac/overview-of-storage-management-for-oracle-rac.html)

## Data File Access in Oracle RAC

Every Oracle RAC instance must access every data file, and instances verify file accessibility during startup and when tablespaces or data files are added or brought online. Verification fails if a file is placed on storage unavailable to an instance or if instances access different copies of the same file. After correcting access problems, run ALTER SYSTEM CHECK DATAFILES on each instance to confirm consistent data file access.

Read More: [Data File Access in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-storage-in-oracle-rac/data-file-access-in-oracle-rac.html)

## NFS Server for Storage

Oracle AI Database can operate as an NFS server, responding to client requests while storing files and metadata inside the database. It can automatically replicate files associated with a primary database to a standby database and can store unstructured content such as email. Oracle file systems can be created or destroyed and accessed through the NFS server using the documented SecureFiles and Large Objects procedures.

Read More: [NFS Server for Storage](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-storage-in-oracle-rac/nfs-server-for-storage.html)

## Redo Log File Storage in Oracle RAC

Each Oracle RAC instance must have at least two redo log groups, which Oracle DBCA allocates automatically during database creation; group counts and sizes can be adjusted later, and adding a cluster node configures its redo logs. Instances switch groups as logs fill, archive completed groups when running in ARCHIVELOG mode, and participate in recovery checks. When an instance is removed, its redo thread should be disabled so recovery does not unnecessarily examine it.

Read More: [Redo Log File Storage in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-storage-in-oracle-rac/redo-log-file-storage-in-oracle-rac.html)

## Automatic Undo Management in Oracle RAC

Oracle AI Database automatically manages undo segments in an undo tablespace assigned to each RAC instance, while all instances can read cluster-wide undo blocks for consistent reads and can update eligible undo tablespaces during recovery. Assign each instance through its UNDO\_TABLESPACE parameter in the SPFILE or PFILE, with automatic allocation available when Oracle Managed Files is enabled. All RAC instances must use the same undo management mode, and policy-managed database deployment is desupported in Oracle AI Database 26ai.

Read More: [Automatic Undo Management in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-storage-in-oracle-rac/automatic-undo-management-in-oracle-rac.html)

## Oracle Automatic Storage Management with Oracle RAC

Oracle ASM distributes database files evenly across disk-group storage, can mirror files for protection, and reduces storage administration without requiring I/O tuning in RAC. Grid Infrastructure creates an ASM instance on each cluster node, with each instance using an SPFILE or PFILE; parameter files and nondefault listener entries should be backed up. ASM disk groups require shared, properly permissioned storage and can be administered with ASMCA, Enterprise Manager, SQL\*Plus, SRVCTL, or installation tools, while CVU verifies ASM and shared-storage integrity across nodes. ASM automatically rebalances files after disk changes, coordinates metadata among instances, and supports preferred read failure groups for locality in extended-distance clusters through ASM\_PREFERRED\_READ\_FAILURE\_GROUPS. Installing Grid Infrastructure converts nonclustered ASM to clustered ASM, and SRVCTL can add, remove, start, stop, configure, and report ASM instances. Disk groups can be created and managed independently of database creation through ASMCA or Enterprise Manager.

Read More: [Oracle Automatic Storage Management with Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-storage-in-oracle-rac/oracle-automatic-storage-management-with-oracle-rac.html)


# Administering Database Instances and Cluster Databases

This chapter describes how to administer Oracle Real Application Clusters (Oracle RAC) databases and database instances.

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

> **See Also:**
>
> The Oracle Enterprise Manager Cloud Control online help for more information about Oracle Enterprise Manager Cloud Control.

## Overview of Oracle RAC Database Administration

Oracle RAC administration uses the SYSRAC privilege and tools such as SRVCTL, Oracle Enterprise Manager, and SQL\*Plus. Since Oracle Database 21c, administrator-managed and policy-managed capabilities have converged into a single CDB/PDB-oriented model, while policy-managed deployment is desupported in Oracle AI Database 26ai. The model supports dynamic PDB placement, scalable cluster resources, automatic redo and undo provisioning, and SCAN-based client connectivity.

Read More: [Overview of Oracle RAC Database Administration](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/overview-of-oracle-rac-database-administration.html)

## Tools for Administering Oracle RAC

Oracle RAC is administered primarily with SRVCTL, Oracle Enterprise Manager, and SQL\_Plus. SRVCTL centrally manages databases, instances, services, and Clusterware resources; Oracle Enterprise Manager provides graphical, cluster-wide and instance-specific monitoring and administration; and SQL\_Plus performs operations against the current instance, requiring explicit instance targeting for remote or multi-instance changes. Use SYSASM rather than SYSRAC for ASM administration.

Read More: [Tools for Administering Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/tools-for-administering-oracle-rac.html)

## Starting and Stopping Instances and Oracle RAC Databases

Oracle RAC instances and databases can be started or stopped with Oracle Enterprise Manager, SRVCTL, or SQL\_Plus, provided Oracle Grid Infrastructure is running on the target node. Startup state determines available operations, and Oracle does not support running multiple instances of the same database on one node. SRVCTL and Enterprise Manager can manage all instances together, while SQL\_Plus is primarily instance-oriented.

Read More: [Starting and Stopping Instances and Oracle RAC Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/starting-and-stopping-instances-and-oracle-rac-databases.html)

## Starting and Stopping PDBs in Oracle RAC

PDBs are Oracle Clusterware resources in Oracle Database 21c and later, so SRVCTL manages their startup, shutdown, placement, services, policies, cardinality, and status. Automatic PDBs start with their CDB, while manual policies preserve appropriate state across Clusterware restarts. Administrators can start or stop PDBs cluster-wide or on selected nodes, disable automatic restart, inspect configuration, and adjust cardinality and resource settings subject to creation-time restrictions.

Read More: [Starting and Stopping PDBs in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/starting-and-stopping-pdbs-in-oracle-rac.html)

## Local Rolling Database Maintenance

Oracle AI Database 26ai supports optional local rolling, out-of-place maintenance for Oracle RAC and RAC One Node, allowing a second instance from a new Oracle home to run temporarily on the same node before the old instance stops. This reduces connection migration and brownout time while preserving PDB placement and services. The feature requires OMF, an SPFILE, sufficient CPU, memory, storage, redo, and undo capacity, and controlled SRVCTL configuration and instance transfer; failed transfers can be fully or partially reverted.

Read More: [Local Rolling Database Maintenance](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/local-rolling-database-maintenance.html)

## Pluggable Database Rank

The PDB `-rank` setting assigns relative workload importance to cardinality-based PDBs under the RANK management policy, with higher values receiving priority. Oracle Clusterware uses rank to determine startup order, instance shutdown decisions, and which PDBs remain running when resources are insufficient or nodes fail. Ranking is cluster-wide and is evaluated before CPU requirements during failover and resource allocation.

Read More: [Pluggable Database Rank](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/pluggable-database-rank.html)

## Pluggable Database Placement

Oracle RAC supports preferred and available PDB placement, which restricts a PDB to explicitly designated CDB instances or nodes, and floating placement, which allows a cardinality-defined PDB to run dynamically on eligible CDB instances. Cardinality controls the simultaneous node count, while `-maxcpu` and `-mincpuunit` influence resource evaluation. Placement can be configured when creating a PDB or modified later, with privileged users required for certain resource and ranking changes.

Read More: [Pluggable Database Placement](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/pluggable-database-placement.html)

## Example of Creating a Pluggable Database with Cardinality and Rank

The examples demonstrate creating a database with the RANK management policy, adding a PDB with a specified cardinality, inspecting its configuration, and modifying its cardinality, CPU limits, and rank using SRVCTL. A CDB using RANK defaults newly created PDBs to the RESTART policy, and PDB rank and resource controls help Oracle Clusterware prioritize workloads.

Read More: [Example of Creating a Pluggable Database with Cardinality and Rank](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/example-of-creating-a-pluggable-database-with-cardinality-and-rank.html)

## Reducing Downtime During Database and Instance Outages

Oracle RAC maintains availability during individual instance or server failures through automatic restart, recovery, subsystem management, service relocation, and client redirection. Planned work can be performed through rolling instance maintenance, while Clusterware service management, FAN, and Application Continuity reduce disruption by relocating services, notifying clients rapidly, draining sessions, balancing connections, and replaying recoverable requests.

Read More: [Reducing Downtime During Database and Instance Outages](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/reducing-downtime-during-database-and-instance-outages.html)

## Oracle RAC High Availability Best Practices

Oracle AI Database 26ai introduces two-stage rolling updates, separating patch deployment from later activation through `ALTER SYSTEM ENABLE RAC TWO-STAGE ROLLING UPDATES ALL`, with status visible in `V$RAC_TWO_STAGE_ROLLING_UPDATES`. Smooth reconfiguration reduces brownout during node changes by performing on-demand Cache Fusion reconfiguration, and ordered sequence optimizations improve RAC performance automatically. Sequence configuration should balance ordering, gaps, and performance, with cached `NOORDER` generally providing the best throughput.

Read More: [Oracle RAC High Availability Best Practices](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/oracle-rac-high-availability-best-practices.html)

## Verifying That Instances are Running

Instance availability can be checked with SRVCTL, SQL\_Plus, or Oracle Enterprise Manager.\_ `srvctl status database` _reports running instances and nodes, while_ `srvctl status pdb` \_checks PDB status. In SQL\_Plus, administrators can connect to an instance-specific service and query `V$ACTIVE_INSTANCES` to view instance numbers, host names, and instance names.

Read More: [Verifying That Instances are Running](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/verifying-that-instances-are-running.html)

## Terminating Sessions On a Specific Cluster Instance

To terminate a RAC session, identify its SID, serial number, and instance ID in `GV$SESSION`, then issue `ALTER SYSTEM KILL SESSION` with the optional `@instance_id` clause. The operation rolls back active transactions and releases resources; it may wait for outstanding activity or mark the session for PMON termination, while `IMMEDIATE` forces prompt termination. Application Continuity can mask recoverable session cancellation from users.

Read More: [Terminating Sessions On a Specific Cluster Instance](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/terminating-sessions-on-a-specific-cluster-instance.html)

## Overview of Initialization Parameter Files in Oracle RAC

Oracle RAC instances should use one shared SPFILE, stored on ASM or a cluster file system, to maintain consistent and persistent configuration. Instance-specific values use `SID.parameter` entries, while wildcard values apply broadly; administrators should modify the binary SPFILE through Enterprise Manager or `ALTER SYSTEM`, not a text editor. The SPFILE location is managed through Clusterware, parameter files follow platform-specific search orders, and regular backups through RMAN or `CREATE PFILE` are recommended.

Read More: [Overview of Initialization Parameter Files in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/overview-of-initialization-parameter-files-in-oracle-rac.html)

## Initialization Parameter Use in Oracle RAC

Most initialization parameters use common defaults, but some may differ by instance and others must be identical across the cluster. RAC-specific settings include cluster mode, instance identity, redo threads, GCS processes, interconnects, shared server dispatchers, result cache behavior, services, and shared SPFILE usage. Critical parameters such as database identity, control files, block size, recovery destinations, instance type, undo management, and compatibility must match, while several operational parameters should also be aligned to simplify administration and avoid failover or recovery problems.

Read More: [Initialization Parameter Use in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/initialization-parameter-use-in-oracle-rac.html)

## Quiescing Oracle RAC Databases

`ALTER SYSTEM QUIESCE RESTRICTED` quiesces the entire RAC database, not merely the issuing instance, and requires Database Resource Manager to have been active since startup on every instance. The command waits for non-DBA sessions to become inactive, prevents database opening and resource-plan changes during quiescence, and is reversed with `ALTER SYSTEM UNQUIESCE`. A quiesced database is unsuitable for cold backups because background processes may still update internal structures, although online backups remain possible.

Read More: [Quiescing Oracle RAC Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/quiescing-oracle-rac-databases.html)

## Administering Multiple Cluster Interconnects on Linux and UNIX Platforms

On Linux and UNIX, `CLUSTER_INTERCONNECTS` can specify one or more alternative private-network addresses, distributing RAC traffic across listed interfaces when available. Oracle generally recommends Redundant Interconnect Usage instead, and the parameter should not contain HAIP addresses. When used, addresses must correspond to equivalent adapters across instances and be listed consistently; appropriate use cases include separating traffic for multiple databases or supporting unstable interface naming, while single-interconnect or adequately provisioned default configurations should leave it unset.

Read More: [Administering Multiple Cluster Interconnects on Linux and UNIX Platforms](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/administering-multiple-cluster-interconnects-on-linux-and-unix-platforms.html)

## Customizing How Oracle Clusterware Manages Oracle RAC Databases

SRVCTL database policies control how aggressively Oracle Clusterware restarts RAC databases. `AUTOMATIC` restores the prior running state and restarts after failures, `MANUAL` avoids host-restart recovery while continuing failure monitoring, and `NORESTART` prevents automatic restarts even after failures. Administrators can view policies with `srvctl config database -all`, change them with `srvctl modify database`, or specify them when adding a database.

Read More: [Customizing How Oracle Clusterware Manages Oracle RAC Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/customizing-how-oracle-clusterware-manages-oracle-rac-databases.html)

## Advanced Oracle Enterprise Manager Administration

Oracle Enterprise Manager Cloud Control supports centralized installation, configuration, monitoring, and advanced administration of Oracle RAC databases, including node and instance discovery, provisioning, cluster scaling, job scheduling, alert management, and maintenance suspensions.

Read More: [Advanced Oracle Enterprise Manager Administration](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/advanced-oracle-enterprise-manager-administration.html)

## Using Oracle Enterprise Manager Cloud Control to Discover Nodes and Instances

Oracle Enterprise Manager Cloud Control can discover Oracle RAC database and instance targets automatically during agent installation or manually afterward through the Targets and Database pages. Administrators can add database, listener, and ASM targets, select hosts, choose discovery scope, and manually configure cluster databases or instances that remain undiscovered after reconfiguration.

Read More: [Using Oracle Enterprise Manager Cloud Control to Discover Nodes and Instances](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/advanced-oracle-enterprise-manager-administration.html#GUID-3D1282DE-818F-4F9B-ADD0-D023A4069C6C)

## Other Oracle Enterprise Manager Capabilities

Oracle Enterprise Manager provides RAC and Grid Infrastructure provisioning with reusable deployment profiles, dynamically updated prerequisites and tools through My Oracle Support, support for one-click cluster extension, certified cluster scale-down and deletion, single-instance database provisioning, and Grid Infrastructure provisioning for standalone servers.

Read More: [Other Oracle Enterprise Manager Capabilities](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/advanced-oracle-enterprise-manager-administration.html#GUID-194C1104-11E4-482A-9F59-63034A9BD1E8)

## Administering Jobs and Alerts in Oracle RAC

The Cluster Database Home page aggregates RAC instance status, alerts, and AWR statistics while allowing drill-down to individual instances. Through the Administration tab, administrators can manage RAC jobs and alerts, configure instance- or database-level thresholds, and use maintenance suspensions to prevent unnecessary monitoring noise during planned operations.

Read More: [Administering Jobs and Alerts in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/advanced-oracle-enterprise-manager-administration.html#GUID-7BF7E846-D911-4CAC-B618-E56E9E7872F1)

## Administering Jobs in Oracle RAC

Oracle Enterprise Manager jobs can be created at the cluster database, cluster, or instance level and executed on an available or designated RAC host. Administrators can submit operating system and SQL scripts, schedule recurring tasks such as backups, and review job activity through Active, History, and Library categories.

Read More: [Administering Jobs in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/advanced-oracle-enterprise-manager-administration.html#GUID-39030925-33F1-482A-AC86-7C8A8111F456)

## Administering Alerts in Oracle RAC with Oracle Enterprise Manager

Oracle Enterprise Manager supports RAC-specific tests and distinguishes database-level alerts from instance-level alerts. Administrators can set thresholds for individual instance conditions, such as archive log issues, or configure database-wide conditions, such as tablespace usage, to avoid duplicate notifications across instances.

Read More: [Administering Alerts in Oracle RAC with Oracle Enterprise Manager](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/advanced-oracle-enterprise-manager-administration.html#GUID-0F0D32E1-C49D-408E-B88B-2C747863FE71)

## Using Defined Suspensions in Oracle Enterprise Manager

Defined suspensions temporarily disable monitoring for all RAC targets or selected cluster database instances during maintenance. This prevents planned operations from distorting monitoring data or generating unnecessary alerts.

Read More: [Using Defined Suspensions in Oracle Enterprise Manager](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-database-instances-and-cluster-databases/advanced-oracle-enterprise-manager-administration.html#GUID-36BC76C5-1EB3-4B84-9F0F-5C7C2D3202F5)


# Administering Oracle RAC One Node

Learn how to administer Oracle Real Application Clusters One Node (Oracle RAC One Node).

Oracle Real Application Clusters One Node (Oracle RAC One Node) is a single instance of an Oracle Real Application Clusters (Oracle RAC) database that runs on one node in a cluster. This option adds to the flexibility that Oracle offers for database consolidation. You can consolidate many databases into one cluster with minimal overhead while also providing the high availability benefits of failover protection, online rolling patch application, and rolling upgrades for the operating system and Oracle Clusterware.

## Creating an Oracle RAC One Node Database

Oracle RAC One Node databases can be created with Fleet Patching and Provisioning, DBCA, or manual scripts, and registered with Clusterware using SRVCTL if automatic registration does not occur. Use `srvctl add database -dbtype RACONENODE`, including `-server` and `-instance` for administrator-managed databases; policy-managed deployment is desupported in Oracle AI Database 26ai. Configure at least one dynamic database service, and optionally specify an instance prefix, which determines instance names during relocation and failover. Oracle recommends managing these databases with SRVCTL because operations such as online relocation require it.

Read More: [Creating an Oracle RAC One Node Database](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-oracle-rac-one-node/creating-an-oracle-rac-one-node-database.html)

## Converting Databases

SRVCTL can convert a single-instance Oracle RAC database to Oracle RAC One Node or convert an Oracle RAC One Node database back to Oracle RAC. Before converting to RAC One Node, ensure the RAC database has only one instance, configure services to prefer the retained instance, and change any `PRECONNECT TAF` policies to `BASIC` or `NONE`; the database must use Oracle Managed Files or have at least two redo threads. To convert back, use `srvctl convert database -db db_unique_name -dbtype RAC`, complete or cancel any active relocation, and then add further instances with `srvctl add instance`; policy-managed deployment is desupported in Oracle AI Database 26ai.

Read More: [Converting Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-oracle-rac-one-node/converting-databases.html)

## Online Database Relocation

Online database relocation moves an Oracle RAC One Node database to another node while maintaining service availability by starting a second instance, migrating services and connections, waiting for connection migration, and then stopping the former instance. Use `srvctl relocate database` and configure the relocation timeout for the connection-migration interval. Before relocation, ensure required password files are available on candidate nodes, maintain both instance-specific password files when shared storage is not used, and on Windows add the database service user to the Clusterware wallet. This feature is available only for Oracle RAC One Node databases, not standard Oracle RAC databases.

Read More: [Online Database Relocation](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/administering-oracle-rac-one-node/online-database-relocation.html)


# Workload Management with Dynamic Database Services

Workload management includes load balancing, enabling clients for Oracle Real Application Clusters (Oracle RAC), distributed transaction processing, and services.

## Connection Load-Balancing

Oracle Net Services supports client-side and server-side connection load balancing for Oracle RAC. Client-side balancing distributes requests across listeners, while server-side balancing uses SCAN listeners and service goals such as `-clbgoal` and `-rlbgoal` to select the best instance. Oracle recommends using both methods, with DBCA configuring them automatically. Connection failover and timeout settings such as `CONNECT_TIMEOUT`, `RETRY_COUNT`, `RETRY_DELAY`, and `TRANSPORT_CONNECT_TIMEOUT` improve availability for generic, JDBC, and OCI clients, while `LOAD_BALANCE=ON` distributes older-client connections across SCAN addresses.

Read More: [Connection Load-Balancing](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/connection-load-balancing.html)

## Smart Connection Rebalance

Smart Connection Rebalance analyzes workload access patterns and automatically routes service connections to instances where related workloads can share data efficiently, reducing inter-instance messaging, global-cache transfers, contention, and response times. Its recommendation engine evaluates services and smart connection groups, reports guidance through AWR and the `SMART_CONN_RECOMMENDATION` column of `(G)V$ACTIVE_SERVICES`, and can relocate service connections without manual session redistribution. Enable it with `srvctl modify service ... -rlbgoal SMART_CONN`; disable it by setting the goal to `NONE`, with child services restricted to `SMART_CONN` or `NONE`.

Read More: [Smart Connection Rebalance](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/smart-connection-rebalance.html)

## Load Balancing Advisory

The Load Balancing Advisory directs work toward RAC instances offering the best service quality and supports connection pools, application servers, schedulers, middleware, and integrated Oracle clients. Service goals include `SMART_CONN` for workload locality, `SERVICE_TIME` for response-time-sensitive work, and `THROUGHPUT` for batch-oriented workloads; `NONE` disables runtime balancing. FAN service-metrics events provide instance-level routing percentages and service-quality flags, and clients can consume them through JDBC, UCP, OCI session pools, ODP.NET, WebLogic Active GridLink, or the Oracle RAC FAN API. Events can be monitored through internal service-metrics queues, although they are not exposed through FAN callouts.

Read More: [Load Balancing Advisory](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/load-balancing-advisory.html)

## Enabling Clients for Oracle RAC

Oracle integrates FAN with JDBC, OCI, UCP, WebLogic Active GridLink, ODP.NET, and related connection pools to detect failures quickly, remove invalid connections, rebalance pools, and exploit newly available instances. JDBC FCF requires enabling `setFastConnectionFailoverEnabled(true)`, configuring Oracle Notification Service, and using service-name connection URLs; runtime load balancing additionally requires service-level advisory goals. OCI clients register callbacks for FAN events and can use TAF, service notification, and advisory settings, while ODP.NET enables HA and load balancing through connection-string attributes such as `HA Events=true` and `Load Balancing=true`. Application Continuity and Transaction Guard support replay and reliable transaction-outcome handling after outages.

Read More: [Enabling Clients for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/enabling-clients-for-oracle-rac.html)

## Distributed Transaction Processing in Oracle RAC

Oracle RAC supports global XA transactions across instances through GTX background processes, with XA affinity recommended to keep all branches of a transaction on one instance for performance and correct handling of suspend/resume or cross-branch savepoints. Application servers and connection pools such as WebLogic and UCP can provide XA affinity, while singleton services can provide preferred-instance placement and distribute workloads across multiple service groups. DTP services using `-dtp TRUE` should be reserved for applications that require them; Oracle generally recommends global transactions with XA affinity instead. Service relocation and failover remain available for singleton-service deployments.

Read More: [Distributed Transaction Processing in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/distributed-transaction-processing-in-oracle-rac.html)

## Automatic Workload Repository

The Automatic Workload Repository collects, processes, and preserves database and service-level performance statistics for reporting, alerting, workload management, and resource prioritization. Metrics can represent time, transactions, calls, and other measures, enabling administrators to adjust Resource Manager priorities, stop overloaded processes, modify service requirements, or execute recovery actions. AWR provides persistent, global performance data for Oracle Clusterware and Resource Manager and supports manual workload rebalancing through Enterprise Manager or SRVCTL. RAC services should be created and managed with SRVCTL or Enterprise Manager rather than `DBMS_SERVICE`.

Read More: [Automatic Workload Repository](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/automatic-workload-repository.html)

## Measuring Performance by Service Using the Automatic Workload Repository

AWR enables performance tuning by service, making response time, throughput, resource use, waits, and SQL activity attributable to applications rather than anonymous sessions. Administrators can extend monitoring to specific modules and actions with `DBMS_MONITOR`, verify enabled aggregations through `DBA_ENABLED_AGGREGATIONS`, and inspect service data in views such as `V$SERVICE_STATS`, `V$SERVICE_EVENT`, `V$SERVICE_WAIT_CLASS`, `V$SERVICEMETRIC`, `V$SERVICEMETRIC_HISTORY`, and `V$SERV_MOD_ACT_STATS`. These global, persistent statistics support service-quality monitoring, workload routing, and balancing across RAC instances.

Read More: [Measuring Performance by Service Using the Automatic Workload Repository](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/measuring-performance-by-service-using-the-automatic-workload-repository.html)

## Automatic Workload Repository Service Thresholds and Alerts

AWR service thresholds compare actual service quality with required response-time and CPU-time levels using moving averages of server-side call metrics. Administrators can define warning and critical limits with `DBMS_SERVER_ALERT`, apply them across RAC instances, review configurations in `DBA_THRESHOLDS`, and trigger Enterprise Manager or programmatic actions such as changing job priorities, stopping overloaded processes, or relocating services. `DBMS_MONITOR` can also enable service, module, and action monitoring, with results verified through `DBA_ENABLED_AGGREGATIONS` and detailed in `V$SERV_MOD_ACT_STATS`.

Read More: [Automatic Workload Repository Service Thresholds and Alerts](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/automatic-workload-repository-service-thresholds-and-alerts.html)

## Using Oracle Services

Oracle services provide logical workload groupings that can represent applications, user populations, or operation types such as online processing, batch jobs, and reporting. Assigning connections and work to distinct services makes resource consumption, performance, and service-level requirements visible and manageable. Services can be configured with characteristics that support workload isolation, monitoring, prioritization, availability, and application performance optimization.

Read More: [Using Oracle Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/using-oracle-services.html)

## Service Deployment Options

Oracle RAC services provide location transparency by allowing a service name to identify multiple instances while allowing an instance to support multiple services. Service definitions control Clusterware resources and failover, Resource Manager consumer-group mappings, AWR monitoring, parallel-query instance scope, GoldenGate queue ownership, editions, startup policy, Data Guard roles, preferred and available instances, failback, co-location, connection and runtime load balancing, and XA behavior. Services should use unique valid names and appropriate `-clbgoal` and `-rlbgoal` settings; default internal services are not client-managed. Restricted service registration protects listeners through valid-node checking and configurable invited nodes or subnets.

Read More: [Service Deployment Options](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/service-deployment-options.html)

## Administering Services

Oracle Enterprise Manager and SRVCTL provide the primary methods for creating and administering Oracle RAC services; SRVCTL settings override DBMS\_SERVICE settings. Service administration includes creating, deleting, starting, stopping, enabling, disabling, relocating, monitoring, and mapping services to Resource Manager consumer groups. Services should be configured with workload-management characteristics, and SERVICE\_NAMES should not be set manually. Enterprise Manager provides cluster-wide service management but requires SYSDBA credentials, while SRVCTL supports detailed command-line administration, including Application Continuity and Transaction Guard configuration through failover, load-balancing, notification, retention, and replay parameters.

Read More: [Administering Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/administering-services.html)

## Global Services

Global services provide centralized management and workload management across replicated Oracle RAC and nonclustered databases connected through technologies such as Oracle Data Guard or GoldenGate. They support preferred and available databases, replication-lag handling, geographical affinity, connection and runtime load balancing, inter-database failover, fast and connect-time failover, Application Continuity, Transaction Guard, and compatibility with existing clients. SRVCTL manages instance placement within an Oracle RAC database, while GDSCTL manages other global service attributes.

Read More: [Global Services](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/global-services.html)

## Service-Oriented Buffer Cache Access

Service-oriented buffer cache access improves performance by tracking object access through services and persisting that information in the database. Frequently accessed blocks are cached on instances running the associated service rather than on unrelated instances, and the cache can be pre-warmed when a service starts or relocates. This preserves more consistent performance for users after service placement changes.

Read More: [Service-Oriented Buffer Cache Access](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/service-oriented-buffer-cache-access.html)

## Connecting to a Service: An Example

This example demonstrates configuring and using an HR.example.com service on the CRM database, with preferred instances CRM1 and CRM2, available instances CRM3 and CRM4, cardinality of two, LONG connection load balancing, SERVICE\_TIME runtime load balancing, and Application Continuity settings. SRVCTL creates and starts the service with transaction failover, commit outcome tracking, a 10-second retry delay, and up to 40 retries. A JDBC Universal Connection Pool application then connects through the SCAN listener using the service name, Fast Connection Failover, remote ONS, and configured pool credentials and sizing.

Read More: [Connecting to a Service: An Example](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/workload-management-with-dynamic-database-services/connecting-to-a-service-an-example.html)


# Ensuring Application Continuity

**Application Continuity** is a feature that enables the replay, in a non-disruptive and rapid manner, of a request against the database after a recoverable error that makes the database session unavailable so an outage appears to the user as no more than a delayed processing of the request.

AC needs request boundaries, which means AC depends on Oracle or third-party pools that embed request boundaries when connections are borrowed and returned to the pool. Whereas, TAC uses provided request boundaries and creates its own. With TAC request boundaries advance automatically when there is no transaction, the session state is restorable, and cursors are closed.

To use this chapter, you should be familiar with the major relevant concepts and techniques of the technology or product environment in which you are using Application Continuity, such as Oracle RAC or Oracle Active Data Guard (Oracle ADG).

> **See Also:**
>
> [Oracle AI Database High Availability Overview and Best Practices](https://docs.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/26/racad&id=HAOVW-GUID-6BF1367C-E409-4ECE-AD2B-E9016CB1A763) describes how you can choose and implement the level of Application Continuity protection that is the best for your applications.

## Understanding Application Continuity

Application Continuity masks many recoverable planned and unplanned Oracle AI Database outages by rebuilding database sessions, restoring session and transactional state, and replaying in-flight work without duplicating committed transactions. It relies on Transaction Guard and logical transaction identifiers to determine commit outcomes, supports Oracle RAC, Active Data Guard, DBMS\_ROLLING, and multitenant PDB failover, and uses concepts such as database requests, request boundaries, recoverable errors, preserved function results, session-state consistency, and stateless applications. Replay replaces the failed session, restores state, validates results, and resubmits the final call; successful replay is transparent, while unsafe or inconsistent replay returns the original error. Support is available across numerous JDBC, UCP, OCI, ODP.NET, SQL\*Plus, WebLogic, Tuxedo, Python, and Node.js configurations, while restrictions apply to unsupported drivers, certain APIs, serializable isolation, data-loss targets, replication technologies, and statements or operations that cannot be safely replayed. Request boundaries provide the strongest control over replay, whereas Transparent Application Continuity can discover boundaries for simpler applications.

Read More: [Understanding Application Continuity](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/understanding-application-continuity.html)

## Transparent Application Continuity

Transparent Application Continuity extends Application Continuity for simpler applications by automatically tracking session and transactional state, discovering implicit request boundaries, restoring preset state, preserving supported function values, and disabling replay when unsafe side effects are detected. Enabled with `FAILOVER_TYPE=AUTO`, TAC supports planned and unplanned failover, resumable cursors in Oracle AI Database 26ai, automatic session-state verification, and safe recovery without application code changes. It offers correctness guarantees including timely failover, validation of database identity and chronology, prevention of duplicate transactions, restoration of session state, and preservation of already observed results. TAC differs from traditional Application Continuity by creating request boundaries when sessions are transaction-free, restorable, and have suitable cursors, while `RESET_STATE` prevents state leakage between pooled uses. It is enabled by default on selected Oracle Cloud services and can be configured through `DBMS_APP_CONT_ADMIN` to enable TAC or AC, disable failover, activate coverage checks, reset state, and configure draining.

Read More: [Transparent Application Continuity](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/transparent-application-continuity.html)

## Configuring Application Continuity

Configuring Application Continuity requires suitable client and server resources, connection pools or explicit request boundaries, correct session-state restoration, appropriate service attributes, FAN, database services, retry settings, and monitoring of protection coverage. Administrators should select TAC with `FAILOVER_TYPE=AUTO` for applications with uncertain or evolving state usage, or AC with `FAILOVER_TYPE=TRANSACTION` when explicit boundaries and replay behavior are controlled; configure `COMMIT_OUTCOME`, `FAILOVER_RESTORE`, session-state consistency, replay timeouts, and connection retry parameters. High-availability connections should use Oracle data sources, SCAN-based addressing, aligned `REMOTE_LISTENER` settings, and suitable timeout and retry values. Database configuration must include FAN/ONS where applicable and must avoid default database services. `FAILOVER_RESTORE` can restore common and extended session states, with database templates and encrypted dictionary credentials providing broader coverage; keystores may be configured through `WALLET_ROOT` or, less preferably, `SQLNET.ORA`. Connection labels and initialization callbacks are reserved for states not restored automatically, while side-effect rules determine whether PL/SQL side effects, autonomous transactions, and database links are replayed or suppressed.

Read More: [Configuring Application Continuity](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/configuring-application-continuity.html)

## Administering Application Continuity Operation and Usage

This page explains how to administer Application Continuity for planned maintenance, replay consistency, monitoring, session-state management, protection analysis, reconnection, and replay suppression. It recommends combining FAN-aware connection pools with service draining, using Application Continuity to recover incomplete requests, and configuring appropriate service parameters for RAC or single-instance databases. It describes automatic and explicit preservation of mutable function results, methods for checking and granting KEEP privileges, protection-level statistics, AUTO and DYNAMIC session-state consistency, and Application Continuity statistics. The page also introduces ACCHK for tracing, filtering, reporting, and purging protection data, and documents conditions requiring replay to be disabled, including external side effects, interdependent sessions, middle-tier time logic, changing physical identifiers, and DBA-initiated termination with NOREPLAY.

Read More: [Administering Application Continuity Operation and Usage](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/administering-application-continuity-operation-and-usage.html)

## Fast Application Notification (FAN)

This page describes FAN as Oracle RAC’s event-notification framework for rapidly informing clients about database, instance, node, network, and service availability changes. FAN prevents TCP timeout delays, supports immediate client interruption and reconnection, drains sessions during planned maintenance, enables connection-pool load balancing, and works with Oracle drivers, UCP, WebLogic, OCI, JDBC, and ODP.NET. It explains client and service configuration requirements, FAN-aware driver behavior, server-side callouts, high-availability event types and parameters, service subscriptions, and event-to-session mappings. FAN callouts can automate logging, alerting, service management, failback, and repair actions; they are installed on cluster nodes and generally execute on the originating node, except for node-down and VIP-down events, which are posted across the cluster.

Read More: [Fast Application Notification (FAN)](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/fast-application-notification-fan.html)

## Configure for Unplanned Outages

This page explains how Oracle RAC, FAN, and Application Continuity cooperate to conceal unplanned outages from applications by recovering in-flight work and relocating services across available instances. Clusterware isolates failed components, restores dependent resources, and maintains service cardinality where possible, while FAN publishes availability events through Oracle Notification Service and Advanced Queuing and can trigger server-side callouts. Applications remain independent of service placement because restart and recovery of databases, listeners, ASM, and related subsystems are automated. FAN callouts may integrate with fault-management and repair systems, although their asynchronous execution does not guarantee ordering.

Read More: [Configure for Unplanned Outages](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/configure-for-unplanned-outages.html)

## Managing Planned Maintenance

Oracle RAC supports planned maintenance by relocating, stopping, and restarting services while draining active sessions at safe request boundaries to minimize disruption. FAN planned notifications, connection pools, server-side draining, configurable drain timeouts, and stop options coordinate session release and failover. The MAA Client Dashboard and views such as GV$CLIENT\_HA\_READINESS, GV$CLIENT\_REQUEST\_HISTOGRAM, and GV$SERVICE\_DRAIN\_TIMEOUT\_ADVICE help assess client readiness, request durations, and suitable drain windows. Intelligent Drain Timing can automatically choose between continued draining and planned failover for protected sessions. SRVCTL supports maintenance operations for individual services, service groups, nodes, databases, instances, and PDBs, while Application Continuity, Transparent Application Continuity, TAF, connection tests, and specialized XA/sessionless transaction rules help preserve application work during service relocation or shutdown.

Read More: [Managing Planned Maintenance](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/managing-planned-maintenance.html)

## Transaction Guard for Improving Client Failover

Transaction Guard helps applications determine the outcome of a commit after a recoverable error, preventing duplicate transaction submissions and supporting transaction idempotence through Logical Transaction IDs. Database Native Transaction Guard uses database transaction identifiers to provide the same protection with lower overhead and is enabled by default with Application Continuity. Transaction Guard also supports XA transactions and DBMS\_ROLLING upgrades by replicating transaction history to a transient logical standby, preserving commit outcomes during switchover. Configuration requires appropriate privileges, transaction-history planning, COMMIT\_OUTCOME and RETENTION\_TIMEOUT service settings, and preferably FAN; services should be explicitly configured with these parameters rather than using the default administrative database service.

Read More: [Transaction Guard for Improving Client Failover](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/transaction-guard-for-improving-client-failover.html)

## Application Continuity During Major Database Version Upgrades with DBMS\_ROLLING

Starting with Oracle AI Database 26ai, Application Continuity and session draining support planned major-version upgrades, restructuring, and non-rolling patching through DBMS\_ROLLING. Sessions can fail over transparently between logical database versions during the controlled switchover, allowing applications to remain operational while the infrastructure monitors replication lag and initiates the transition when it can complete in seconds to minutes. The capability integrates Application Continuity with a logical standby to minimize interruption and maintain business continuity, with the 19c-to-26ai upgrade supported for Oracle Autonomous Database Dedicated only.

Read More: [Application Continuity During Major Database Version Upgrades with DBMS\_ROLLING](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/application-continuity-during-major-database-version-upgrades-with-dbms_rolling.html)

## Reset Database Session State

RESET\_STATE prevents session state from leaking between pooled application requests and, starting with Oracle AI Database 26ai, operates independently of Application Continuity. At request boundaries it can clear residual state, protecting shared connections from exposing sensitive application context and improving safety with Transparent Application Continuity. NONE performs no cleanup, LEVEL1 clears non-restorable state such as package variables, temporary objects, cursors, MLE variables, sequences, and DBMS\_OUTPUT, and LOGIN additionally restores login-time settings including initialization parameters, application contexts, roles, tracing attributes, client identifiers, and database links. LOGIN requires explicit request boundaries, and RESET\_STATE supersedes RESET\_PACKAGE.

Read More: [Reset Database Session State](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/ensuring-application-continuity/reset-database-session-state.html)


# Configuring Recovery Manager and Archiving

You can configure Oracle Recovery Manager (Oracle RMAN) to support your Oracle RAC environment.

This chapter provides procedures for using for archiving in Oracle RAC environments and discusses online redo log and archived redo log considerations.

## Overview of Configuring RMAN for Oracle RAC

Oracle Recovery Manager (RMAN) is included with Oracle AI Database and supports backup, restoration, and recovery of data files, control files, SPFILEs, and archived redo logs in Oracle RAC. It can be used from the command line or through Oracle Enterprise Manager.

Read More: [Overview of Configuring RMAN for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/overview-of-configuring-rman-for-oracle-rac.html)

## Archiving Mode in Oracle RAC

An Oracle RAC database must use ARCHIVELOG mode to archive redo logs. Archiving mode is configured at the database level, so all instances either archive logs or none do; it can be changed with ALTER DATABASE while the database is mounted and not open.

Read More: [Archiving Mode in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/archiving-mode-in-oracle-rac.html)

## Configuring the RMAN Snapshot Control File Location

RMAN uses a snapshot control file to obtain a consistent control-file copy for recovery catalog synchronization and control-file backups. In Oracle RAC, its location must be on shared storage accessible to every backup node; SHOW SNAPSHOT CONTROLFILE NAME displays the location, while CONFIGURE SNAPSHOT CONTROLFILE NAME changes it persistently.

Read More: [Configuring the RMAN Snapshot Control File Location](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/configuring-the-rman-snapshot-control-file-location.html)

## Configuring RMAN to Automatically Backup the Control File and SPFILE

Enabling CONFIGURE CONTROLFILE AUTOBACKUP causes RMAN to back up the control file and SPFILE after BACKUP or COPY operations. Autobackups support disaster recovery without a recovery catalog, but their storage path must be identically accessible on all participating nodes, and the first allocated RMAN channel performs the autobackup.

Read More: [Configuring RMAN to Automatically Backup the Control File and SPFILE](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/configuring-rman-to-automatically-backup-the-control-file-and-spfile.html)

## Crosschecking on Multiple Oracle RAC Nodes

For reliable RMAN crosschecks and restores, every Oracle RAC node should be able to access all backups. If this is not possible, configure channels with CONNECT for the nodes that can access particular backups; otherwise inaccessible backups may be incorrectly marked EXPIRED during crosschecking.

Read More: [Crosschecking on Multiple Oracle RAC Nodes](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/crosschecking-on-multiple-oracle-rac-nodes.html)

## Configuring Channels for RMAN in Oracle RAC

RMAN channels in Oracle RAC can be configured for automatic load balancing or assigned to specific instances. Automatic balancing is enabled by configuring device-type parallelism with CONFIGURE DEVICE TYPE, specifying the number of channels RMAN should use for backup or restore operations.

Read More: [Configuring Channels for RMAN in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/configuring-channels-for-rman-in-oracle-rac.html)

## Managing Archived Redo Logs Using RMAN in Oracle RAC

Oracle records archived redo log filenames in the target control file and, when applicable, the recovery catalog. Archived logs must use naming and storage arrangements that allow required nodes to read them; although multiple nodes can restore logs in parallel, the node applying recovery must access every required log, with RECOVER PARALLEL available to adjust recovery threads.

Read More: [Managing Archived Redo Logs Using RMAN in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/managing-archived-redo-logs-using-rman-in-oracle-rac.html)

## Archived Redo Log File Conventions in Oracle RAC

LOG\_ARCHIVE\_FORMAT must uniquely identify archived redo logs in Oracle RAC using thread, sequence, and resetlogs variables such as %t, %s, and %r, with uppercase variants providing zero padding. Including the resetlogs identifier prevents files from different database incarnations from being overwritten, and these format variables are mandatory when COMPATIBLE is 10.0 or higher.

Read More: [Archived Redo Log File Conventions in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/archived-redo-log-file-conventions-in-oracle-rac.html)

## RMAN Archiving Configuration Scenarios

Oracle RAC archiving can use shared cluster file systems or node-local file systems with remote access. Shared storage, preferably Oracle ASM with a separate recovery-area disk group, lets every node read all logs directly and simplifies backups; local archiving requires unique per-node destinations plus NFS or mapped-drive access during recovery. In either design, archived logs must be complete and readable by the recovery node, and the recovery instance must use the same LOG\_ARCHIVE\_FORMAT as the archiving instances.

Read More: [RMAN Archiving Configuration Scenarios](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/rman-archiving-configuration-scenarios.html)

## Monitoring the Archiver Processes

After configuring RMAN and archiving, use GV$ARCHIVE\_PROCESSES to view archiver status across all Oracle RAC instances or V$ARCHIVE\_PROCESSES to view the connected instance. Do not terminate an archiver process with the kill command because doing so causes the database instance to fail.

Read More: [Monitoring the Archiver Processes](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/configuring-recovery-manager-and-archiving/monitoring-the-archiver-processes.html)


# Managing Backup and Recovery

Learn how to use Recovery Manager (RMAN) to back up and restore Oracle Real Application Clusters (Oracle RAC) databases, and about Oracle RAC instance recovery, parallel backup, recovery with SQL\*Plus, and using the Fast Recovery Area in Oracle RAC.

## Managing Backup and Recovery in Clusters

In an Oracle RAC cluster, any node can restore archived redo logs because data files are accessible from every cluster node; the instance performing recovery does not need to restore all data files itself.

Read More: [Managing Backup and Recovery in Clusters](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/managing-backup-and-recovery/managing-backup-and-recovery-in-clusters.html)

## RMAN Backup Scenario for Noncluster File System Backups

In a noncluster file system configuration, each node backs up only to locally mounted storage and cannot access archived redo logs on other nodes unless network file system access is configured. With shared network access, each node still backs up its own archived redo logs to its local directory.

Read More: [RMAN Backup Scenario for Noncluster File System Backups](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/managing-backup-and-recovery/rman-backup-scenario-for-noncluster-file-system-backups.html)

## RMAN Restore Scenarios for Oracle RAC

Oracle RAC restore procedures depend on the storage architecture: cluster file system backups can be restored from any available node with access to the shared files or media, while noncluster file system recovery requires network access to every node’s archived-log directory. RMAN can restore the SPFILE to its default or a specified location, and Oracle Enterprise Manager can restore it when the database is closed; channel allocation may need to be adjusted for load balancing during full restores.

Read More: [RMAN Restore Scenarios for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/managing-backup-and-recovery/rman-restore-scenarios-for-oracle-rac.html)

## Instance Recovery in Oracle RAC

Oracle RAC automatically performs instance recovery after software or hardware failures by applying online redo logs, preserving committed transactions, rolling back incomplete work, and releasing resources. Oracle Clusterware restarts failed instances, surviving instances recover failed peers, and if all instances fail, the next instance to open the database performs recovery; all online redo logs must be accessible, so mirroring is recommended. RMAN is the standard tool for backing up and restoring RAC data files, control files, SPFILEs, and archived redo logs.

Read More: [Instance Recovery in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/managing-backup-and-recovery/instance-recovery-in-oracle-rac.html)

## Media Recovery in Oracle RAC

Media recovery in Oracle RAC is initiated by a user through a client application, typically using RMAN to restore data file backups and recover the database. The recovery node must access all required data files and archived redo logs, either on disk or through backups; for encrypted tablespaces, the Oracle Wallet must be opened after mounting the database and before opening it.

Read More: [Media Recovery in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/managing-backup-and-recovery/media-recovery-in-oracle-rac.html)

## Parallel Recovery in Oracle RAC

Oracle AI Database automatically selects an appropriate recovery parallelism based on available CPU resources. With RMAN, the number of allocated channels controls parallelism for restoring data files and applying incremental backups, while archived redo log application is automatically parallelized; parallel recovery can be disabled through initialization parameters or the RMAN and SQL recovery commands.

Read More: [Parallel Recovery in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/managing-backup-and-recovery/parallel-recovery-in-oracle-rac.html)

## Using a Fast Recovery Area in Oracle RAC

An Oracle RAC fast recovery area must reside on shared storage, such as an Oracle ASM disk group, cluster file system, or network file system directory accessible by every instance. The `DB_RECOVERY_FILE_DEST` parameter must have the same value across all instances, and Oracle Enterprise Manager provides configuration options through the cluster database Maintenance and Backup/Recovery settings.

Read More: [Using a Fast Recovery Area in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/managing-backup-and-recovery/using-a-fast-recovery-area-in-oracle-rac.html)


# Cloning Oracle RAC to Nodes in a New Cluster

Learn how to clone Oracle Real Application Clusters (Oracle RAC) database homes on Linux and Unix systems to nodes in a new cluster.

## Introduction to Cloning Oracle RAC

Cloning Oracle RAC copies an existing, patched Oracle home to another location and adapts it to the target environment, enabling fast, silent, repeatable deployment across multiple cluster nodes. It is especially useful for simultaneously installing many clusters or reproducing fully patched production, test, or development environments, although traditional interactive installers are preferable for a single cluster. Cloned homes retain source-applied one-off patches, can themselves serve as future clone sources, and may be customized for settings such as port assignments. The process copies only files within the source Oracle home, relinks binaries for the destination system, and may change file counts and binary sizes; it does not replace Oracle Enterprise Manager Provisioning Pack, which provides interactive and automated provisioning workflows for larger data centers.

Read More: [Introduction to Cloning Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/cloning-oracle-rac-to-nodes-in-a-new-cluster/introduction-to-cloning-oracle-rac.html)

## Preparing to Clone Oracle RAC

Preparing an Oracle RAC clone involves installing the software-only Oracle RAC home, applying the required Release Update and any one-off patches, and creating a backup archive of the prepared home, preferably with the release number in its filename. Before deploying the clone, Oracle Clusterware must be installed and running on every target node, with the target environment configured in the same sequence as the source cluster. The archived Oracle home is then available for copying to one or more destination nodes.

Read More: [Preparing to Clone Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/cloning-oracle-rac-to-nodes-in-a-new-cluster/preparing-to-clone-oracle-rac.html)

## Deploying Oracle RAC Clones to Nodes in a Cluster

Deploying a clone requires preparing each target node with the platform-specific prerequisites, active Oracle Clusterware, active Oracle ASM, and a mounted ASM disk group, then extracting the Oracle home and correcting ownership when necessary. Remove source-specific network configuration and obsolete database files before registering the home, either through a software-only installer run or the parameter-sensitive `clone.pl` script, which accepts Oracle home, base, home-name, operating-system group, cluster-node, and local-node settings. On Linux and UNIX, run `root.sh` as root after cloning on every node, ensuring completion before continuing; finally, run DBCA from one node to create and register RAC instances across the cluster, configure storage and database options, and create the database.

Read More: [Deploying Oracle RAC Clones to Nodes in a Cluster](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/cloning-oracle-rac-to-nodes-in-a-new-cluster/deploying-oracle-rac-clones-to-nodes-in-a-cluster.html)

## Locating and Viewing Log Files Generated During Cloning

Oracle RAC cloning invokes several tools that generate diagnostic logs. Oracle Universal Installer activity and errors are recorded under the central inventory in `cloneActions` and `oraInstall` log files, while pre-cloning and cloning activity and errors are recorded in `$ORACLE_HOME/clone/logs` as `clone` and `error` logs. The central inventory location is identified through `/var/opt/oracle/oraInst.loc` on most UNIX systems, `/etc/oraInst.loc` on Linux and IBM AIX, and the standard Oracle Inventory directory under `C:\Program Files\Oracle\Inventory` on Windows.

Read More: [Locating and Viewing Log Files Generated During Cloning](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/cloning-oracle-rac-to-nodes-in-a-new-cluster/locating-and-viewing-log-files-generated-during-cloning.html)


# Using Cloning to Extend Oracle RAC to Nodes in the Same Cluster

Learn how to use cloning to extend Oracle RAC nodes within a cluster.

This chapter provides information about using cloning to extend Oracle Real Application Clusters (Oracle RAC) to nodes in an existing cluster.

## About Adding Nodes Using Cloning in Oracle RAC Environments

Cloning can add nodes to an existing Oracle RAC environment after the cluster has been successfully installed and configured. The process extends the Oracle Clusterware configuration, extends the Oracle AI Database home with Oracle RAC, and uses Oracle assistants to add listeners and instances. Because the cloning script invokes multiple tools, each potentially producing separate logs, review the generated log files after `clone.pl` completes.

Read More: [About Adding Nodes Using Cloning in Oracle RAC Environments](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/using-cloning-to-extend-oracle-rac-to-nodes-in-the-same-cluster/about-adding-nodes-using-cloning-in-oracle-rac-environments.html)

## Cloning Local Oracle Homes on Linux and UNIX Systems

To clone a local, nonshared Oracle home, prepare a copy of the source home, archive it with `tar`, and transfer it to the same path on each new node. Configure `ORACLE_HOME` and `ORACLE_BASE`, run `clone.pl` from `Grid_home/clone/bin` with the cluster and local-node parameters, execute any required commands in `configToolFailedCommands`, update the Oracle inventory from the existing node with `runInstaller -updateNodeList`, and run `root.sh` on each new node. Finally, use Oracle DBCA from the cloned node to add RAC instances on the new nodes.

Read More: [Cloning Local Oracle Homes on Linux and UNIX Systems](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/using-cloning-to-extend-oracle-rac-to-nodes-in-the-same-cluster/cloning-local-oracle-homes-on-linux-and-unix-systems.html)

## Cloning Shared Oracle Homes on Linux and UNIX Systems

To clone a shared Oracle home, prepare the source copy, configure `ORACLE_HOME` and `ORACLE_BASE` on the new node, and run `clone.pl` from `$ORACLE_HOME/clone/bin` with the cluster and local-node parameters. Specify `-cfs` to identify a shared Oracle RAC home, and use the source node’s `ORACLE_HOME_NAME`. Update the Oracle inventory from the existing node, run `root.sh` on each new node, and use Oracle DBCA from the cloned node to add database instances.

Read More: [Cloning Shared Oracle Homes on Linux and UNIX Systems](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/using-cloning-to-extend-oracle-rac-to-nodes-in-the-same-cluster/cloning-shared-oracle-homes-on-linux-and-unix-systems.html)

## Cloning Oracle Homes on Windows Systems

On Windows, archive a local Oracle RAC home with ZIP and extract it on the new node in the same directory, or use the existing shared home. Run `clone.pl` from `%ORACLE_HOME%\clone\bin` with the home, base, home name, cluster, and local-node parameters; specify `ORACLE_HOME_USER` for secured homes and use `-cfs -noConfig` for shared homes. Update the inventory from the existing node with `setup.exe -updateNodeList`, then run Oracle DBCA from the cloned node to add RAC instances on the new node.

Read More: [Cloning Oracle Homes on Windows Systems](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/using-cloning-to-extend-oracle-rac-to-nodes-in-the-same-cluster/cloning-oracle-homes-on-windows-systems.html)


# Adding and Deleting Oracle RAC from Nodes on Linux and Unix Systems

Extend an existing Oracle Real Application Clusters (Oracle RAC) home to other nodes and instances in the cluster, and delete Oracle RAC from nodes and instances in the cluster.

## About Adding and Deleting Nodes

Adding and deleting nodes modifies an Oracle RAC cluster; use cloning procedures instead when creating multiple installations from an existing Oracle RAC home. Before making changes, back up the Oracle Cluster Registry with `ocrconfig -showbackup`, and use “target node” to mean the node receiving the RAC extension.

Read More: [About Adding and Deleting Nodes](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/about-adding-and-deleting-nodes.html)

## Adding Oracle RAC to Nodes with Oracle Grid Infrastructure Installed

Adding Oracle RAC to a node requires procedures based on whether the Oracle home is local, shared through Oracle ACFS, or shared through another file system. Local homes use `addnode.sh`, `root.sh`, manual network configuration, and PDB activation; ACFS homes require starting the file-system resources, attaching the home, running `addnode.sh -noCopy`, and executing `root.sh`; other shared homes require creating and mounting the home path, attaching it, updating the Oracle Inventory, and running `root.sh`. Afterward, add the database instance to the target node and back up the OCR.

Read More: [Adding Oracle RAC to Nodes with Oracle Grid Infrastructure Installed](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/adding-oracle-rac-to-nodes-with-oracle-grid-infrastructure-installed.html)

## Adding Administrator-Managed Oracle RAC Database Instances to Target Nodes

Administrator-managed RAC instances can be added with Oracle Enterprise Manager or Oracle DBCA, which creates and configures instances, high-availability components, Oracle Net settings, startup behavior, and services. Interactive DBCA guides users through selecting the database and adding an instance, followed by administrative privilege verification with CVU and service configuration; silent DBCA uses `-addInstance` with the target node, global database name, optional instance name, and SYSDBA credentials.

Read More: [Adding Administrator-Managed Oracle RAC Database Instances to Target Nodes](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/adding-administrator-managed-oracle-rac-database-instances-to-target-nodes.html)

## Deleting Oracle RAC from a Cluster Node

Removing RAC from a node requires deleting its database instance and Oracle RAC software before removing the node from the cluster; if no instance exists, proceed directly to RAC removal. Before deleting administrator-managed instances, relocate services, ensure they can run on remaining instances, and remove the target instance from all service preferred and available lists.

Read More: [Deleting Oracle RAC from a Cluster Node](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/deleting-oracle-rac-from-a-cluster-node.html)

## Deleting Instances from Oracle RAC Databases

Instances can be removed with SRVCTL or Oracle DBCA, but services must first be relocated or reconfigured so the target instance is not required. Interactive DBCA deletion should run from another node while the target instance is active, and must be followed by verification that the redo thread is disabled and the instance is absent from OCR. Silent DBCA uses `-deleteInstance` and removes listener registration, the database instance, Oracle Net configuration, and the instance’s Oracle Flexible Architecture directories.

Read More: [Deleting Instances from Oracle RAC Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/deleting-oracle-rac-from-a-cluster-node.html#GUID-6BA60523-0558-4803-886A-743965E0D452)

## Using Oracle DBCA in Interactive Mode to Delete Instances from Nodes

Interactive DBCA instance deletion starts on a node other than the one hosting the target instance, using Instance Management to select and remove the instance from the RAC database. DBCA removes the instance and its Oracle Net configuration; afterward, verify and disable the corresponding redo thread if necessary, confirm removal from OCR with SRVCTL, and repeat the process for additional nodes.

Read More: [Using Oracle DBCA in Interactive Mode to Delete Instances from Nodes](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/deleting-oracle-rac-from-a-cluster-node.html#GUID-2BBBD86B-2ADA-4E7B-A1CA-789767223556)

## Using Oracle DBCA in Silent Mode to Delete Instances from Nodes

Silent DBCA removes an Oracle RAC instance with `-deleteInstance`, requiring the global database name and instance name, with optional node and SYSDBA credentials. The operation deregisters the instance from listeners, deletes it from the configured node, removes Oracle Net configuration, and deletes its Oracle Flexible Architecture directory structure.

Read More: [Using Oracle DBCA in Silent Mode to Delete Instances from Nodes](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/deleting-oracle-rac-from-a-cluster-node.html#GUID-17439B6B-6D3C-46AA-A585-94B636C708AC)

## Removing Oracle RAC

Before removing RAC software from a node, disable and stop any listeners in the RAC home. Deinstall a local, nonshared Oracle home with `deinstall -local`; do not use this command for a shared home because it would remove software needed by other nodes, and instead continue with the shared-home removal procedure.

Read More: [Removing Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/deleting-oracle-rac-from-a-cluster-node.html#GUID-CE995C7B-B420-4A4E-B4EA-E7A972277588)

## Deleting Nodes from A Cluster

After removing the database instance and Oracle RAC software, remove the node from the cluster by running the appropriate scripts on the target node to remove Oracle Clusterware, then execute the required scripts on remaining nodes to update the cluster’s node list.

Read More: [Deleting Nodes from A Cluster](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-linux-and-unix-systems/deleting-oracle-rac-from-a-cluster-node.html#GUID-8EEFAE40-5F40-44E4-B0B0-50CA80E4F289)


# Adding and Deleting Oracle RAC from Nodes on Windows Systems

Use these procedures to extend an existing Oracle Real Application Clusters (Oracle RAC) home on Microsoft Windows to other nodes and instances in the cluster, or delete Oracle RAC from nodes and instances in the cluster.

In these topics, the entries for `Grid_home` refer to the full path name for the Oracle Grid Infrastructure home, and the entries for `Oracle_home` refer to substitutes for environment variables for the Oracle home with Oracle RAC.

If your goal is to clone an existing Oracle RAC home to create multiple new Oracle RAC installations across the cluster, then use the cloning procedures that are described in "Cloning Oracle RAC to Nodes in a New Cluster".

> **Note:**
>
> Ensure that you have a current backup of Oracle Cluster Registry (OCR) before adding or deleting Oracle RAC by running the `ocrconfig -showbackup` command.
>
> For all of the add node and delete node procedures, temporary directories such as `%TEMP%` or `C:\Temp` _should not be_ shared directories. If your temporary directories are shared, then set your temporary environment variable, such as `%TEMP%`, to a location on a local node. In addition, use a directory path that exists on all of the nodes.

## Adding Oracle RAC to Nodes with Oracle Grid Infrastructure Installed

To add Oracle RAC to existing Windows cluster nodes, verify the Grid Infrastructure and Oracle home environment settings, then extend the Oracle RAC home with `addnode.bat`, supplying the Oracle home user password or `-promptPasswd` when required. For shared non-ACFS file systems, obtain mount details with `srvctl`, mount the database home, attach it with `setup.exe -attachHome`, and update the inventory with `-updateNodeList`; back up the voting disk and OCR after completing the process.

Read More: [Adding Oracle RAC to Nodes with Oracle Grid Infrastructure Installed](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-windows-systems/adding-oracle-rac-to-nodes-with-oracle-grid-infrastructure-installed.html)

## Adding Administrator-Managed Oracle RAC Database Instances to Target Nodes

Oracle DBCA can add administrator-managed RAC instances to target nodes interactively or silently after the Oracle Clusterware and database homes are extended. DBCA creates and configures the instance, high-availability components, Oracle Net configuration, and optionally services; interactive mode uses Instance Management and Add Instance workflows, while silent mode uses `dbca -silent -addInstance` with the node and global database names. On Windows, create the OraMTS service with `oramtsctl.exe -new -host` after adding nodes or completing a software-only installation, then perform any required service configuration.

Read More: [Adding Administrator-Managed Oracle RAC Database Instances to Target Nodes](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-windows-systems/adding-administrator-managed-oracle-rac-database-instances-to-target-nodes.html)

## Deleting Oracle RAC from a Cluster Node

Removing RAC from a Windows cluster node requires deleting its database instances before removing the RAC software and node. Relocate and reconfigure services so the instance is not preferred or available, then use DBCA in silent or interactive mode to delete the instance, remove its Oracle Net configuration and OFA directories, verify and disable any remaining redo thread, and confirm OCR registration with `srvctl`. Disable and stop listeners on the target node, deinstall the Oracle home with `deinstall -local` or `-cfs` for shared homes, and finally run the Grid Infrastructure removal and node-list update procedures to delete the node from the cluster.

Read More: [Deleting Oracle RAC from a Cluster Node](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/adding-and-deleting-oracle-rac-from-nodes-on-windows-systems/deleting-oracle-rac-from-a-cluster-node.html)


# Design and Deployment Techniques

Learn about methods to design and deploy Oracle RAC.

This chapter briefly describes database design and deployment techniques for Oracle Real Application Clusters (Oracle RAC) environments. It also describes considerations for high availability and provides general guidelines for various Oracle RAC deployments.

## Deploying Oracle RAC for High Availability

Oracle RAC supports high availability by allowing applications to continue operating across multiple database instances, but the entire application infrastructure—including authentication, networking, storage, and operational processes—must be designed without single points of failure. Effective deployments define service-level objectives, recovery times, and failover expectations; validate them through functional, performance, and destructive testing; and apply Oracle Maximum Availability Architecture practices. Recommended measures include VIP-based connectivity, workload management services, resilient voting disks and OCR, tuned recovery, Oracle ASM, strong change control, infrastructure redundancy, Enterprise Manager administration, RMAN protection, and appropriate sequence and index strategies. RAC also supports consolidation through shared ASM storage, cluster-managed services, capacity policies, and Global Data Services, while enabling online scalability by adding instances or servers without outages.

Read More: [Deploying Oracle RAC for High Availability](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/design-and-deployment-techniques/deploying-oracle-rac-for-high-availability.html)

## General Design Considerations for Oracle RAC

Oracle RAC application design should proceed through application, memory and I/O, contention, and operating-system tuning, because RAC cannot compensate for an application that fails to scale on a symmetric multiprocessing system. For insert-intensive OLTP workloads, hash partitioning of tables and indexes can reduce concurrent insert contention and improve RAC performance transparently, although hash-partitioned indexes do not support index range scans.

Read More: [General Design Considerations for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/design-and-deployment-techniques/general-design-considerations-for-oracle-rac.html)

## Oracle RAC Sharding for Shard-Friendly Applications

Oracle RAC Sharding routes connections to instances according to a business sharding key, reducing inter-instance block transfers while preserving access to all tables from every instance. It is best suited to applications that know a stable, well-distributed key before connection checkout, use that key in SQL predicates, and concentrate transaction work on the same key; it is less effective for skewed or broadly distributed workloads. Deployment involves selecting and partitioning a frequently accessed table, enabling affinity, passing the key through the connection pool, and using it consistently in SQL, while unaffected application modules can continue using normal load balancing.

Read More: [Oracle RAC Sharding for Shard-Friendly Applications](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/design-and-deployment-techniques/oracle-rac-sharding-for-shard-friendly-applications.html)

## General Database Deployment Topics for Oracle RAC

Oracle RAC deployment benefits from locally managed tablespaces, automatic segment space management, and separate undo tablespaces for each instance, while limiting DDL during peak activity to avoid unnecessary overhead. Adding or removing nodes may require corresponding SYSAUX resizing. Poor XA transaction performance can be improved by directing all branches of a tightly coupled distributed transaction through a singleton DTP service on the same instance. RAC is well suited to OLTP because Cache Fusion supports availability, scalability, and load balancing, and to data warehouses because parallel execution can distribute work across instances using optimizer decisions based on cluster resources. TDE requires one shared keystore accessible to all nodes, Windows firewall settings must permit required Oracle connections, and ONS clients can be secured with wallets and appropriate configuration.

Read More: [General Database Deployment Topics for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/design-and-deployment-techniques/general-database-deployment-topics-for-oracle-rac.html)

## Introduction to Blocker Resolver

Blocker Resolver is an enabled-by-default RAC feature that detects, analyzes, verifies, and autonomously resolves database delays and deadlocks caused by blocking sessions. It runs as the DIA0 task, gathers cluster-wide information, waits for configurable thresholds, and terminates the blocking session or process when a delay does not resolve naturally, with priority given to protecting high-ranking sessions. Administrators can configure Normal or High sensitivity and control trace-file size and count through DBMS\_BLOCKER\_RESOLVER; the deprecated DBMS\_HANG\_MANAGER should no longer be used. Resolutions are recorded as ADR incidents with ORA-32701 in alert logs, while detailed diagnostics are written to DIA0 trace files.

Read More: [Introduction to Blocker Resolver](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/design-and-deployment-techniques/introduction-to-blocker-resolver.html)


# Monitoring Performance

Learn how to monitor and tune the performance of your Oracle Real Application Clusters (Oracle RAC) database.

## Monitoring and Tuning Oracle RAC Databases

Oracle Enterprise Manager provides cluster-aware monitoring through the Cluster Database Home, Interconnects, and Cluster Database Performance pages, enabling administrators to review cluster status, alerts, services, cache coherency, network activity, host load, active sessions, throughput, wait classes, services, and instances. Standard database tuning practices also apply to RAC, while the Database Reliability Framework continuously detects cross-layer issues and can automatically correct problems by adjusting memory structures or process priorities.

Read More: [Monitoring and Tuning Oracle RAC Databases](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/monitoring-and-tuning-oracle-rac-databases.html)

## Verifying the Interconnect Settings for Oracle RAC

Interconnect configuration affects Cache Fusion performance through its bandwidth, latency, and IPC efficiency. Query V$CLUSTER\_INTERCONNECTS and V$CONFIGURED\_INTERCONNECTS to verify the connected instance’s private and public interfaces, addresses, and configuration sources; use GV$CLUSTER\_INTERCONNECTS to inspect all cluster instances.

Read More: [Verifying the Interconnect Settings for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/verifying-the-interconnect-settings-for-oracle-rac.html)

## Influencing Interconnect Processing

Interconnect hardware performance cannot usually be changed after deployment, but IPC buffer sizes can influence protocol efficiency. Oracle Clusterware stores interconnect information in the OCR, which can be inspected or modified with OIFCFG or OCRDUMP; the CLUSTER\_INTERCONNECTS parameter can also assign a private address or NIC when necessary. Supported clusters may use multiple private networks with either IPv4 or IPv6, but the same protocol must be used consistently.

Read More: [Influencing Interconnect Processing](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/influencing-interconnect-processing.html)

## Performance Views in Oracle RAC

Oracle RAC provides instance-specific V$ dynamic performance views and cluster-wide GV$ views. GV$ views combine qualified instances’ V$ data and add the INST\_ID column, allowing administrators to identify the originating instance or restrict queries, such as selecting lock information from specific instances.

Read More: [Performance Views in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/performance-views-in-oracle-rac.html)

## Creating Oracle RAC Data Dictionary Views with CATCLUST.SQL

RAC databases created without Database Configuration Assistant may lack required RAC-related data dictionary views and tables. In that situation, an account with SYSDBA privileges must run the CATCLUST.SQL script to complete the RAC data dictionary configuration.

Read More: [Creating Oracle RAC Data Dictionary Views with CATCLUST.SQL](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/creating-oracle-rac-data-dictionary-views-with-catclust.sql.html)

## Oracle RAC Performance Statistics

Oracle RAC performance statistics are reported as message request counters or timed statistics. Message counters quantify activities such as block mode conversions, while timed statistics measure total or average wait time for specific read and write I/O operations.

Read More: [Oracle RAC Performance Statistics](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/oracle-rac-performance-statistics.html)

## Automatic Workload Repository in Oracle RAC Environments

AWR creates hourly snapshots containing synchronized performance data from all active RAC instances, storing values separately by instance rather than as cluster-wide aggregates. ADDM can analyze this data across the entire cluster, a single instance, or a selected subset of instances through RAC, Local, or Partial ADDM modes, using Enterprise Manager or PL/SQL packages.

Read More: [Automatic Workload Repository in Oracle RAC Environments](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/automatic-workload-repository-in-oracle-rac-environments.html)

## Active Session History Reports for Oracle RAC

ASH reports diagnose RAC performance by sampling active sessions across instances, focusing on sessions using CPU or waiting on non-idle events and thereby limiting data to workload-related activity. RAC-specific sections include Top Cluster Events, which identifies events and instances responsible for cluster wait activity, and Top Remote Instance, which identifies instances contributing most to prolonged cluster waits.

Read More: [Active Session History Reports for Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/active-session-history-reports-for-oracle-rac.html)

## Monitoring Oracle RAC Statistics and Wait Events

RAC performance analysis uses AWR, Statspack, dynamic performance views, ASH, ADDM, and GCS/GES statistics to evaluate global cache activity, enqueue messaging, block transfers, remote requests, and wait behavior. Cluster wait events distinguish normal cache traffic from issues involving hot blocks, contention, load, interconnect misconfiguration, or excessive SQL block access; analysis should correlate wait time, affected objects and instances, SQL cluster wait time, CPU and network conditions, and service times to determine corrective actions such as SQL tuning, workload redistribution, or additional capacity.

Read More: [Monitoring Oracle RAC Statistics and Wait Events](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/monitoring-performance/monitoring-oracle-rac-statistics-and-wait-events.html)


# Converting Single-Instance Oracle AI Databases to Oracle RAC and Oracle RAC One Node

Learn about procedures for converting from Oracle AI Database single-instance databases to Oracle Real Application Clusters (Oracle RAC) and Oracle RAC One Node databases.

## Converting to Oracle RAC and Oracle RAC One Node Using Oracle DBCA

Oracle DBCA automates conversion from a single-instance Oracle AI Database to Oracle RAC or Oracle RAC One Node by configuring control files, undo tablespaces, redo logs, initialization parameters, networking, Clusterware resources, and management services. The process requires supported cluster hardware, shared storage accessible by all nodes, compatible applications, Grid Infrastructure, cluster validation, a DBCA-generated database template, and RAC-enabled database software. Procedures cover creating the database image, installing Grid Infrastructure, registering the database with Clusterware, installing RAC software, and deploying the template. Additional workflows address conversions on clusters with RAC-enabled or RAC-disabled homes, automated and manual RAC conversion, and conversion from a single server to RAC One Node using relinking, SRVCTL, and DBCA.

Read More: [Converting to Oracle RAC and Oracle RAC One Node Using Oracle DBCA](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/converting-single-instance-oracle-ai-databases-to-oracle-rac-and-oracle-rac-one-node/converting-to-oracle-rac-and-oracle-rac-one-node-using-oracle-dbca.html)

## Preparing to Convert with rconfig and Oracle Enterprise Manager

Conversions using rconfig or Oracle Enterprise Manager require a backup and a properly prepared Oracle RAC environment with Grid Infrastructure, RAC software, enabled RAC functionality, clustered ASM or shared file storage, user equivalence, and configured management agents when Enterprise Manager is used. Although rconfig is deprecated in Oracle AI Database 26ai, it can convert databases across supported Oracle homes and storage configurations, potentially enabling archiving, moving files, and configuring Oracle Managed Files. Enterprise Manager provides a guided Convert to Cluster Database workflow for credentials, cluster nodes, listeners, instance prefixes, shared storage, recovery areas, review, and job monitoring.

Read More: [Preparing to Convert with rconfig and Oracle Enterprise Manager](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/converting-single-instance-oracle-ai-databases-to-oracle-rac-and-oracle-rac-one-node/preparing-to-convert-with-rconfig-and-oracle-enterprise-manager.html)

## Converting Databases to Oracle RAC Using rconfig

The deprecated rconfig utility converts a single-instance database to Oracle RAC or Oracle RAC One Node according to settings in a customized ConvertToRAC XML file. Administrators should edit the sample configuration without storing passwords, select verification behavior, and run the utility from the Oracle home bin directory; verification can perform checks only, check before conversion, or skip prerequisite checks. If conversion fails, delete the target database with DBCA, restore the source database, inspect rconfig logs under the Oracle Base configuration logs, correct the reported issues, and retry.

Read More: [Converting Databases to Oracle RAC Using rconfig](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/converting-single-instance-oracle-ai-databases-to-oracle-rac-and-oracle-rac-one-node/converting-databases-to-oracle-rac-using-rconfig.html)

## Example of rconfig XML Input Files for ConvertToRAC

The sample ConvertToRAC XML configuration demonstrates converting an ASM-based single-instance database to an administrator-managed Oracle RAC database. It defines verification mode, source and target Oracle homes, source SID and SYSDBA credentials, cluster nodes, an optional instance prefix, optional RAC One Node service settings, storage type, target database area, and fast recovery area. Passwords must be omitted so rconfig can request them interactively, and the file’s storage and node values must be adapted to the target environment.

Read More: [Example of rconfig XML Input Files for ConvertToRAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/converting-single-instance-oracle-ai-databases-to-oracle-rac-and-oracle-rac-one-node/example-of-rconfig-xml-input-files-for-converttorac.html)

## Postconversion Steps

After converting to Oracle RAC, configure load balancing and application failover with AC or TAC, run ORAchk for health validation, prefer locally managed tablespaces, and use automatic segment space management. Because RAC requires more memory than a single-instance database, increase buffer cache capacity by approximately 10 percent and shared pool capacity by approximately 15 percent, while also applying RAC service and workload-management practices.

Read More: [Postconversion Steps](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/converting-single-instance-oracle-ai-databases-to-oracle-rac-and-oracle-rac-one-node/postconversion-steps.html)


# A Server Control Utility Reference

Use the Server Control Utility (SRVCTL) to manage Oracle Real Application Clusters (Oracle RAC) configuration information.

> **Note:**
>
> SRVCTL commands specific to Oracle Grid Infrastructure administration operations are documented in [Oracle Clusterware Administration and Deployment Guide](https://docs.oracle.com/pls/topic/lookup?ctx=en/database/oracle/oracle-database/26/racad&id=CWADD-GUID-F2CBA060-E4F2-4EB1-A0A7-11144D68A26A)

## SRVCTL Usage Information

SRVCTL is installed on every cluster node and must be run with the version from the Oracle home managing the target object. Commands are case-sensitive, must not run concurrently against the same object, and require comma-delimited values without spaces; Windows lists must be quoted. Successful commands may produce no output, with return codes of 0 for success, 1 for failure, and 2 for warnings. The `-eval` option can simulate supported database and service operations without changing the system.

Read More: [SRVCTL Usage Information](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/srvctl-usage-information.html)

## Specifying Command Parameters as Keywords Instead of Single Letters

Single-letter SRVCTL parameters are deprecated, and Oracle recommends using full keyword forms such as `-multicastport` and `-subdomain`. Mixed use remains supported for backward compatibility, including newly introduced keyword parameters alongside legacy letters. Use `-compatible` with `-help` to display applicable single-letter equivalents.

Read More: [Specifying Command Parameters as Keywords Instead of Single Letters](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/specifying-command-parameters-as-keywords-instead-of-single-letters.html)

## Character Set and Case Sensitivity of SRVCTL Object Values

SRVCTL object names have type-specific character, case, uniqueness, and length restrictions. Database domains, unique names, PDBs, disk groups, instances, listeners, nodes, SCAN names, services, and volumes each support defined character sets and maximum lengths; most names are case-insensitive, while instance and listener sensitivity can depend on the platform and disk group names are converted to uppercase.

Read More: [Character Set and Case Sensitivity of SRVCTL Object Values](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/character-set-and-case-sensitivity-of-srvctl-object-values.html)

## Summary of Tasks for Which SRVCTL Is Used

SRVCTL manages cluster database configurations, instances, services, databases, Oracle ASM instances and disk groups, listeners, VIPs, node applications, and related clusterware resources. It supports adding, modifying, removing, enabling, disabling, starting, stopping, relocating, configuring environments, and obtaining status for database and node-level resources.

Read More: [Summary of Tasks for Which SRVCTL Is Used](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/summary-of-tasks-for-which-srvctl-is-used.html)

## Using SRVCTL Help

Use `srvctl -help` to view all commands, or `srvctl command object -help` to display syntax and parameters for a specific operation. Help shows full keyword parameters by default, while adding `-compatible` displays available legacy single-letter forms. Use `srvctl -version` to display the installed SRVCTL version.

Read More: [Using SRVCTL Help](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/using-srvctl-help.html)

## SRVCTL Privileges and Security

Run SRVCTL as the software owner of the Oracle home managing the target resource: database owners manage databases, and Grid Infrastructure owners manage Oracle ASM. OSDBA members can start and stop databases, while OSASM members are required for Oracle ASM operations. Creating or registering objects requires the owning Oracle home account, and some commands require root on Linux or UNIX or Administrator privileges on Windows; root-required commands should be run from the secured Grid Infrastructure home.

Read More: [SRVCTL Privileges and Security](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/srvctl-privileges-and-security.html)

## Additional SRVCTL Topics

Use SRVCTL for Oracle-supplied resources such as listeners, instances, disk groups, and networks, and use CRSCTL for Oracle Clusterware resources rather than directly manipulating resources whose names begin with `ora`. Do not cancel running SRVCTL commands with Control-C, because interruption can corrupt configuration data.

Read More: [Additional SRVCTL Topics](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/additional-srvctl-topics.html)

## Deprecated SRVCTL Subprograms or Commands

SRVCTL continues to accept deprecated single-character parameters and several legacy commands for compatibility, but scripts should be updated to use full keywords. Deprecated functionality includes numerous one-letter aliases, selected database, instance, ASM, GNS, service, and OC4J options, the `oc4j` noun, service `PRECONNECT` TAF usage, and the service `-failovermethod` option. Older scripts, especially those from Oracle Database 12.2 and earlier, should be reviewed and modernized.

Read More: [Deprecated SRVCTL Subprograms or Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/deprecated-srvctl-subprograms-or-commands.html)

## SRVCTL Command Reference

SRVCTL uses the syntax `srvctl command object [parameters]`, where commands are verbs, objects identify resources, and parameters refine operations. Names and parameters are case-sensitive, although database, instance, listener, and service names preserve case while comparing case-insensitively. The reference covers database, disk group, home, instance, listener, network, node applications, ONS, PDB, SCAN, SCAN listener, service, VIP, and volume objects, including configuration, lifecycle, status, relocation, and prediction operations.

Read More: [SRVCTL Command Reference](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/srvctl-command-reference.html)

## Database Commands

Database-object commands manage Oracle RAC and related database resources throughout their lifecycle. They add, configure, convert, enable, disable, start, stop, relocate, remove, upgrade, downgrade, update, predict, and report database status while supporting Oracle RAC, RAC One Node, single-instance deployments, Data Guard roles, startup and shutdown options, policies, concurrency, disk groups, ACFS dependencies, environment variables, memory limits, listeners, and candidate nodes. Commands such as `srvctl add database`, `modify database`, `start database`, `stop database`, `status database`, and `remove database` provide the principal configuration and operational controls.

Read More: [Database Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/database-commands.html)

## Diskgroup Commands

Oracle ASM disk groups are managed with SRVCTL commands using the `diskgroup` keyword. Available operations include enabling or disabling disk groups on specified Clusterware nodes, predicting failure consequences, starting and stopping resources, displaying detailed or verbose status, and removing disk group resources with optional dependency checks bypassed by `-force`.

Read More: [Diskgroup Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/diskgroup-commands.html)

## Home Commands

SRVCTL `home` commands manage all Oracle Restart- or Oracle Clusterware-managed resources associated with an Oracle home. Administrators can start, stop, and check resource status by specifying the Oracle home, state file, and—when using Clusterware—the hosting node; stop operations also support database shutdown options and forced execution.

Read More: [Home Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/home-commands.html)

## Instance Commands

SRVCTL `instance` commands manage Oracle RAC database instances, including adding, modifying node assignments, enabling, disabling, starting, stopping, transferring between Oracle homes, updating startup or ASM target settings, checking status, and removing configurations. Most operations require Oracle Clusterware and RAC, support node or instance lists, and provide controls for startup, shutdown, service draining, failover, force, and detailed output.

Read More: [Instance Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/instance-commands.html)

## Listener Commands

SRVCTL `listener` commands provide comprehensive management of database and Oracle ASM listeners registered with Oracle Restart or Oracle Clusterware. Operations include adding, configuring, modifying endpoints, Oracle homes, owners, networks, and environment variables; enabling, disabling, starting, stopping, checking status, predicting failures, exporting configuration, and removing listeners, with options for cluster nodes, secure protocols, forced actions, and privileged ownership changes.

Read More: [Listener Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/listener-commands.html)

## Network Commands

SRVCTL `network` commands manage non-default Oracle Clusterware networks used for additional RAC interfaces and VIPs. Administrators can add, configure, modify, inspect, predict failure impact for, and remove networks, defining subnets, interfaces, IPv4 or IPv6 address types, static, DHCP, autoconfiguration, or mixed behavior, ping targets, and dependency handling; administrative privileges are required.

Read More: [Network Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/network-commands.html)

## Nodeapps Commands

SRVCTL `nodeapps` commands manage node-level applications, including VIPs, Oracle Notification Service, Enterprise Manager ports, administrator helpers, remote servers, and security wallets. Operations cover adding, modifying, configuring, enabling, disabling, starting, stopping, checking status, removing, and managing environment variables, with support for static or DHCP subnets, VIP relocation, selective ONS or VIP actions, forced removal, and Clusterware-specific administration.

Read More: [Nodeapps Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/nodeapps-commands.html)

## ONS Commands

SRVCTL `ons` commands manage Oracle Notification Service daemons exclusively in Oracle Restart environments. Administrators can add, configure, modify ports and remote servers, export credentials, enable, disable, start, stop, check status, and remove ONS instances, optionally targeting a client cluster associated with a shared SCAN listener and using verbose or force options where supported.

Read More: [ONS Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/ons-commands.html)

## PDB Commands

Use the `srvctl` `pdb` keyword to manage Pluggable Databases in an Oracle RAC cluster, including adding, configuring, modifying, enabling, disabling, relocating, starting, stopping, removing, and checking status. `srvctl add pdb` registers a PDB with options for instance cardinality, CPU limits, application root, startup and stop modes, management policy, and imported JSON configuration; `config` displays its configuration; `modify` changes supported placement, CPU, rank, startup, stop, and policy attributes; `enable` and `disable` control Clusterware management; `relocate` moves a PDB between nodes with optional draining and force controls; `start` and `stop` manage the PDB and services with node, mode, draining, and force options; `status` reports one or all PDB states; and `remove` unregisters the PDB configuration. Management policies include `AUTOMATIC`, `MANUAL`, and `RESTART`, with `RESTART` requiring the CDB to use the `RANK` policy.

Read More: [PDB Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/pdb-commands.html)

## SCAN Commands

Use the `srvctl` `scan` keyword to manage SCAN VIP resources in Oracle Clusterware. `srvctl add scan` creates SCAN VIP resources for a fully qualified SCAN name and selected network, while `config` displays or exports configuration for all or selected SCAN VIPs. `enable`, `disable`, `start`, and `stop` control all SCAN VIPs or a selected VIP by ordinal number, with optional node and force controls; `modify` synchronizes the number of SCAN VIPs with DNS-resolved addresses, supports multiple SCAN names across subnets, and can skip reachability checks; `relocate` moves a selected SCAN VIP to a specified or automatically selected node; `status` reports current state with optional detailed output; `predict` simulates the consequences of a SCAN VIP failure; and `remove` deletes SCAN VIP resources, optionally forcing removal and suppressing prompts. These commands are available with Oracle Clusterware, and SCAN ordinals range from 1 through 3.

Read More: [SCAN Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/scan-commands.html)

## SCAN Listener Commands

Use the `srvctl` `scan_listener` keyword to manage SCAN listener resources associated with SCAN VIPs. `srvctl add scan_listener` creates listeners with configurable network, name prefix, protocol endpoints, registration-allowed nodes or subnets, and shared-client-cluster settings; `config` displays or exports listener configuration; `enable`, `disable`, `start`, and `stop` control all or selected listeners by network, ordinal number, or shared client cluster, with optional node and force controls; `modify` updates listener resources to match SCAN VIP counts or changes endpoints and registration restrictions; `export` saves shared-listener credential data; `relocate` moves a selected listener to a specified or automatically selected node; `status` reports listener state for selected networks, ordinals, client clusters, or all resources; `predict` simulates failure consequences; `remove` unregisters listener resources with optional force and no-prompt behavior; and `update` applies new listener endpoints without additional parameters. SCAN listener ordinals range from 1 through 3, and these operations require Oracle Clusterware.

Read More: [SCAN Listener Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/scan-listener-commands.html)

## Service Commands

Service commands use the `service` keyword to create, configure, inspect, enable, disable, start, stop, predict, relocate, and remove database services. The page documents comprehensive `srvctl` syntax and parameters for service placement, roles, policies, load balancing, failover and Application Continuity, session state, PDB and global services, draining, stopping, and criticality, with commands for configuration export, status inspection, failure prediction, relocation, and resource removal. It also explains preferred and available instance management, online modification behavior, service attribute dependencies, Oracle RAC and Clusterware restrictions, and examples for basic, TAF, Application Continuity, and Transparent Application Continuity services.

Read More: [Service Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/service-commands.html)

## VIP Commands

VIP commands use the `vip` keyword to administer Oracle Clusterware virtual IP resources, including adding, configuring, enabling, disabling, starting, stopping, relocating, predicting failures, removing, and managing environment variables. The documented `srvctl` operations support IPv4 and IPv6 addresses, network and interface assignments, reachability checks, node targeting, dependency overrides, failover relocation, JSON configuration export, and environment variable inspection or updates. Commands are generally restricted to Oracle Clusterware and include controls for forced operations, prompts, verbose output, and stopping or relocating VIPs on specific nodes.

Read More: [VIP Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/vip-commands.html)

## Volume Commands

Oracle ACFS volume commands use the `volume` keyword with SRVCTL to display configuration and status, enable or disable Clusterware management, start or stop volumes, and remove volumes. These commands are supported only on Oracle ACFS platforms, and most operations require Oracle Clusterware. Volumes can generally be identified by name and disk group or by device path; status and stop operations can target selected nodes, configuration can be exported in JSON, and removal supports a `-force` option for running volumes.

Read More: [Volume Commands](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/server-control-utility-reference/volume-commands.html)


# B Troubleshooting Oracle RAC

This how diagnose problems for Oracle Real Application Clusters (Oracle RAC) components using trace and log files.

> **Note:**
>
> Trace and log files, similar to those generated for Oracle AI Database with Oracle RAC, are also available for the Oracle Clusterware components. For Oracle Clusterware, Oracle AI Database stores these under a unified directory log structure.

## Where to Find Files for Analyzing Errors

Oracle RAC records significant events in trace files stored in the Automatic Diagnostic Repository (ADR), whose location is controlled by the DIAGNOSTIC\_DEST parameter. Each instance has an alert\_SID.log file containing ORA-600 errors and other operational exceptions, while background and user processes generate separate trace files with operating-system-specific names. Regular monitoring and backup of these files helps preserve diagnostic information for troubleshooting.

Read More: [Where to Find Files for Analyzing Errors](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/troubleshooting-oracle-rac/where-to-find-files-for-analyzing-errors.html)

## Managing Diagnostic Data in Oracle RAC

Oracle RAC provides ADR-based infrastructure for collecting and managing diagnostic data across instances, which is especially useful when problems require correlating or merging trace files. Placing all instance ADR homes under a shared ADR base enables ADRCI to view, correlate, and package incidents, problems, traces, dumps, health reports, and alert entries for Oracle Support. The Data Recovery Advisor can also diagnose and repair persistent failures such as corrupted blocks or missing files.

Read More: [Managing Diagnostic Data in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/troubleshooting-oracle-rac/managing-diagnostic-data-in-oracle-rac.html)

## Using Instance-Specific Alert Files in Oracle RAC

Each Oracle RAC instance maintains its own alert\_SID.log file in the directory specified by DIAGNOSTIC\_DEST. The file records important errors, exceptions, and startup-related information, is appended to whenever the instance starts, and can be written by all process threads associated with that instance.

Read More: [Using Instance-Specific Alert Files in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/troubleshooting-oracle-rac/using-instance-specific-alert-files-in-oracle-rac.html)

## Enabling Tracing for Java-Based Tools and Utilities in Oracle RAC

Oracle RAC Java-based utilities, including CVU, DBCA, NETCA, and SRVCTL, are invoked through scripts named for each utility. Tracing is enabled by default for DBCA and DBUA, while setting SRVM\_TRACE to TRUE enables tracing for CVU and SRVCTL. Generated logs are stored in utility-specific directories under Oracle\_base/cfgtoollogs, such as the dbca and dbua directories.

Read More: [Enabling Tracing for Java-Based Tools and Utilities in Oracle RAC](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/troubleshooting-oracle-rac/enabling-tracing-for-java-based-tools-and-utilities-in-oracle-rac.html)

## Resolving Pending Shutdown Issues

When SHUTDOWN IMMEDIATE remains pending, Oracle Clusterware may still be processing the original shutdown request, so repeated immediate shutdown commands may not respond promptly. Subsequent shutdown attempts should use SHUTDOWN ABORT through SQL\*Plus.

Read More: [Resolving Pending Shutdown Issues](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/troubleshooting-oracle-rac/resolving-pending-shutdown-issues.html)

## How to Determine If Oracle RAC Instances Are Using the Private Network

The private interconnect used by Oracle RAC can be examined with the oradebug ipc command, which writes network details to a trace file under DIAGNOSTIC\_DEST; oradebug tracefile\_name identifies that file. The V$CLUSTER\_INTERCONNECTS view provides additional interconnect information, including interface names, IP addresses, status, and source, although Enterprise Manager Cloud Control is the recommended method for checking the interconnect.

Read More: [How to Determine If Oracle RAC Instances Are Using the Private Network](https://docs.oracle.com/en/database/oracle/oracle-database/26/racad/troubleshooting-oracle-rac/how-to-determine-if-oracle-rac-instances-are-using-the-private-network.html)