看完该篇文章你可以了解如下问题：resmgr:cpu quantum等待事件的知识，如何模拟该等待事件，如何避免该事件。
数据库版本：
SYS@zkm> select banner from v$version where rownum=1;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
其实我是想模拟"latch: cache buffers chains"事件，结果模拟出来的事件是"resmgr:cpu quantum"，所以模拟过程涉及到cbc相关知识。其实该事件只需要在资源管理任务期间模拟大量的逻辑读即可，因为逻辑读消耗CPU。
以下是正文：
SYS@zkm> create table scott.test as select 1 id from dual;
Table created.
SYS@zkm> select dbms_rowid.rowid_relative_fno(rowid) file_id,dbms_rowid.rowid_block_number(rowid) block_id from scott.test;
FILE_ID BLOCK_ID
---------- ----------
4 523
SYS@zkm> select rowid from scott.test;
ROWID
------------------
AAAVqcAAEAAAAILAAA
查询表的4号文件523号块的latch地址。
SYS@zkm> select hladdr from x$bh where dbablk=523 and dbarfil=4;
HLADDR
----------------
000000008CD4A658
查询该latch地址所保护的buffer还有哪一些。
SYS@zkm> set linesize 500
SYS@zkm> col what for a50
SYS@zkm> select a.owner||'.'||a.object_name what,dbarfil,dbablk,a.data_object_id,a.object_id from dba_objects a,x$bh where hladdr='000000008CD4A658' and a.data_object_id=x$bh.obj;
WHAT DBARFIL DBABLK DATA_OBJECT_ID OBJECT_ID
-------------------------------------------------- ---------- ---------- -------------- ----------
SYS.VIEW$ 1 73659 69 69
SYS.I_DEPENDENCY1 1 60645 106 106
SYS.C_OBJ#_INTCOL# 1 95582 444 444
SYS.HISTGRM$ 1 95582 444 446
SCOTT.TEST 4 523 88732 88732
以SYS.HISTGRM$为例子，查询1号文件95582块row编号为0的行的rowid。
SYS@zkm> select dbms_rowid.rowid_create(1,444,1,95582,0) from dual;
DBMS_ROWID.ROWID_C
------------------
AAAAG8AABAAAXVeAAA
--或者
SYS@zkm> select rowid from SYS.HISTGRM$ where dbms_rowid.rowid_relative_fno(rowid)=1 and dbms_rowid.rowid_block_number(rowid)=95582 and dbms_rowid.rowid_row_number(rowid)=0;
ROWID
------------------
AAAAG8AABAAAXVeAAA
会话sid:41做如下动作：
SYS@zkm> /
PL/SQL procedure successfully completed.
SYS@zkm> l
1 declare
2 a int;
3 begin
4 for i in 1..10000000 loop
5 select count(*) into a from SYS.HISTGRM$ where rowid='AAAAG8AABAAAXVeAAA';
6 end loop;
7* end;
同时，会话sid:26做如下动作：
SYS@zkm> /
PL/SQL procedure successfully completed.
SYS@zkm> l
1 declare
2 a int;
3 begin
4 for i in 1..10000000 loop
5 select count(*) into a from scott.test where rowid='AAAVqcAAEAAAAILAAA';
6 end loop;
7* end;
同时其他会话的情况：
SYS@zkm> show parameter resource_manager_plan
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
resource_manager_plan string SCHEDULER[0x32D9]:DEFAULT_MAIN
TENANCE_PLAN
SYS@zkm> select sid,event,p1raw,p2raw from v$session where wait_class<>'Idle';
SID EVENT P1RAW P2RAW
---------- ---------------------------------------------------------------- ---------------- ----------------
26 resmgr:cpu quantum 0000000000000003 000000000000325B
41 resmgr:cpu quantum 0000000000000003 000000000000325B
42 SQL*Net message to client 0000000062657100 0000000000000001
可以看到，26和41会话出现“resmgr:cpu quantum”等待。
查询相关资料，11g以后每天固定时间会运行资源管理任务，主要是保证作业期间有cpu资源去保证收集新的优化器状态、为昂贵的SQL找到更好的执行计划、清空AWR等动作。
等待事件 ‘resmgr:cpu quantum’ 是资源管理器用来控制 CPU 分配给进程的标准事件。当会话等待 ‘resmgr:cpu quantum’ 时，会话正在等待分配一个CPU时间额度 。
当启用资源管理器并限制CPU消耗时会发生此等待。为了减少此等待事件的发生，可以增加会话当前消费组的CPU分配，因此下边方法中的第三种不要一味去禁用该任务，要了解瓶颈是否是cpu足够只是被限制了才出现“resmgr:cpu quantum”事件的 。
其实我的虚拟机配置很低，只有1个线程，资源管理任务是否开启对资源的调用时一样的。本来我是想做资源管理任务开启和关闭时候运行时间的比对的，由于我的配置问题看不出查询时间的差别。
只不过在资源管理任务关闭时，"resmgr:cpu quantum"就不存在了，但是top看cpu使用率还是将近100%。
那么如何避免资源管理任务的影响呢？
有三种方法：
1.既然是因为被限制了cpu的数量，那么增加会话当前消费组的cpu分配，使得会话有足够的cpu去运行sql语句。(该方法我没有验证过)
2.可以避开资源管理任务运行的时间段。
比如我的实验环境随时可以设置date -s " 2018-12-11 03:59:00"(周二),随后警告日志就出现(生产勿做此操作，此处只做测试)：
Warning: VKTM detected a time drift.
Time drifts can result in an unexpected behavior such as time-outs. Please check trace file for more details.
Tue Dec 11 03:59:01 2018
Closing scheduler window
Closing Resource Manager plan via scheduler window
Clearing Resource Manager plan via parameter
Tue Dec 11 04:14:12 2018
Clearing Resource Manager plan via parameter
ALTER SYSTEM SET resource_manager_plan='' SCOPE=BOTH;
PS:所以测试时候想要这个资源任务来影响你的话，同样设置时间在相应的时间段内。
比如设置date -s " 2018-12-10 21:59:59",随后警告日志就出现：
Time drifts can result in an unexpected behavior such as time-outs. Please check trace file for more details.
Mon Dec 10 22:00:01 2018
Setting Resource Manager plan SCHEDULER[0x32D9]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Mon Dec 10 22:00:01 2018
Starting background process VKRM
Mon Dec 10 22:00:02 2018
VKRM started with pid=36, OS id=4199
Mon Dec 10 22:00:06 2018
Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"
并且resource_manager_plan会被赋值：
SYS@zkm> show parameter resource_manager_plan
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------------------
resource_manager_plan string SCHEDULER[0x32D9]:DEFAULT_MAINTENANCE_PLAN
资源管理任务运行时间：
周一到周五：22:00到第二天2:00
周六周日：6:00到第二天2:00
详细查询select * from DBA_SCHEDULER_WINDOWS;
3.直接关闭任务。
ALTER system SET resource_manager_plan='';
EXECUTE dbms_scheduler.set_attribute('WEEKNIGHT_WINDOW','RESOURCE_PLAN','');
EXECUTE dbms_scheduler.set_attribute('WEEKEND_WINDOW','RESOURCE_PLAN','');
EXECUTE dbms_scheduler.set_attribute('MONDAY_WINDOW','RESOURCE_PLAN','');
EXECUTE dbms_scheduler.set_attribute('TUESDAY_WINDOW','RESOURCE_PLAN','');
EXECUTE dbms_scheduler.set_attribute('WEDNESDAY_WINDOW','RESOURCE_PLAN','');
EXECUTE dbms_scheduler.set_attribute('THURSDAY_WINDOW','RESOURCE_PLAN','');
EXECUTE dbms_scheduler.set_attribute('FRIDAY_WINDOW','RESOURCE_PLAN','');
EXECUTE dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN','');
EXECUTE dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN','');
或者（需要重启数据库）：
alter system set "_resource_manager_always_on"=FALSE scope=spfile sid='*';
alter system set "_resource_manager_always_off"=TRUE SCOPE=SPFILE sid='*';