9
Database Resource Management

This chapter describes how Oracle's Database Resource Manager works to help a database administrator allocate resources to different groups of users. This chapter includes the following topics:

• Introduction to the Database Resource Manager
• How the Database Resource Manager Works
• Resource Plans and Resource Consumer Groups
• Resource Allocation Methods and Resource Plan Directives
• Interaction with Operating-System Resource Control

Introduction to the Database Resource Manager

Traditionally, it has been up to the operating system to regulate resource management among the various applications running on a system, including Oracle databases. Before Oracle8i, there was no way to prioritize one Oracle session over another. The Database Resource Manager gives database administrators more control over resource management decisions, so that resource allocation can be aligned with an enterprise's business objectives.

The Database Resource Manager solves many resource allocation problems that an operating system does not manage so well:

• Excessive overhead. This results from operating system context switching between Oracle server processes when the number of server processes is high.
• Inefficient scheduling. The operating system deschedules Oracle database servers while they hold latches, which is inefficient.
• Inappropriate allocation of resources. The operating system distributes resources equally among all active processes and is unable to prioritize one task over another.
• Inability to manage database-specific resources

With Oracle's Database Resource Manager, a database administrator can:

• Guarantee certain users a minimum amount of processing resources regardless of the load on the system and the number of users
• Distribute available processing resources by allocating percentages of CPU time to different users and applications. In a data warehouse, a higher percentage may be given to ROLAP (relational on-line analytical processing) applications than to batch jobs.
• Limit the degree of parallelism of any operation performed by members of a group of users
• Create an active session pool. This pool consists of a specified maximum number of user sessions allowed to be concurrently active within a group of users. Additional sessions beyond the maximum are queued for execution, but you can specify a timeout period, after which queued jobs terminate.
• Allow automatic switching of users from one group to another group based on administrator-defined criteria. If a member of a particular group of users creates a session that runs for longer than a specified amount of time, that session can be automatically switched to another group of users with different resource requirements.
• Prevent the execution of operations that are estimated to run for a longer time than a predefined limit
• Create an undo pool. This pool consists of the amount of undo space that can be consumed in by a group of users.
• Configure an instance to use a particular method of allocating resources. You can dynamically change the method, for example, from a daytime setup to a nighttime setup, without having to shut down and restart the instance.

It is thus possible to balance one user's resource consumption against that of other users and to partition system resources among tasks of varying importance, to achieve overall enterprise goals.

Database Resource Manager Overview

Resources are allocated to users according to a resource plan specified by the database administrator. The following terms are used in specifying a resource plan:

A resource plan specifies how the resources are to be distributed among various users (resource consumer groups).

Resource consumer groups allow the administrator to group user sessions together by resource requirements. Resource consumer groups are different from user roles; one database user can have different sessions assigned to different resource consumer groups.

Resource allocation methods determine what policy to use when allocating for any particular resource. Resource allocation methods are used by resource plans and resource consumer groups.

Resource plan directives are a means of assigning consumer groups to particular plans and partitioning resources among consumer groups by specifying parameters for each resource allocation method.

The Database Resource Manager also allows for creation of plans within plans, called subplans. Subplans allow further subdivision of resources among different users of an application.

Levels provide a mechanism to specify distribution of unused resources among available users. Up to eight levels of resource allocation can be specified.

Example of a Simple Resource Plan

To illustrate these concepts, take an example of a fictitious company, ABC Inc. ABC sells electronics consumer goods over the Internet. To ensure the best performance for online customers, at least 85% of the CPU resources should be allocated to them. From the remaining resources, 10% should go to users involved in shipping orders and 5% to billing operations.

To configure an Oracle database to allocate resources in such a way, the database administrator creates three resource consumer groups:

• ONLINE for online customers
• SHIPPING for shipping users
• BILLING for billing users

The database administrator then creates a resource plan such as the one in Table 9-1.

Table 9-1 Simple Resource Allocation Plan, ABCUSERS

Consumer Group	CPU Resource Allocation
ONLINE	85%
SHIPPING	10%
BILLING	5%

