Database Resource Manager in Oracle 26ai

Plans, Directives, and Consumer Groups

A resource plan brings together the policy for a management scope. Its plan directives associate the plan with consumer groups and specify the allocations, limits, and actions that apply. A consumer group represents sessions with similar processing requirements.

For example, an interactive group might receive favorable CPU treatment, while a reporting group has a lower allocation and a concurrency limit. The group identifies the workload; the directive describes how the active plan treats it. The same group can therefore receive different treatment under different plans.

The figure separates the active plan, its directives, and the groups whose sessions consume resources. These are organizational layers, not three CPU scheduling priority levels. The interactive and reporting directives can apply different controls even though they belong to the same plan.

Administrators maintain these definitions through DBMS_RESOURCE_MANAGER. Creating a definition does not automatically activate it or place application sessions in the intended groups. The RESOURCE_MANAGER_PLAN initialization parameter selects the applicable plan, and Scheduler windows can also influence which plan becomes active.

How Sessions Receive a Policy

Resource Manager supports mapping sessions through attributes such as database user, service, and application module. Mapping rules and their priorities determine which classification applies. A session has one current consumer group at a time, but its group can change through authorized actions or configured switching rules.

In the first diagram, sessions A and C both connect as APP_USER. Different services or module attributes can place one in OLTP_GROUP and the other in REPORTING_GROUP. A database username alone does not have to define the workload boundary.

This is useful when an application uses a shared account or connection pool. Classification should reflect the work being performed, with reliable application attributes and tested mapping rules. Otherwise, a carefully designed reporting limit may have little effect because the reporting sessions never enter the reporting group.

The top plan must provide OTHER_GROUPS coverage. This is the fallback policy for sessions whose current consumer groups are not represented in that plan. It should not be understood merely as a list of users who have never been assigned a group. Even an existing, valid group can need fallback treatment when a different plan becomes active.

Distinguish the Resource Controls

Relevant directive parameters include ACTIVE_SESS_POOL_P1, PARALLEL_DEGREE_LIMIT_P1, SESSION_PGA_LIMIT, and UTILIZATION_LIMIT. Naming the parameter helps connect the conceptual policy to its later implementation, but its value should come from workload requirements.

For threshold-based policies, a configured action can switch consumer groups, cancel the current SQL call, or terminate a session. These outcomes are not interchangeable. A report that can tolerate slower execution may be suitable for switching; an application that depends on session state may be affected very differently by termination.

Do not treat an I/O threshold that triggers an action as a guaranteed storage-bandwidth allocation. Storage resource management capabilities depend on the platform and configuration. Likewise, limiting DOP does not, by itself, establish every parallel statement queuing behavior.

Multitenant Resource Management

A CDB resource plan allocates resources among PDBs. Within an application PDB, a PDB resource plan allocates the PDB's available resources among consumer groups. These are distinct administrative levels, with related enforcement requirements.

A PDB's CPU allocation percentages should not be read as guaranteed percentages of the entire physical server. The PDB itself participates in the broader allocation among databases and PDBs. Some PDB policies depend on resource management at the CDB level.

PDB resource plans cannot contain subplans or use multilevel scheduling policies. Although the general Resource Manager model includes subplans in supported contexts, the application-PDB examples in this lesson use a single-level policy. A diagram with three rows does not imply a three-level scheduling hierarchy.

Example: An E-Commerce Resource Plan

Suppose web requests and management reports share one application PDB. The illustrated ESALES_PLAN favors web requests during CPU contention, limits reporting concurrency, and provides fallback coverage.

WEBUSER and MANAGER are consumer-group names here. They are not automatically database usernames. Application sessions must be classified into the appropriate groups for these directives to govern their work.

The image's fallback phrase, “sessions not otherwise assigned,” is shorthand. More precisely, the OTHER_GROUPS directive covers sessions whose current consumer groups are not represented in the active plan.

CPU Allocations Are Not Hard Caps

The 70/20/10 values describe the example's level-1 percentage-style allocation under contention. If reporting does not use its allocation, other work can use available CPU, subject to applicable limits. The diagram does not configure a separate utilization ceiling.

