resmgr:cpu quantum等待事件

resmgr:cpu quantum是Resource Manager特性导致的等待事件，理论上只有版本10g以后才可能出现，同时应当仅在resource manager plan被激活的时间窗口中发生该等待事件。

该等待事件存在的意义是当resource manager控制CPU调度时，需要控制对应进程暂时不使用CPU而进程到内部运行队列中，以保证该进程对应的consumer group(消费组)没有消耗比指定resource manager指令更多的CPU。

此时session就会以”resmgr:cpu quantum”的名义等待在内部运行队列中，wait一段时间以减少对CPU的争用，直到再次获得CPU时该等待事件结束。

需要注意的是虽然国内的绝大多数数据库都不太可能去设置resource plan激活某种资源计划，但是10g开始默认的gather_stats_job自动收集统计信息作业会在每个工作日的晚上22:00-06:00和周六、周日全天打开default_maintance_windows该维护窗口会默认打开一个Oracle预定义的资源计划，在这个窗口中服务进程仍可能进入resmgr:cpu quantum等待事件。

合理的resmgr:cpu quantum是为了实现cpu control的必要代价，但是存在一些BUG可能导致服务进程因为resmgr:cpu quantum而HANG住，并一直等待该事件，这些BUG主要发生在10g的10.2.0.5之前。

AWR TOP 5 EVENT:

Event Waits Time(s) (ms) time Wait Class
———————————– ——— —— —— ———-
resmgr:cpu quantum 1,193,863 96,152 81 67.0 Scheduler
enq: HW – contention 11,789 13,172 1117 9.2 Configurat
enq: US – contention 38,030 11,876 312 8.3 Other
buffer busy waits 19,224 10,762 560 7.5 Concurrenc
enq: TX – index contention 4,862 6,989 1437 4.9 Concurrenc

解决resmgr:cpu quantum等待事件的方法有：

一. 禁用resource plan windows

To disable the DEFAULT_MAINTENANCE_PLAN you can use the below steps as suggested in Note 786346.1

1. Set the current resource manager plan to null (or another plan that is not restrictive):

alter system set resource_manager_plan=” scope=both;

2. Change the active windows to use the null resource manager plan (or other nonrestrictive plan) using:

execute dbms_scheduler.set_attribute(‘WEEKNIGHT_WINDOW’,’RESOURCE_PLAN’,”);
execute dbms_scheduler.set_attribute(‘WEEKEND_WINDOW’,’RESOURCE_PLAN’,”);

3. Then, for each window_name (WINDOW_NAME from DBA_SCHEDULER_WINDOWS), run:

execute dbms_scheduler.set_attribute(‘<window name>’,’RESOURCE_PLAN’,”);

二、打上resource manager必要的补丁

可以参考文档Recommended Patches for CPU Resource Manager (Doc ID 1339803.1)

It applies to Oracle RDBMS Enterprise Edition, versions 10.2.0.4, 10.2.0.5, 11.1.0.7, 11.2.0.1, 11.2.0.2, and 11.2.0.3.

The Oracle Database Resource Manager can be used in many ways, such as managing CPU, I/O, parallel execution, runaway queries, etc. This note addresses issues that are specific to managing CPU.
CPU Resource Manager is enabled when the current Resource Plan contains CPU management directives. These directives are called cpu_p1, cpu_p2, cpu_p3, etc. in releases prior to 11.1. They are called mgmt_p1, mgmt_p2, mgmt_p3, etc. in 11.1 and all subsequent releases.
When using CPU Resource Manager, 3 types of issues are seen:

(1) Excessive throttling, resulting in under-utilization of the CPU.
(2) Poor conformance to the Resource Plan.
(3) Crashes or internal errors.

Below is a list of the most critical, known bugs for CPU Resource Manager. These bug fixes are recommended for all customers that are either evaluating or using CPU Resource Manager.

For other recommended bug fixes, monitoring scripts, and other tips for Resource Manager, see the master MOS Document 1339769.1.

================================================

/

STATUS	 SQL_ID
-------- -------------
EVENT
----------------------------------------------------------------
ACTIVE
resmgr:cpu quantum

SQL> /

STATUS	 SQL_ID
-------- -------------
EVENT
----------------------------------------------------------------
ACTIVE
resmgr:cpu quantum

SQL> oradebug short_stack;
ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1782<-sspuser()+112<-__restore_rt()<-pfrrun_no_tool()+63<-pfrrun()+1030<-plsql_run()+774<-peicnt()+301<-kkxuexe()+1082<-kkxmpsexe()+1034<-kgmexwi()+631<-kgmexec()+1059<-evapls()+1071<-evaopn2()+904<-qerocImageIterStart()+400<-qerocStart()+443<-selexe0()+1088<-opiexe()+14771<-opipls()+3103<-opiodr()+1149<-__PGOSF141_rpidrus()+211<-skgmstack()+148<-rpiswu2()+617<-rpidrv()+1347<-psddr0()+464<-psdnal()+462<-pevm_OPND()+142<-pfrinstr_OPND()+53<-pfrrun_no_tool()+63<-pfrrun()+1030<-plsql_run()+774<-peidxr_run()+258<-peidxexe()+79<-kkxdexe()+609<-kkxmpexe()+241<-kgmexwi()+631<-kgmexec()+1059<-evapls()+1071<-evaopn2()+904<-qerocImageIterStart()+400<-qerocStart()+443<-qersoStart()+1581<-selexe0()+1088<-opiexe()+14771<-kpoal8()+2299<-opiodr()+1149<-ttcpip()+1251<-opitsk()+1633<-opiino()+958<-opiodr()+1149<-opidrv()+570<-sou2o()+103<-opimai_real()+133<-ssthrdmain()+214<-main()+201<-__libc_start_main()+244 oradebug short_stack;
ksedsts()+461<-ksdxfstk()+32<-ksdxcb()+1782<-sspuser()+112<-__restore_rt()<-__PGOSF346_pfrinstr_RELBRNCH()+62<-pfrrun_no_tool()+63<-pfrrun()+1030<-plsql_run()+774<-peicnt()+301<-kkxuexe()+1082<-kkxmpsexe()+1034<-kgmexwi()+631<-kgmexec()+1059<-evapls()+1071<-evaopn2()+904<-qerocImageIterStart()+400<-qerocStart()+443<-selexe0()+1088<-opiexe()+14771<-opipls()+3103<-opiodr()+1149<-__PGOSF141_rpidrus()+211<-skgmstack()+148<-rpiswu2()+617<-rpidrv()+1347<-psddr0()+464<-psdnal()+462<-pevm_OPND()+142<-pfrinstr_OPND()+53<-pfrrun_no_tool()+63<-pfrrun()+1030<-plsql_run()+774<-peidxr_run()+258<-peidxexe()+79<-kkxdexe()+609<-kkxmpexe()+241<-kgmexwi()+631<-kgmexec()+1059<-evapls()+1071<-evaopn2()+904<-qerocImageIterStart()+400<-qerocStart()+443<-qersoStart()+1581<-selexe0()+1088<-opiexe()+14771<-kpoal8()+2299<-opiodr()+1149<-ttcpip()+1251<-opitsk()+1633<-opiino()+958<-opiodr()+1149<-opidrv()+570<-sou2o()+103<-opimai_real()+133<-ssthrdmain()+214<-main()+201<-__libc_start_main()+244