The plan shown in Table 9-1 specifies that 85% of CPU cycles be allotted to ONLINE group sessions, 10% to those of the SHIPPING group and the remaining 5% to the BILLING group. Although this example describes a very simplistic scenario, the Database Resource Manager provides the database administrator with a powerful mechanism for implementing controlled resource allocation policies within an Oracle database.

How the Database Resource Manager Works

The Database Resource Manager controls the distribution of resources among various sessions by controlling the execution schedule inside the database. By controlling which sessions to run and for how long, the Database Resource Manager can ensure that resource distribution matches the plan directive and hence, the business objectives.

Sessions belonging to consumer groups with higher CPU resource allocation are allowed to use more CPU time than sessions belonging to groups or sub plans with lower allocation.

Resource Control

The basic objective of the Database Resource Manager is to maximize system throughput in a way that conforms to business objectives. Consequently, it does not try to enforce CPU allocation percentage limits as long as consumer groups are getting the resources they need.

Example of Resource Control

Consider the plan in Table 9-1. If this plan is activated on a system with a single CPU, any one of the consumer groups can consume up to 100% of CPU resources, providing other groups do not have enough active sessions to consume their allocation. Therefore, with no active sessions in the SHIPPING and BILLING groups, the ONLINE group sessions can use 100% of CPU resources, even though their allocation limit is set to 85%.

Similarly, if the database is hosted on system with three CPUs and each group has only one active session, each session runs on one of the three CPUs; in this case, resource allocation is actually 33.33%, no matter how allocation limits are set. However, if all the consumer groups have enough active sessions to consume all available CPU resources, then the Database Resource Manager enforces the allocation guidelines specified by the plan directive.

Effectiveness of the Database Resource Manager

The effect of the Database Resource Manager is noticeable only in busy environments with high system utilization.

On multiprocessor systems, processor affinity scheduling at the operating system level can distort CPU allocation on under utilized systems. On a system with multiple CPUs, if one of the CPUs has resources available while others are fully utilized, the operating system attempts to migrate processes from the busy processor's run queue to an under utilized processor. However this does not happen immediately.

On a fully loaded system with enough processes, processor affinity increases performance; this is because invalidating the current CPU cache and loading the new one can be quite expensive. Because most platforms support processor affinity, enough processes must be run to ensure full system utilization.

Database Integration

The Database Resource Manager is fully integrated into the database security system. The supplied PL/SQL package DBMS_RESOURCE_MANAGER lets the database administrator create, update, and delete resource plans and resource consumer groups. The administrator defines a user's default consumer group and what privileges the user has (using the DBMS_RESOURCE_MANAGER_PRIVS package). A user or session can switch resource consumer groups (using DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP) to change execution priority, if the user has been granted the privilege to switch to that consumer group. In addition, users or sessions can be moved from group to group by the database administrator on a production system, dynamically changing the way CPU resources are used.

It is very simple to use the Database Resource Manager in an environment where each application user logs on to the database using a different database username. It is also not very difficult to implement it where applications use generic database login. Because Database Resource Manager actually controls resource utilization at the session level, it is possible to prioritize one session over another, even if both the sessions belong to the same database user. Therefore, it is possible to switch a session to the desired consumer group because of the user's application role, using the DBMS_SESSION.SWITCH_CURRENT_CONSUMER_GROUP procedure, as follows:

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:

Figure 9-1 ABC Resource Allocation Plan, ABCUSERS

Text description of the illustration cncpt146.gif

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.

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.

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

Consumer Group	CPU Resource Allocation
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:

Table 9-3 Top Plan, ABCTOP

Subplan	CPU Resource Allocation
ABCUSERS	75%
ABCMAINT	25%

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

Text description of the illustration cncpt145.gif

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 resources are handed back to the parent plan, which can then distribute it among its subplans.

Resource Allocation Methods and Resource Plan Directives

The Database Resource Manager enables controlled distribution of resources among consumer groups (inter-group), as well within a consumer group (intra-group), using allocation methods and plan directives.