Consequently, observing the web workload above 70% at a quiet reporting time does not automatically indicate failure of the policy. Evaluate whether the intended treatment occurs when workloads actually compete. Nor does the 70% allocation guarantee a particular checkout response time.

Concurrency Is Different from Parallelism

The reporting active-session limit permits four sessions with active calls under that directive; additional work can queue. DOP four limits parallelism per operation. Multiplying these numbers does not establish a universal sixteen-process budget, because parallel execution structure and server use require separate consideration.

Web operations are illustrated as serial, with no explicit active-session cap in this directive. That is not a promise of unlimited database capacity. CPU, memory, connection limits, and other policies still constrain the workload.

Percentage-Style Examples and SHARES

The figure deliberately uses MGMT_P1 to show a percentage-style policy. Oracle's 26ai package documentation recommends SHARES instead of MGMT_P* when defining new configurations. Shares express relative weights rather than fixed reservations.

Retain the distinction when moving from a teaching example to implementation. MGMT_P1 remains documented and should not be confused with the older deprecated CPU_P1 parameter. The next lesson can apply the recommended configuration approach while preserving the business objective shown here.

CPU Management Scope in Oracle 26ai

Oracle 26ai introduces RESOURCE_MANAGER_CPU_SCOPE to select between instance-level CPU management and supported server-level inter-instance management:

• INSTANCE_ONLY manages CPU within a database instance.
• SERVER_WIDE uses Linux control groups, or cgroups, to manage CPU across database instances sharing a server on supported Autonomous and Exadata deployments.

SERVER_WIDE is not supported on ordinary non-Exadata Linux systems. The documented requirements include UEK 5 or later. Defaults depend on deployment: INSTANCE_ONLY is the general reference default, while Autonomous is configured with SERVER_WIDE by default.

This parameter is not dynamically modifiable and cannot be changed within a PDB. In RAC, the same value is required across instances. Server-wide describes management on the server, not one global CPU scheduler spanning every cluster node. Consult the platform requirements before treating this feature as an option for a particular installation.

Resource Plans and Routine Maintenance

Maintenance work also competes with application workloads. Tasks such as automatic optimizer statistics collection and advisor activity need opportunities to run without overwhelming business activity. Scheduling and resource allocation address two different questions: when work is eligible to run, and how it competes while running.

Inspect the Actual Windows

Using an administrative session with appropriate catalog access in the intended container, inspect the current configuration:

-- SQL*Plus commands:
SHOW CON_NAME
SHOW PARAMETER resource_manager_plan

SELECT window_name, enabled, active, repeat_interval,
       duration, resource_plan, next_start_date
FROM dba_scheduler_windows
ORDER BY window_name;

SELECT window_group_name, window_name
FROM dba_scheduler_wingroup_members
WHERE window_group_name = 'MAINTENANCE_WINDOW_GROUP'
ORDER BY window_name;

The first commands establish container and plan context. The queries then show window definitions and actual group membership. Review NEXT_START_DATE alongside the calendaring expression to understand when the next opening is expected.

Verify Definitions, Classification, and Runtime Behavior

Use DBA_RSRC_PLANS and DBA_RSRC_PLAN_DIRECTIVES to inspect stored definitions. Use V$RSRC_PLAN for runtime plan information and V$SESSION.RESOURCE_CONSUMER_GROUP to examine current session classification. A plan appearing in a definition view is not proof that it is active.

Verification should follow the policy's intended effect. Confirm the right plan is active in the right container, check that representative sessions enter the expected groups, and then examine queueing and workload results. A reporting session placed in the wrong group can make a valid directive appear ineffective.

For the e-commerce example, assess checkout response times alongside report completion times during representative simultaneous load. If CPU is not the bottleneck, changing CPU weights may have little effect. If reports wait in an active-session queue, that may be the intended result of the concurrency policy rather than an unexplained slowdown.

Oracle Documentation

• Managing Resources with Oracle AI Database Resource Manager
• DBMS_RESOURCE_MANAGER package and directive parameters
• RESOURCE_MANAGER_CPU_SCOPE requirements
• RESOURCE_MANAGER_PLAN and multitenant scope
• Automated maintenance tasks and maintenance windows

Database Resource Manager - Exercise