Resource Plans and Resource Consumer Groups

DECLARE default_group VARCHAR2(30);

BEGIN DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP('desired_consumer_group', 'default_group', false);

END; /

Oracle continues to support user resource limits and profiles used with the Database Resource Manager. While the Database Resource Manager balances different requests for service against each other within the defined resource allocation plan, profiles are used to limits a user's consumption of resources.

The Database Resource Manager and the automatic degree of parallelism (ADOP) feature are integrated. ADOP attempts to optimize system utilization by automatically adjusting the degree of parallelism for parallel query operations based on current system load and the Database Resource Manager degree of parallelism directive.

Performance Overhead

The Database Resource Manager can effectively manage resources with minimal overhead. For systems with hundreds of users, Database Resource Manager can actually improve the performance by reducing context switches and latch contention.

Database Resource Manager does not switch process as often as any operating system’s fair-share scheduler does.

Database Resource Manager runs fewer processes concurrently and never context-switches a process that is holding a latch.

Judicious use of the Database Resource Manager should not lead to any performance degradation. However, the depth or complexity of a resource plan can impede the process of selecting the process to be run; therefore, it may advisable to avoid too deep a resource plan. The more levels a plan schema has, the more work the Database Resource Manager must do to pick a session for execution.

Resource Plans and Resource Consumer Groups

A resource plan is a way to group a set of resource consumer groups together and specify how resources should be divided among them. Consider the example from Table 9–1, which can be diagrammed as follows:

Database Resource Management 9-7

Resource Plans and Resource Consumer Groups

Figure 9–1 ABC Resource Allocation Plan, ABCUSERS

Users

Plan

Activation of a Resource Plan

You can create as many resource plans as you need in a database. However, only one plan can be active at any given time. You can activate a resource plan in one of two ways: persistent and dynamic.

Persistent

Set the value of the RESOURCE_MANAGER_PLAN initialization parameter to the plan you want to activate. For example, to activate ABC’s simple resource plan, abcusers, you would modify the initialization parameter file to include the following line:

RESOURCE_MANAGER_PLAN='ABCUSERS'

When you modify the initialization parameter file, you ensure persistence of the resource plan across database shutdown. However, changes in the initialization parameter file take effect only when the database is restarted. Use this method to set a the default resource plan for the database.

Dynamic

Issue the ALTER SYSTEM SET RESOURCE_MANAGER_PLAN statement. Using the same example, you would issue the following statement:

ALTER SYSTEM SET RESOURCE_MANAGER_PLAN ='ABCUSERS';

When you issue the ALTER SYSTEM SET RESOURCE_MANAGER_PLAN statement, the specified plan is activated immediately, without requiring an instance restart. However, the database reverts to the default setting in the initialization parameter file the next time it is started.

9-8 Oracle9i Database Concepts

Resource Plans and Resource Consumer Groups

For example, using the dynamic method an administrator could create two different plans, for day time and for night time. The day time plan would allocate more resources to online users, while the night time plan (when online users are not very active) would ensure higher allocation to batch jobs. Then the database administrator uses the ALTER SYSTEM statement to toggle back and forth between day and night plans without interrupting database services.

The ALTER SYSTEM SET RESOURCE_MANAGER_PLAN statement is used to dynamically activate, change, or deactivate resource plans.

See Also: Step 3 of "Interaction with Operating-System Resource

Control" on page 9-18

Groups of Resource Plans

You can also use resource plans to group other resource plans. This enables you to partition resources among different kinds of applications. For example, the ABC company might need to reserve certain minimum resources to developers and administrators, so that they can perform critical maintenance operations.

Consider a case where at least 25% of the available CPU cycles must be reserved for sessions belonging to two resource consumer groups: DEVELOPERS and ADMINISTRATORS. These CPU cycles should be allocated between DEVELOPERS and ADMINISTRATORS in a ratio of 60 to 40. To achieve this objective, the database administrator first creates a maintenance plan with following specifications:

Table 9–2 Sample Maintenance Plan, ABCMAINT

DEVELOPERS 60%

ADMINISTRATORS 40%

When activated, the plan shown in Table 9–2 ensures that all available resources are distributed among developers’ and administrators’ sessions in a 60:40 ratio. However, only 25% of all available resources are to be reserved for maintenance; 75% should made available to the abcusers plan. This can be realized by creating a top-level plan with abcusers and abcmaint being its members, as shown in Table 9–3:

Database Resource Management 9-9

Resource Plans and Resource Consumer Groups

Table 9–3 Top Plan, ABCTOP

The users and maintenance groups become subplans of ABCTOP. The resulting plan tree is diagrammed in Figure 9–2.

Figure 9–2 Resource Plan Containing Subplans

Top

A subplan or consumer group can have more than one parent. For example, in the plan shown in Figure 9–2, the consumer group Admin could very well have been part of both the users and maintenance plans. Because multiple parents are allowed, you can preserve plan independence: You do not need to change anything in subplans when you roll them up to a top-level plan.

A plan tree can have as many hierarchical levels as you want. However, as the number of these levels increase, the overhead associated with resource control increases; the determination of which process is to be run next has to be performed at every level that contains subplans. On the other hand, sub plans provide a good way to partition database resources at a high level among multiple applications and then repartition them within an application among various users. If a given group within an application does not consume its allocation, unused resources are made available to other groups within the same application first. If none of the groups in an application can consume all the resources made available to them, the unused

9-10 Oracle9i Database Concepts