• Plan-level resource allocation methods and directives specify how resources must be distributed among consumer groups.
• Consumer-group methods and directives control resource distribution among sessions belonging to a consumer group.

When scheduling a session for execution, the Database Resource Manager acts as follows:

1. Plan resource allocation guidelines and directives determine which consumer group is to run next.
2. Group-level allocation methods and directives determine which session in the selected group is dispatched to the CPU run queue.

For example, in case of the ABC Company's users plan shown in Table 9-1, plan-level methods and directives specify a resource distribution allowing ONLINE consumer group sessions to be run 85% of the time, while sessions belonging to SHIPPING and BILLING groups get 10% and 5% of CPU time, respectively.

Plan-level directives of ABCUSERS ensure that the ONLINE group is picked up more frequently for execution than the SHIPPING and BILLING groups. However, the ONLINE group usually has several active sessions waiting for execution. Group-level directives determine the order in which these sessions are run.

Resource Plan Directives

How resources are allocated to resource consumer groups is specified in resource allocation directives. The Database Resource Manager provides several means of allocating resources.

CPU Method

This method lets you specify how CPU resources are to be allocated among consumer groups or subplans. The multiple levels of CPU resource allocation (up to eight levels) provide a means of prioritizing CPU use within a plan schema. Level 2 gets resources only after level 1 is unable to use all of its resources. Multiple levels not only provide a way of prioritizing, but they provide a way of explicitly specifying how all primary and leftover resources are to be used.

Active Session Pool with Queuing

You can control the maximum number of concurrently active sessions allowed within a consumer group. This maximum designates the active session pool. When a session cannot be initiated because the pool is full, the session is placed into a queue. When an active session completes, the first session in the queue can then be scheduled for execution. You can also specify a timeout period after which a job in the execution queue (waiting for execution) will timeout, causing it to terminate with an error.

An entire parallel execution session is counted as one active session.

Degree of Parallelism Limit

*Specifying a parallel degree limit lets you control the maximum degree of parallelism for any operation within a consumer group.

Automatic Consumer Group Switching

This method lets you control resources by specifying criteria that, if met, causes the automatic switching of sessions to another consumer group. The criteria used to determine switching are:

• SWITCH_GROUP--specifies the consumer group to which this session is switched if the other (following) criteria are met.
• SWITCH_TIME--specifies the length of time that a session can run before it is switched to another consumer group.
• SWITCH_ESTIMATE--specifies whether Oracle is to use its own estimate of how long an operation will run.

The Database Resource Manager switches a running session to SWITCH_GROUP if the session is active for more than SWITCH_TIME seconds. Active means that the session is running and consuming resources, not waiting idly for user input or waiting for CPU cycles. The session is allowed to continue running, even if the active session pool for the new group is full. Under these conditions a consumer group can have more sessions running than specified by its active session pool. After the session finishes its operation and becomes idle, it is switched back to its original group.

If SWITCH_ESTIMATE is set to true, then the Database Resource Manager uses a predicted estimate of how long the operation will take to complete. If Oracle's predicted estimate is longer than the value specified as SWITCH_TIME, then Oracle switches the session before execution starts. If this parameter is not set, the operation starts normally and only switches groups when other switch criteria are met.

Execution Time Limit

You can specify a maximum execution time allowed for an operation. If Oracle estimates that an operation will run longer than the specified maximum execution time, then the operation is terminated with an error. This error can be trapped and the operation rescheduled.

Undo Pool

You can specify an undo pool for each consumer group. An undo pool controls the amount of total undo that can be generated by a consumer group. When the total undo generated by a consumer group exceeds it's undo limit, the current DML statement generating the redo is terminated. No other members of the consumer group can perform further data manipulation until undo space is freed from the pool.

CPU Resource Allocation

A database administrator can control resource distribution among sessions in competing consumer groups by granting resources at up to eight levels of resource allocation and by specifying how resources are to be distributed among consumer groups at each of these levels.

The users plan shown in Table 9-1 depicts a simple resource distribution scheme using a resource allocation at a single level. This plan can be modified to allocate any unconsumed resources first to administrators (for maintenance operations) and then to any batch jobs. Table 9-4 shows the modified plan:

