Oracle RAC Database Deployment Models (Changes in 26ai & earlier)

Oracle RAC Database Deployment Models (Changes in 26ai & earlier)

Starting with Oracle Database 21c, there is a single, merged management style for Oracle RAC databases.

Note:

The policy-managed database deployment option is de-supported in Oracle Database 26ai.

Prior to Oracle Database 21c, Oracle RAC databases support two different management styles and deployment models: administrator-managed deployment and policy-managed deployment.

·        Administrator-managed deployment requires that you statically configure each database instance to run on a specific node in the cluster. This deployment also requires that you configure database services to run on specific instances that belong to a particular database using the preferred and available designation.

·        Policy-managed deployment is based on server pools. In this deployment, database services run within a server pool as singleton or uniform across all of the servers in the server pool.

Databases are deployed in one or more server pools and the size of the server pools

determine the number of database instances in the deployment.

Starting with Oracle Database 21c, the two management styles are merged into a single deployment model that combines the best features of each model. The administrator-managed database deployment style now has additional capabilities that were previously available only in policy-managed databases.

These enhancements result in a new, converged deployment style. To use the merged database management style, you must have a Container Database

(CDB) with at least one Pluggable Database (PDB).

You manage the merged database deployment model using the same commands and utilities (such as SRVCTL, Oracle DBCA, or Oracle Enterprise Manager) as before. All commands and utilities, except for the policy-management specific commands such as srvpool commands, maintain backward compatibility to support the management of Oracle databases prior to Oracle Database 21c.

The merged database management style simplifies management of dynamic systems. The clusters and databases can expand or shrink as requirements change. The Oracle home software must be installed on every node in the cluster.

Benefits of the merged management style

The PDBs in the cluster database are available on all nodes, or a subset of the nodes, based on the cardinality setting for the PDB. The cardinality of a PDB governs the number of nodes where a PDB can run at the same time. If you use a number for cardinality instead of ALL, then the instances in which the PDBs are opened depend on the resources available to each instance.

A database instance is started on every server in the cluster that hosts a PDB. If you are using Oracle Automatic Storage Management (Oracle ASM) with Oracle Managed Files for your database storage, then, when an instance starts and there is no redo thread available, Oracle RAC automatically enables one and creates the required redo log files and undo tablespace.

Clients can connect to a PDB using the same SCAN-based connect string irrespective of which servers the PDBs are running on at the time.

What Was “Policy-Managed Database Deployment”?

In Oracle RAC environments (11gR2 through 19c), you could configure your database in two deployment modes:

 

Mode	Description	Node Association	Tools / Features
Administrator-Managed	You manually specify which instances run on which nodes.	Fixed to specific nodes (e.g., node1, node2).	Classic mode, simple for small clusters.
Policy-Managed	You define server pools (logical groups of servers), and Oracle Clusterware automatically places and relocates instances.	Dynamic — instances float based on pool policies.	Used by QoS Management, Instance Caging, and server pools.

 In policy-managed mode, you didn’t bind instances to specific nodes.

Instead, you defined:

• Server Pools: named groups with MIN_SIZE, MAX_SIZE, and IMPORTANCE.
• Databases and Services assigned to those pools.
• QoS Management Policies operating on those pools.

Clusterware dynamically placed or moved instances between servers in those pools depending on workload, resource availability, or QoS recommendations.

Example:

srvctl add serverpool -serverpool oltp_pool -min 2 -max 4 -importance 100

srvctl modify database -db FINDB -serverpool oltp_pool

This was the policy-managed model ; the foundation of Oracle QoS Management in RAC.

 What Changed in Oracle AI Database - 26ai

Oracle officially desupported policy-managed database deployments in Oracle Database 26ai (23c).

That means:

• You can no longer create or use policy-managed databases.
• Server pools and their automatic instance placement model are removed.
• RAC databases must now use administrator-managed configuration.

What “Desupported” Means

“Desupported” in Oracle terminology means:

• You cannot create new policy-managed databases in 26ai.
• Existing policy-managed databases must be converted to administrator-managed before upgrade.
• The related commands (like srvctl add serverpool, srvctl modify database -serverpool, etc.) are no longer valid for database placement.
• QoS Management functionality that depended on server pools is no longer available.

Why Oracle Made This Change

There are several reasons Oracle deprecated this model:

1.     Complexity
Many customers found server pool and policy-managed setups confusing to operate and troubleshoot.

2.     Low Adoption
Most real-world RAC environments (especially Exadata and production workloads) used administrator-managed mode.

3.     Integration Simplification
Oracle wanted to streamline cluster management around a single, predictable model — administrator-managed.

4.     Shift Toward Autonomous and Multitenant
Oracle’s new architectures (Autonomous Database, Multitenant, Cloud RAC) handle resource control differently, without manual server pool constructs.

What Happens to QoS Management

QoS Management in its classic form (policy-based RAC control via server pools) is effectively retired starting with Oracle 26ai.

Key implications:

• QoS Management relied on server pools and performance classes; these no longer exist in 26ai.
• QoS metrics and recommendations (via Enterprise Manager or EMCLI) are not available in 26ai RAC.
• Resource isolation and prioritization should now be handled using:
• Oracle Resource Manager
• Instance Caging
• CDB/PDB Resource Plans
• Services and Load Balancing Advisory

So, in 26ai and future versions, QoS-style behavior is expected to move to Multitenant resource management and Autonomous Database infrastructure, not Clusterware-level QoS.

 If You’re Currently Using QoS or Server Pools

Before upgrading to 26ai:

1.     Convert your policy-managed databases to administrator-managed.

srvctl convert database -db FINDB -admin-managed

2.     Retire server pool usage; manage instances explicitly on specific nodes.

3.     Migrate QoS controls to:

o    Oracle Resource Manager plans (CPU, I/O, session control)

o    Service-level resource directives

o    Instance Caging for CPU isolation

Oracle provides migration utilities and step-by-step guides in:

Oracle Database 26ai Upgrade Guide → Desupported Features → Policy-Managed Database Deployments

Summary

Feature	Status in 26ai	Replacement
Policy-managed databases	Desupported	Administrator-managed
Server pools	Desupported	Explicit node instance mapping
Oracle QoS Management	Retired	Resource Manager / Instance Caging
Dynamic instance placement	Removed	Manual instance placement
RAC QoS metrics	Unavailable	EM performance monitoring / Resource plans

 Finally:

Oracle Database 26ai eliminates the policy-managed deployment model and its dependent technologies (like QoS Management based on server pools).
RAC databases must now be deployed in administrator-managed mode, with performance and isolation handled via Resource Manager and instance caging, not server pool reallocation.

 

++++++ Alireza Kamrani ++++++