【Oracle】如何模拟resmgr:cpu quantum

看完该篇文章你可以了解如下问题：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='*';

其他：关于资源管理任务更详细的说明