Table 9-4 Multilevel Users Plan 1

Consumer Group	CPU_LEVEL1	CPU_LEVEL2	CPU_LEVEL3
ONLINE	85%	0%	0%
SHIPPING	10%	0%	0%
BILLING	5%	0%	0%
ADMIN	0%	100%	0%
BATCH	0%	0%	100%

The modified users plan shown in Table 9-4 accomplishes the following:

• CPU_LEVEL1 ensures that at least 85% of CPU resources are available to the sessions belonging to ONLINE, 10% to SHIPPING, and 5% to BILLING consumer groups.
• CPU_LEVEL2 offers to the ADMIN consumer group any resources not consumed by ONLINE, SHIPPING, and BILLING.
• CPU_LEVEL3 makes available to the BATCH consumer group any resources still left.

Multilevel User Plan 1 meets the stated objective by granting resources among the consumer groups at different levels. Sessions belonging to ONLINE, SHIPPING and BILLING groups are always given the first opportunity to run, but their resource consumption is limited to 85%, 10% and 5%, respectively. Any unused resources are made available to Level 2 and are distributed among consumer groups in the proportion of grants made at this level. If unused resources still exist, then they are made available to the next level down.

However, the ADMIN group might have to wait a long time, if all the groups at Level 1 are busy. Similarly, the BATCH group might not get to run any sessions at all, if groups at Level 1 and 2 consume all the resources. Such behavior might not be acceptable in some environments. What is required is a plan that allocates most CPU resources to ONLINE, SHIPPING, and BILLING and also ensures availability of certain minimum CPU cycles to the ADMIN and BATCH groups. The modified multilevel users plan is shown in Table 9-5:

Table 9-5 Multilevel Users Plan 2

Consumer Group	CPU_LEVEL1	CPU_LEVEL2	CPU_LEVEL3
ONLINE	75%	0%	0%
SHIPPING	10%	0%	0%
BILLING	5%	0%	0%
ADMIN	0%	80%	0%
BATCH	0%	20%	0%

The modified multiuser plan shown in Table 9-5 accomplishes the following:

• CPU_LEVEL1 now allocates up to 75% of available CPU time to the ONLINE group, while SHIPPING gets 10% and BILLING gets 5%.
• CPU_LEVEL2 splits the remaining 10% of CPU time between ADMIN and BATCH groups in a ratio of 80 to 20. This ensures that ADMIN group sessions get at least 8% of all available CPU time (80% of 10%); BATCH group sessions get at least 2%.

Multilevel User Plan 2 guarantees a minimum of 10% of the CPU resources to the ADMIN and BATCH groups. These Level 2 groups get more CPU time if the ONLINE, SHIPPING, and BILLING groups do not use all of their allocated resources. With no active sessions for any Level 1 groups, the ADMIN group sessions can run 80% of the time, and BATCH group sessions can run 20% of the time.

CPU Allocation Rules

The multilevel user plans shown in Table 9-4 and Table 9-5 demonstrate that CPU resource allocation using the Emphasis method follows a set of rules. These rules are as follows:

1. Sessions in resource consumer groups with nonzero percentage allocation at Level 1 always get the first opportunity to run.
2. CPU resources are distributed at a given level by specified percentages.
   • If one consumer group does not consume its allocated resources, unused resources are not given to other groups at the same level, but fall through to the next level.
   • After all resource consumer groups at a given level have had a chance to run, any remaining resources fall through to the next level.
3. The sum of percentages at any given level must be less than or equal to 100.
4. After being offered to consumer groups at all levels, any CPU time that is unused, because of either inactivity or quota restrictions, gets recycled. It is offered to consumer groups again starting at Level 1.
5. Any levels that have no plan directives explicitly specified (for example, Level 3 in the example) are implied to have 0% for all subplans or consumer groups.

