Oracle Autonomous AI Database automatically configures and manages Oracle Real Application Clusters (RAC), giving customers its performance and availability benefits without the complexity of managing the cluster themselves. For most customers, RAC simply works in the background while they focus on their applications.

For customers with more specialized requirements, Autonomous AI Database on Dedicated Exadata Infrastructure offers additional control and flexibility. Administrators can tailor how databases use RAC nodes to favor single-node execution, distribute work more broadly, or preserve capacity for failover and future growth. These settings let customers align RAC placement with their workload priorities while Oracle continues to manage the underlying infrastructure.

These Dedicated controls are now more flexible. Database split threshold, Distribution affinity, and Node failover reservation were previously configurable only when creating an Autonomous Container Database (ACD). All three are now editable, letting administrators adjust a database’s RAC footprint and its failover CPU reservation without recreating the ACD.

At the Autonomous Exadata VM Cluster (AVMC) level, the new Distribution Algorithm setting lets administrators favor resource density or more balanced database placement across nodes.

These controls apply to Dedicated deployments in Oracle Cloud, on Exadata Cloud@Customer, and on Oracle Database@AWS and Oracle Database@Azure. Configure them through the OCI console.

Choose when a database opens across nodes

The Database split threshold is the ECPU value above which an Autonomous AI Database (ADB) opens across multiple RAC nodes. The default is 64 ECPUs, constrained by the ECPU capacity per node. For example, if each node has 40 ECPUs, a 60-ECPU ADB must span nodes even with the threshold set to 64 ECPUs. The threshold guides placement but cannot increase a node’s overall capacity.

A higher threshold can keep smaller databases on one node, preserving DML locality and reducing cross-instance coordination. This can suit latency-sensitive workloads and fleets with many small databases. A lower threshold causes a database to be open across multiple RAC nodes at a smaller CPU allocation. This allows work to run on multiple instances and keeps other instances open during a node event, such as rolling patching.

Manual scaling reevaluates placement using the new allocation and current split threshold. With a 64-ECPU threshold and sufficient node capacity, scaling an ADB from 48 to 96 ECPUs causes it to split; scaling back to 48 reevaluates it for single-node placement. Choose the threshold around the database’s expected ECPU allocation and workload behavior.

After scaling completes, connect to the ADB with an account that has access to GV$PDBS and run the following query to confirm where the database is open:

SELECT inst_id, open_mode
FROM   gv$pdbs
ORDER BY inst_id;

Each returned row identifies a RAC instance where the ADB is open. One row indicates single-node placement; two or more rows indicate multi-node placement. This verifies the database’s open instances, not how application traffic is distributed among them.

To evaluate performance, run a workload that reflects typical application activity and concurrency, then compare response time and throughput with your application’s targets.

Choose how broadly a split database is distributed

Once an ADB crosses the threshold, Distribution affinity sets its preferred node count. Minimum nodes, the default, favors the fewest nodes that can accommodate the allocation. Maximum nodes favors as many nodes as practical. Both depend on available capacity and placement constraints.

For example, take a four-node AVMC with 80 ECPUs per node, an ACD split threshold of 64 ECPUs, and a 120-ECPU ADB:

  • Minimum nodes tries two nodes with 60 ECPUs each, then three with 40 each, then four with 30 each if earlier placements cannot be satisfied.
  • Maximum nodes tries the same placements in reverse order: four nodes, then three, then two.

Minimum nodes favors consolidation and leaves more placement flexibility elsewhere. Maximum nodes spreads the allocation more broadly and can retain a larger share of active compute during a node event.

A database open on one node still has high availability

An ADB open on one RAC node still benefits from the service’s high availability. For these non-split databases, the ACD’s Node failover reservation (%) controls the CPU capacity set aside on other nodes for localized failures and maintenance.

When this setting is greater than 0%, the service reserves CPU capacity to guarantee that the configured failover capacity is available on a surviving node. With the default 50% reservation, the database can run there with 50% of its allocated CPU capacity. This reserves compute for recovery; it does not guarantee the original throughput or uninterrupted application sessions.

The additional CPUs reserved for failover are not billed. With a 50% reservation, that capacity can also serve other ADBs on the node during normal operation. During failover or maintenance, the affected ADBs, including those already on the surviving node, operate at 50% of their allocations. For example, two ADBs normally allocated 32 ECPUs each on different nodes, both configured at 50%, can each run with 16 ECPUs on the surviving node.

At 100%, the failover headroom cannot also be committed to other ADBs: the surviving node needs capacity for the full allocations of both resident and incoming databases. In the same example, it needs 64 ECPUs to keep both ADBs at 32 ECPUs. This preserves full CPU allocations through the event but requires more capacity to remain available.

At 0%, no CPU capacity is reserved for this purpose, and the database will experience a service interruption when its hosting node is unavailable, such as during rolling patching or an unplanned node event.

Split databases retain compute capacity on the remaining nodes during a node event, such as rolling patching. For example, a database with its CPU allocation evenly distributed across four nodes retains 75% of that allocation while one node is unavailable. Actual throughput depends on the workload.

Currently Node failover reservation (%) can only be decreased while the ACD contains ADBs. If the ACD contains no ADBs, you can increase or decrease it. Support to reconfigure nonempty ACDs is planned.

Use the VM cluster policy to guide placement

The new AVMC Distribution Algorithm helps choose which nodes each database runs on, within the ACD’s split threshold and distribution affinity settings. You can configure the algorithm when creating the AVMC or change it afterward.

Resource Optimized, the default, favors consolidation by choosing valid placements that need the least additional resource growth.

Distribution Optimized favors spreading databases more evenly across nodes to reduce workload concentration.

Consider a 16-ECPU ADB in a four-node AVMC with a 64-ECPU split threshold. Node 1 hosts several ADBs but can accommodate this one within the ACD’s existing allocation. Node 3 has a smaller database footprint but would need additional ACD resources. Assume both placements satisfy capacity, failover reservation, and other resource requirements.

With Resource Optimized, the policy favors node 1: it can reuse existing ACD capacity, leaving more capacity on node 3 available for future database creation or growth.

With Distribution Optimized, the policy favors node 3: it improves the balance of databases across the cluster, even though it requires additional resource allocation on that node.

These are placement preferences, not guaranteed node assignments. Both modes honor the ACD split rules. In this example, the ADB remains open on one node; Distribution Optimized does not itself force it to open on more nodes.

Apply the settings

To update the ACD controls in the OCI Console, open ACD Details and find Data resource configuration. Select Edit next to Database split threshold (CPU), Distribution affinity, or Node failover reservation (%), adjust the settings, and select Update.

To change the AVMC policy, open AVMC Details, find Resource allocation, and select Edit next to Distribution algorithm. Choose Resource Optimized or Distribution Optimized, then select Update.

Currently, saved settings take effect for an existing ADB when a manual CPU scaling operation reevaluates its placement. Apply that operation to every ADB in the selected ACD for an ACD change, or every ADB across all ACDs in the AVMC for a Distribution Algorithm change. Updating the policy alone does not automatically redistribute the existing databases.

Oracle is advancing service automation to apply ACD and AVMC configuration changes to affected ADBs without requiring a follow-up CPU scaling operations. Until this capability is available, manual CPU scaling remains required for each affected ADB.

Adjust placement as requirements change

Dedicated gives customers the flexibility to tailor RAC placement to their workloads while retaining Autonomous management. With the ACD controls now editable and the new AVMC distribution policy, teams can revisit placement and failover capacity as applications evolve, without recreating the ACD. Customers set the policies; Oracle continues to manage RAC.

Learn more