Consolidation Requires Enforced Boundaries
Oracle Multitenant makes database consolidation operationally attractive, but a CDB is also a shared failure domain. A reporting query in one PDB can consume parallel servers, a connection storm can exhaust process capacity, and uncontrolled PGA growth can create host-level memory pressure that affects every tenant. Separate schemas do not provide resource isolation, and virtual-machine sizing does not distinguish between workloads inside the same Oracle instance. Production consolidation therefore requires explicit controls at both levels of the hierarchy: the CDB must divide resources among PDBs, while each PDB must govern competing workloads within its allocation.
Oracle AI Database 26ai provides several overlapping mechanisms: CDB Resource Manager plans, PDB performance profiles, PDB initialization parameters, PDB-local resource plans, and, on Exadata, I/O Resource Management. These controls solve different problems. Shares determine relative entitlement during contention, utilization limits impose ceilings, and memory or I/O parameters constrain specific resource classes. Treating them as interchangeable creates policies that appear correct in configuration reviews but do not produce the expected behavior under load.
Separate Entitlements from Ceilings
A CDB resource plan allocates CPU and parallel execution capacity between PDBs. The shares value is a relative weight, not a reservation of a fixed percentage. If GOLD has four shares and SILVER has two, GOLD receives twice SILVER’s allocation when both are CPU constrained; when GOLD is idle, SILVER can use otherwise available CPU unless another limit prevents it. This work-conserving behavior is desirable for consolidation because unused entitlement is not stranded.
The utilization_limit directive has different semantics: it caps the percentage of system CPU that a PDB can consume. A low ceiling protects neighbors but can also throttle a critical tenant while the server remains partly idle. For latency-sensitive services, shares are usually the primary control, with ceilings reserved for workloads whose bursts must never dominate the CDB. Capacity models must also account for CPU consumed by the root, background processes, maintenance tasks, and workloads that cannot be attributed as ordinary foreground activity.
Performance profiles make this policy manageable across many PDBs. The following example creates reusable GOLD, SILVER, and BATCH classes in the CDB root. Values are illustrative; they must be derived from measured demand and service objectives rather than copied into production.
ALTER SESSION SET CONTAINER = CDB$ROOT;
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.CREATE_CDB_PLAN(
plan => 'CONSOLIDATION_PLAN',
comment => 'Production PDB isolation');
DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
plan => 'CONSOLIDATION_PLAN',
profile => 'GOLD',
shares => 8,
utilization_limit => 100,
parallel_server_limit => 60);
DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
plan => 'CONSOLIDATION_PLAN',
profile => 'SILVER',
shares => 3,
utilization_limit => 40,
parallel_server_limit => 25);
DBMS_RESOURCE_MANAGER.CREATE_CDB_PROFILE_DIRECTIVE(
plan => 'CONSOLIDATION_PLAN',
profile => 'BATCH',
shares => 1,
utilization_limit => 20,
parallel_server_limit => 10);
DBMS_RESOURCE_MANAGER.VALIDATE_PENDING_AREA();
DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'CONSOLIDATION_PLAN';Oracle currently recommends avoiding parallel_server_limit in a CDB plan, so new 26ai designs should prefer tested PDB-level parallel settings and queuing unless a specific requirement justifies the directive. This illustrates an important operational rule: a syntactically valid plan is not necessarily the preferred control for the running release. Review current Oracle guidance during upgrades and retest policy behavior rather than assuming an inherited plan remains optimal.
Control Memory and I/O Independently
CPU isolation does not prevent memory exhaustion. At PDB scope, SGA_TARGET constrains the PDB’s SGA use, while PGA_AGGREGATE_LIMIT supplies a hard boundary for aggregate PGA. A limit that is too generous allows one tenant to pressure the entire instance; a limit that is too small can terminate or abort work when Oracle enforces the PGA boundary. The correct value must cover normal concurrency, expected hash and sort work areas, and a measured failure margin without allowing every PDB to reach its maximum simultaneously.
ALTER SESSION SET CONTAINER = SALES_PDB;
ALTER SYSTEM SET SGA_TARGET = 24G SCOPE=BOTH;
ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 8G SCOPE=BOTH;
ALTER SYSTEM SET PGA_AGGREGATE_LIMIT = 16G SCOPE=BOTH;
ALTER SYSTEM SET PARALLEL_SERVERS_TARGET = 48 SCOPE=BOTH;
ALTER SYSTEM SET DB_PERFORMANCE_PROFILE = GOLD SCOPE=SPFILE;The sum of configured PDB maxima may exceed physical memory only when operations understand the resulting overcommit risk and maintain sufficient telemetry and headroom. Oracle background memory, the root container, huge pages, operating-system consumers, and failover topology all consume capacity outside a simple PDB total. In RAC, surviving instances must tolerate the workload redistributed after an instance failure; sizing only for balanced steady state turns failover into a memory and CPU saturation event.
On non-Engineered Systems, MAX_IOPS and MAX_MBPS can constrain PDB I/O. They should be calibrated against storage latency and workload shape because identical throughput can represent very different pressure: small random OLTP operations stress IOPS, while scans and backups consume bandwidth. On Exadata, use I/O Resource Management to coordinate database and category-level priorities with storage-cell scheduling. A database-only limit cannot manufacture SAN capacity or repair an oversubscribed NFS path, so storage-array queues, multipath health, host latency, and network congestion remain part of the isolation design.
Govern Work Inside Each PDB
A CDB plan decides what a PDB receives; a PDB resource plan decides how that allocation is consumed. This distinction matters when one tenant contains interactive OLTP, reports, maintenance jobs, and data loads. Without consumer groups, a correctly protected PDB can still violate its own application SLO because batch sessions consume its entire entitlement. Map sessions using services, modules, users, or explicit application calls, and give connection pools a deterministic service identity instead of relying on ad hoc usernames.
A PDB-local plan can favor OLTP, limit active sessions for batch work, queue parallel statements, or switch long-running calls into a lower-priority consumer group. Application teams must understand that throttling often appears as increased database call time rather than an immediate error. Pool timeouts, retry policies, circuit breakers, and end-to-end deadlines must therefore be longer than expected Resource Manager queueing but shorter than the application’s business deadline. Otherwise a deliberate throttle can trigger retry amplification and create more sessions than the control was designed to contain.
Design for Administrative and HA Failure Modes
Resource policy is ineffective if a PDB administrator can change its performance class or raise local parameters. Use privilege separation and PDB lockdown profiles to prevent tenant administrators from modifying protected initialization parameters or switching DB_PERFORMANCE_PROFILE. Oracle recommends pairing performance profiles with corresponding lockdown profiles. The default CDB directive also needs intentional values because newly plugged or cloned PDBs may otherwise enter service without the expected class.
Plan activation is another common weakness. Verify RESOURCE_MANAGER_PLAN after startup, patching, Data Guard role transition, RAC instance addition, and infrastructure-as-code deployment. Parameter files and configuration automation must be consistent across RAC instances; asymmetric settings make capacity depend on service placement and instance survival. Disaster-recovery systems also need plans sized for their actual hardware. Copying primary percentages to a smaller standby preserves syntax, not service behavior, and may produce severe throttling immediately after a role change.
Resource Manager is not admission control for every shared dependency. Exhausted PROCESSES, listener limits, file descriptors, archive destinations, recovery-area capacity, and storage queues can still damage all PDBs. Services and connection pools should impose tenant-specific connection budgets, while operational runbooks must distinguish deliberate CPU throttling from host saturation. Killing sessions whenever latency rises defeats the policy and may intensify recovery work.
Validate Behavior Under Contention
Configuration inspection is necessary but insufficient. Query the active plan and directives, then observe per-PDB metrics while generating controlled competing workloads. The useful question is not whether a directive exists, but whether the lower-priority PDB accumulates throttled CPU or queue time while the protected service maintains its latency objective.
SELECT name, value
FROM v$parameter
WHERE name = 'resource_manager_plan';
SELECT plan, profile, shares, utilization_limit,
parallel_server_limit
FROM dba_cdb_rsrc_plan_directives
WHERE plan = 'CONSOLIDATION_PLAN'
ORDER BY profile;
SELECT p.name, m.begin_time, m.cpu_consumed_time,
m.cpu_wait_time, m.avg_running_sessions,
m.avg_waiting_sessions
FROM v$rsrcpdbmetric m
JOIN v$pdbs p ON p.con_id = m.con_id
ORDER BY m.begin_time, p.name;Monitor CPU consumed versus CPU wait, average running and waiting sessions, parallel queueing, PGA usage, SGA allocation, session counts, and I/O latency by PDB. Correlate those database metrics with host run queues, NUMA behavior, storage latency, Exadata cell metrics where applicable, and application response-time percentiles. A rising CPU wait value can demonstrate successful containment, but it can also reveal that the protected PDB was assigned inadequate entitlement; policy enforcement and capacity sufficiency are separate judgments.
The acceptance test should include simultaneous peak workloads, a batch overrun, a connection surge, RAC instance loss, and a planned Data Guard switchover where the architecture includes a standby. Confirm both containment and recovery: critical services must remain inside their latency budget, lower tiers must degrade predictably, and the system must return to normal without manual plan repair. Oracle Multitenant consolidation becomes dependable only when resource classes are treated as executable SLOs—version-controlled, protected from local alteration, continuously observed, and repeatedly tested against realistic contention and failure.