The Database Resource Manager allocates CPU resources among groups that have active sessions at a given time. It does not use any historical information in deciding which group to run. For example, perhaps the ONLINE consumer group does not have any active sessions for two hours. During this period, its share of resources is available to other consumer groups. Later, when sessions belonging to the ONLINE consumer group are active, they are still allocated only 75% of CPU resources. Consumer groups do not accrue credit for the period in which they did not have any active sessions.

Levels and Priorities

Levels are similar to priorities. Consumer groups at Level 1 are offered resources before those at lower levels are considered. Table 9-6 illustrates one way of setting priorities with Database Resource Manager plan directives:

Table 9-6 Simple Priority Plan

Subplan or Group	CPU_LEVEL1	CPU_LEVEL2	CPU_LEVEL3
High Priority	100%	0%	0%
Medium Priority	0%	100%	0%
Low Priority	0%	0%	100%

In Table 9-6, sessions belonging to the Medium Priority group or subplan are allowed to run only when no active sessions are in the High Priority group or subplan. Similarly, Low Priority sessions get a chance to run only when no active sessions belong to either the High or Medium priority groups or subplans.

However, a plan like the one shown in Table 9-6 can lead to resource starvation. As long as the High Priority group can use 100% of the CPU resources, no session belonging to the Medium or Low priority groups can run at all. In other words, a set of runaway sessions belonging to the High Priority group could completely stall processing of Medium and Low priority group sessions.

If this is not the effect you intend, you can create a plan that ensures allocation of at least minimum resources to all consumer groups by their relative priorities. For example, you might modify the plan in Table 9-6 as follows:

Table 9-7 Modified Priority Plan

Subplan or Group	CPU_LEVEL1	CPU_LEVEL2	CPU_LEVEL3
High Priority	80%	0%	0%
Medium Priority	10%	0%	0%
Low Priority	10%	0%	0%

The modified plan in Table 9-7 ensures that while the High Priority group gets most of the CPU time, other groups are not completely stalled.

Interaction with Operating-System Resource Control

Oracle9i expects a static configuration and allocates internal resources, such as latches, from available resources detected at database startup. The database might not perform optimally and can become unstable if resource configuration changes very frequently. Therefore, operating-system resource control should be used with Oracle databases judiciously, according to the following guidelines:

1. Operating-system resource control should not be used concurrently with the Database Resource Manager, because neither of them are aware of each other's existence. As a result, both the operating system and Database Resource Manager try to control resource allocation in a manner that causes unpredictable behavior and instability of Oracle databases.
   • If you want to control resource distribution within an instance, use the Database Resource Manager and turn off operating-system resource control.
   • If you have multiple instances on a node and you want to distribute resources among them, use operating-system resource control, not the Database Resource Manager.

     Note: Oracle9i does not support the use of both tools simultaneously. Future releases might allow for their interaction on a limited scale.

2. In an Oracle environment, the use of an operating-system resource manager, such as Hewlett Packard's Process Resource Manager (PRM) or Sun's Solaris Resource Manager (SRM), is supported only if all of the following conditions are met:
   • Each instance must be assigned to a dedicated operating-system resource manager group or managed entity.
   • The dedicated entity running all the instance's processes must run at one priority (or resource consumption) level.
   • Process priority management must not be enabled.

     Caution: Please note that management of individual Oracle processes at different priority levels (for example, using the nice statement on UNIX platforms) is not supported. Severe consequences, including instance crashes, can result. You can expect similar undesirable results if operating-system resource control is permitted to manage memory on which an Oracle instance is pinned.

3. If you chose to use operating-system resource control, make sure you turn off the Database Resource Manager. By default, the Database Resource Manager is turned off. If it is not, you can turn it off by issuing the following statement:

   ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='';
   
   

   Also remember to reset this parameter in your initialization parameter file, so that the Database Resource Manager is not activated the next time the database is started up.

Dynamic Reconfiguration

Tools such as Sun's processor sets and dynamic system domains work well with an Oracle database. There is no need to restart an instance if the number of CPUs changes.

Oracle dynamically detects any change in the number of available CPUs and reallocates internal resources. On most platforms, Oracle automatically adjusts the value of CPU_COUNT to the number of available CPUs.