Resource Allocation Methods and Resource Plan Directives

resources are handed back to the parent plan, which can then distribute it among its subplans.

See Also: PL/SQL User’s Guide and Reference for information about using PL/SQL code to create these plans

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.

Database Resource Management 9-11

Resource Allocation Methods and Resource Plan Directives

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

9-12 Oracle9i Database Concepts

Resource Allocation Methods and Resource Plan Directives

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

Database Resource Management 9-13

Resource Allocation Methods and Resource Plan Directives

Table 9–4 Multilevel Users Plan 1

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

9-14 Oracle9i Database Concepts

Resource Allocation Methods and Resource Plan Directives

Table 9–5 Multilevel Users Plan 2

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.

Database Resource Management 9-15

Resource Allocation Methods and Resource Plan Directives

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

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:

9-16 Oracle9i Database Concepts