You’re familiar with the Database Resource Manager (Resource Manager) from the earlier release. You use the Database Resource Manager to efficiently allocate resources among competing database sessions. Here are the key elements of the Resource Manager:
- Resource Consumer Group is a group of sessions that share similar resource requirements. The Resource Manager allocates resources directly to the resource consumer groups instead of the individual sessions.
- Resource Plan is a container for directives that dictate how the resources are to spread about among the resource consumer groups. At any given time, a certain resource plan is active.
- Resource plan directives dictate which consumers belong to which resource consumer group as well as how the individual resources are to be allocated to that resource consumer group.
There are Database Resource Manager–related enhancements in the following areas:
- Per Session I/O Limits
- New mixed workload resource plan
The CPU_Pn parameters of the CREATE_PLAN_DIRECTIVE procedure are
deprecated now. Instead, use the new MGMT_Pn parameters. Also, in the same
procedure, use the new switch_call parameter instead of the switch_
time_in_call parameter.
Per Session I/O Limits
The Resource Manager provides both manual as well as automatic methods to switch a user’s session to a different resource consumer group. However, whether you change a current resource consumer group manually or automatically, the changes don’t persist and the user’s default resource consumer group remains the same when the user logs in again. In Oracle Database 10g, automatic switching of a session to another resource consumer group could be triggered by a change in a session attribute. The change in session attributes could cause new session-to-consumer group mapping rules to take effect that directed the Resource Manager to move the session to another, typically lower, priority group, based on the dynamic change in the session attribute(s). Oracle Database 11g provides a second way to automatically switch a user’s session from one consumer group to another. Now, automatic session switching can also occur when a session exceeds a CPU or an I/O consumption limit set by the consumer group to which that session is originally assigned. So, you can now specify automatic resource consumer group switching with mapping rules as in the previous release, and also by setting resource limits. If a user is using an excessive amount of CPU, you don’t have to kill that user’s session; you can set up automatic resource group switching so the user is automatically assigned to a resource group with a lower CPU allocation.
Specifying Automatic Switching by Setting Resource Limits
You can now specify limits for CPU and I/O consumption for all sessions in a consumer group when you’re creating a resource plan directive for that consumer group. More specifically, you can dictate what the database can do when a single database call within a session exceeds a CPU or I/O limit. You can choose one of the following actions when a session exceeds a specific resource limit:
- Switch the session to another resource consumer group with a lower resource allocation. In order for this to happen, you must first grant the session owner the “switch” privileges on the new resource consumer group.
- The database can terminate the session.
- The database can abort the SQL statement issuing the call.
The database allows only those sessions that are actually consuming resources to dynamically switch their resource consumer group. A session that’s waiting either for a user’s input or waiting on CPU doesn’t qualify for switching its resource consumer group under the automatic switching feature. Automatic session switching involves the use of the following resource plan directive parameters, which you specify in the CREATE_RESOURCE_PLAN procedure. The examples in the following section illustrate how to use the various parameters.
- switch_group: The consumer group a session is switched to automatically when a switching criterion is satisfied. Here are some things to note about this parameter:
- The default value is NULL.
- If the group name is CANCEL_SQL, the database cancels the current database call.
- If the group name is KILL_SESSION, the session is terminated.
- switch_time: Specifies the duration for which a call can execute before the database switches the session to that specified by the switch_group parameter. The default value is UNLIMITED.
- switch_estimate: If you set this parameter to TRUE, the database will estimate the execution time of each call before the call begins. If the estimated execution time for a call is greater than the limit specified by the switch_time parameter, the database switches the session to the specified group (specified by the switch_group parameter). The default value is FALSE.
- switch_io_megabytes: Specifies the maximum I/O (in megabytes) that a session can transfer in the form of read and write operations before the database takes action. Default is NULL, which means it is unlimited.
- switch_io_reqs: Specifies the maximum number of I/O requests a session can execute before the database takes the action specified by the SWITCH_GROUP parameter. Default is NULL, which means it is unlimited.
- switch_for_call: Indicates whether to switch back to the initial consumer group once the top call has completed (TRUE) or not (FALSE)
Note that the switch_io_megabytes and the switch_io_reqs parameters enable you to specify I/O resource limits when creating a Resource Plan directive. When the database dynamically switches a session’s resource consumer group, the consumer group is allowed to run more sessions than permitted by its active session pool.
The new DBA_HIST_RSRC_PLAN and DBA_HIST_RSRC_CONSUMER_GROUP views have been added to provide a historical view of the data in the V$RSRC_PLAN_HISTORY and V$RSRC_CONS_GROUP_HISTORY views. The V$RSRCMGRMETRIC_HISTORY view displays one hours worth of metrics taken from the V$RSRCMGRMETRIC view.
Examples of Automatic Session Switching
The new I/O parameters mean it is now possible to switch consumer groups, cancel SQL statements or kill sessions based on any combination of elapsed time, I/O requests and I/O in megabytes. The following example switches the resource consumer group from oltp_group to batch_group for the current call within the session if the elapsed time exceeds 120 seconds, the number of I/O requests exceeds 5000 or the amount of I/O requested exceeds 1024M.
BEGIN
DBMS_RESOURCE_MANAGER.clear_pending_area();
DBMS_RESOURCE_MANAGER.create_pending_area();
DBMS_RESOURCE_MANAGER.create_plan('MY_PLAN','');
DBMS_RESOURCE_MANAGER.create_plan_directive(
plan => 'my_plan',
group_or_subplan => 'other_groups',
comment => ' other_groups');
DBMS_RESOURCE_MANAGER.create_plan_directive(
plan => 'my_plan',
group_or_subplan => 'oltp_group',
comment => 'OLTP GROUP',
mgmt_p1 => 70,
switch_group => 'batch_group',
switch_time => 120,
switch_io_reqs => 5000,
switch_io_megabytes => 1024,
max_idle_time => 20,
switch_for_call => TRUE
);
DBMS_RESOURCE_MANAGER.submit_pending_area();
END;
/
The following example kills the session if it consumes more than 4096M of I/O.
BEGIN
DBMS_RESOURCE_MANAGER.create_plan_directive (
plan => 'my_plan',
group_or_subplan => 'oltp_group',
comment => 'OLTP Group',
mgmt_p1 => 70,
switch_group => 'KILL_SESSION',
switch_io_megabytes => 4096);
END;
/
Pre-Created Mixed Workload Resource Plan
Oracle Database 11g provides a new predefined resource plan named MIXED_ WORKLOAD_PLAN. This Oracle-supplied plan gives priority to interactive operations over batch jobs. The plan is disabled by default, and you must enable it in order to assign this plan to user sessions. The MIXED_WORKLOAD_PLAN resource plan consists of the following groups or subplans:
- interactive_group, primarily intended for short online transactions
- batch_group, primarily intended for long batch operations
Following is the way Oracle allocates CPU to the different resource consumer groups in the MIXED_WORKLOAD_PLAN:
- The sys_group gets 100 percent of the CPU at level 1.
- The interactive_group gets preference over the batch_group because its CPU resource allocation is 85 percent of the Level 2 allocation. The other 15 percent of the level 2 CPU allocation is equally distributed among the following subplan and groups:
- ORA$AUTOTASK_SUB_PLAN
- ORA$DIAGNOSTICS
- OTHER_GROUPS
- The batch_group gets only Level 3 allocation of CPU, although it’s 100 percent.
- If a session that is mapped to the interactive_group goes over 60 seconds of execution time, the database automatically switches it to the batch_group. For the interactive_group then, the following automatic consumer resource group switching parameter values hold:
- switch_group: batch-group
- switch_time: 60 seconds
- switch_for_call: true
You can take advantage of the pre-built resource plans by mapping your online application users to the interactive_group consumer group and the batch applications to the batch_group consumer group. You can modify the CPU resource allocations to the batch_group and the interactive_group to suit the needs of your workload.
参考至:《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》
http://www.oracle-base.com/articles/11g/resource-manager-enhancements-11gr1.php
本文原创，转载请注明出处、作者
如有错误，欢迎指正