（参考 http://blog.csdn.net/mrluoe/article/details/7969436 -- 整理并实践通过）
第1步，创建3个用户
SQL> create user srcb identified by srcb; User created. SQL> create user kso identified by kso; User created. SQL> create user hr identified by hr; User created SQL> grant connect,resource to SRCB; Grant succeeded. SQL> grant connect,resource to KSO; Grant succeeded. SQL> grant connect,resource to HR; Grant succeeded.
第2步：创建使用者组(Consumer Groups)
下面的清单创建三个使用者组，APPS、REPORTS和MAINTENANCE。一旦创建了使用者组，就能够把用户会话映射到这些使用者组上面。
注：如果使用者组已经存在，则可先delete掉，否则直接创建。
BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.delete_consumer_group('APPS'); dbms_resource_manager.submit_pending_area(); END; / BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.delete_consumer_group('REPORTS'); dbms_resource_manager.submit_pending_area(); END; / BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.delete_consumer_group('MAINTENANCE'); dbms_resource_manager.submit_pending_area(); END; / BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.create_consumer_group( consumer_group => 'APPS', comment =>'Consumer group for critical OLTP applications'); dbms_resource_manager.create_consumer_group( consumer_group => 'REPORTS', comment =>'Consumer group for long-running reports'); dbms_resource_manager.create_consumer_group( consumer_group => 'MAINTENANCE', comment =>'Consumer group for maintenance jobs'); dbms_resource_manager.validate_pending_area(); dbms_resource_manager.submit_pending_area(); END; /
第3步：创建使用者映射规则(Consumer Group Mapping Rules)
使用者组映射规则，是会话到使用者组的映射关系。以下清单为三个用户账户（srcb、kso、hr）创建了映射关系，同时也为toad.exe和plsqldev.exe工具用户创建一个映射关系，这也能体现出会话属性映射优先级是如果工作的。
BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.set_consumer_group_mapping( attribute => dbms_resource_manager.oracle_user, -- 以Oracle用户添加，其他属性类型如上图所示 value =>'HR', consumer_group => 'APPS'); dbms_resource_manager.set_consumer_group_mapping( attribute => dbms_resource_manager.oracle_user, value =>'KSO', consumer_group => 'REPORTS'); dbms_resource_manager.set_consumer_group_mapping( attribute => dbms_resource_manager.oracle_user, value =>'SRCB', consumer_group => 'MAINTENANCE'); dbms_resource_manager.set_consumer_group_mapping( attribute => dbms_resource_manager.client_program, --- 客户端程序 value =>'toad.exe', consumer_group => 'MAINTENANCE'); dbms_resource_manager.set_consumer_group_mapping( attribute => dbms_resource_manager.client_program, value =>'plsqldev.exe', consumer_group => 'REPORTS'); dbms_resource_manager.submit_pending_area(); END; /
注：这里还需要一个主要的步骤，就是赋予这些用户把他们的会话切换到映射规则中指定的用户者组的权限。如果不这样做，将无法把会话切换到所需的用户者组，而会被分配到默认的用户者组OTHER_GROUPS中。所以，如果发现用户会话进入了OTHER_GROUPS，而不是在映射规则中指定的用户组组，很有可能是忘了吧switch_consumer_group权限授予这个用户了。请记住，如果映射规则吧一个会话关联到当前活动计划中没有定义的使用者组，这种情况也会发生。在下面清单中的参数GRANT_OPTION决定是否允许该用户赋予其他用户切换到这个使用者组的权限。
BEGIN dbms_resource_manager_privs.grant_switch_consumer_group( GRANTEE_NAME => 'KSO', CONSUMER_GROUP => 'REPORTS', GRANT_OPTION => FALSE); dbms_resource_manager_privs.grant_switch_consumer_group( GRANTEE_NAME => 'HR', CONSUMER_GROUP => 'APPS', GRANT_OPTION => FALSE); dbms_resource_manager_privs.grant_switch_consumer_group( GRANTEE_NAME => 'SRCB', CONSUMER_GROUP => 'MAINTENANCE', GRANT_OPTION => FALSE); END; /
提示：如果想减轻工作量，可把switch_consumer_group权限赋予public，但是前提是应该确保用户和开发人员等不会私自把会话切换到一个更高优先级的使用者组。
第4步：设置使用者组映射优先级(Resource Group MappingPriorities)
除了使用会话的username把会话映射到使用者组外，还是有了其他的映射规则，如进程名称等，这就要求设置这些映射规则的优先级。当一个会话与多个规则相匹配时，这就会告诉DBRM应该优先考虑哪个规则。下面的代码吧client_program的优先级放在oracle_user之前：
BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.set_consumer_group_mapping_pri( explicit => 1, client_program => 2, oracle_user => 3, service_module_action => 4, service_module => 5, module_name_action => 6, module_name => 7, service_name => 8, client_os_user => 9, client_machine => 10 ); dbms_resource_manager.submit_pending_area(); END; /
注：使用者映射规则的属性有：
|
会话属性 |
类型 |
描述 |
|
EXPLICIT |
n/a |
这个属性指的是用户通过使用下面任一个存储过程(在DBMS_SESSION包中)明确要求切换到另一个使用者组： l SWITCH_CURRENT_CONSUMER_GROUP l SWITCH_CONSUMER_GROUP_FOR_SESS l SWITCH_CONSUMER_GROUP_FOR_USER 把这个映射属性的级别设置为最高是一种常见的做法。 |
|
ORACLE_USER |
Login |
这是V$SESSION中的USERNAME。登陆时，会话使用这个用户名进行数据库的验证。 |
|
SERVICE_NAME |
Login |
这是用来连接到数据库的数据库服务名，也是V$SESSION的SERVICE_NAME |
|
CLIENT_OS_USER |
Login |
这是用户发起连接机器的操作系统用户账户，也是V$SESSION中的OSUSER |
|
CLIENT_PROGRAM |
Login |
这是最终用户连接到数据库所使用的可执行文件名，例如，toad.exe，资源管理器并不区分其大小写。 |
|
CLIENT_MACHINE |
Login |
这是用户发起连接的机器名，也是V$SESSION的MACHINE列。 |
|
MODULE_NAME |
Runtime |
这是连接到数据库的应用程序设置的模块名。它存储于V$SESSION试图的MODULE列，通过调用DBMS_APPLICATION_INFO.SET_MODULE存储过程进行设置。这是一个可选设置，一些应用程序并不使用它。 |
|
MODULE_NAME_ACTION |
Runtime |
这是模块（MODULE）和动作(ACTION)拼接起来的，格式为module.action。应用程序通过调用下列存储过程进行设置： l DBMS_APPLICATION_INFO.SET_MODULE l DBMS_APPLICATION_INFO.SET_ACTION |
|
SERVICE_MODULE |
Runtime |
这是连接到数据库的服务名和模块名所拼接起来的，格式为service.module |
|
SERVICE_MODULE_ACTION |
Runtime |
此属性是由服务名、模块名和动作名拼接起来的，格式为service.module.action |
|
ORACLE_FUNCTION |
Runtime |
这是一个特殊的属性，有数据库内部维护。当运行RMAN或者Data Pump时会进行相应设置。如执行backup…as backupset时，这个属性会被设置为BACKUP；执行backup…as copy时，会被设置为COPY。当使用Data Pump加载数据到数据库是，这个属性会被设置为DATALOAD。这些属性自动地被映射到内建的如BATCH_GROUP何ETL_GROUP这些使用者组。 |
注：上表中除了ORACLE_USER和SERVICE_NAME的其他属性，可以使用通配符，如_和%，分别对单个核多个字符进行匹配。
第5步：创建资源计划(Resource Plan)和计划指令(Plan Directives)
一般而言，资源计划会和计划指令同时创建，这是因为不能创建一个空的计划。资源计划必须至少包含一个和OTHER_GROUPS使用者组对应的计划指令。下面的清单创建一个叫DAYTIME的资源计划，并为使用者组APPS、REPORTS、MAINTENANCE定义了各自的计划指令，当然还包括使用者组OTHER_GROUPS。
BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.create_plan( plan =>'daytime', comment =>'Resource plan for normal business hours'); dbms_resource_manager.create_plan_directive( plan =>'daytime', group_or_subplan => 'APPS', comment =>'High priority users/applications', mgmt_p1 => 70); dbms_resource_manager.create_plan_directive( plan =>'daytime', group_or_subplan => 'REPORTS', comment =>'Medium priority for daytime reports processing', mgmt_p2 => 50); dbms_resource_manager.create_plan_directive( plan =>'daytime', group_or_subplan => 'MAINTENANCE', comment =>'Low priority for daytime maintenance', mgmt_p3 => 50); dbms_resource_manager.create_plan_directive( plan =>'daytime', group_or_subplan => 'OTHER_GROUPS', comment =>'All other groups not explicitely named in this plan', mgmt_p3 => 50); dbms_resource_manager.validate_pending_area(); dbms_resource_manager.submit_pending_area(); END; /
第6步：创建夜间计划(Night-Time Plan)
非工作时间通常有不同的调度优先级策略，NIGHTTIME计划从APPS组转移一部分CPU资源到MAINTENNANCE组中。下面的清单创建了NIGHTTIME计划，它让维护处理作业拥有比业务应用和报表生成更高的优先级。即便如此，还是为APPS和REPORTS使用者组保留了50%的CPU资源，以确保业务应用程序和报表系统在非高峰时段有足够的CPU资源。
BEGIN dbms_resource_manager.clear_pending_area(); dbms_resource_manager.create_pending_area(); dbms_resource_manager.create_plan( plan =>'nighttime', comment =>'Resource plan for normal business hours'); dbms_resource_manager.create_plan_directive( plan =>'nighttime', group_or_subplan => 'MAINTENANCE', comment =>'Low priority for daytime maintenance', mgmt_p1 => 50); dbms_resource_manager.create_plan_directive( plan =>'nighttime', group_or_subplan => 'APPS', comment =>'High priority users/applications', mgmt_p2 => 50); dbms_resource_manager.create_plan_directive( plan =>'nighttime', group_or_subplan => 'REPORTS', comment =>'Medium priority for daytime reports processing', mgmt_p2 => 50); dbms_resource_manager.create_plan_directive( plan =>'nighttime', group_or_subplan => 'OTHER_GROUPS', comment =>'All other groups not explicitely named in this plan', mgmt_p3 => 100); dbms_resource_manager.validate_pending_area(); dbms_resource_manager.submit_pending_area(); END; /
第7步：激活资源计划(Activate the Resource Plan)
通过使用ALTER SYSTEM命令设置实例参数RESOURCE_MANAGER_PLAN来激活资源计划。如果该计划不存在，DBRM将不会被启用。
ALTER SYSTEM SET resource_manager_plan='DAYTIME' SCOPE=BOTH SID='OSDBSO1'; --- 如果不是rac，则不需要加SID
可以通过使用调度窗口来自动地设置要激活的资源计划，这种方法可以确保基于资源管理的业务规则得以一致地实施。下面的清单修改了内指定调度窗口WEEKNIGHT_WINDOW，以使其使用上面定义好的NIGHTTIME资源计划。这个调度窗口从下午6:00(18时)开始，直至上午7:00(总共780分钟)结束。
BEGIN DBMS_SCHEDULER.SET_ATTRIBUTE( Name =>'"SYS"."WEEKNIGHT_WINDOW"', Attribute =>'RESOURCE_PLAN', Value =>'NIGHTTIME'); DBMS_SCHEDULER.SET_ATTRIBUTE( Name =>'"SYS"."WEEKNIGHT_WINDOW"', attribute =>'REPEAT_INTERVAL', value =>'FREQ=WEEKLY;BYDAY=MON,TUE,WED,THU,FRI;BYHOUR=18;BYMINUTE=00;BYSECOND=0'); DBMS_SCHEDULER.SET_ATTRIBUTE( name=>'"SYS"."WEEKNIGHT_WINDOW"', attribute=>'DURATION', value=>numtodsinterval(780,'minute')); DBMS_SCHEDULER.ENABLE (name=>'"SYS"."WEEKNIGHT_WINDOW"'); END; /
现在再创建一个新窗口WEEKDAY_WINDOW，它涵盖了正常的工作时间。这个窗口自动地将资源计划切换到之前所创建的DAYTIME资源计划。这个窗口从上午7:00（7时）开始，直至下午6:00(总共660分钟)结束，接着进入WEEKNIGHT_WINDOW窗口。
BEGIN DBMS_SCHEDULER.CREATE_WINDOW( window_name => '"WEEKDAY_WINDOW"', resource_plan => 'DAYTIME', start_date => systimestamp at time zone '-6:00', duration => numtodsinterval(660,'minute'), repeat_interval => 'FREQ=WEEKLY;BYDAY=MON,TUE,WED,THU,FRI;BYHOUR=7;BYMINUTE=0;BYSECOND=0', end_date => null, window_priority => 'LOW', Comments => 'Weekday window. Sets the active resource plan to DAYTIME'); DBMS_SCHEDULER.ENABLE (name=>'"SYS"."WEEKDAY_WINDOW"'); END; /
第8步：测试资源计划(Testing a Resource Plan)
如果资源计划DAYTIME开始工作，CPU资源将根据以下公式进行分配。注意70%、15%、7.5%和7.5%反映的是总的CPU分配百分比。
Level 1)APPS = 70% (100% × 70%)
Level 2)REPORTS =15% ((100% - 70%) × 50%)
Level 3)MAINTENANCE = 7.5% (((100% - 70%) × 50%) × 50%)
Level 3)OTHER_GROUPS = 7.5% (((100% - 70%) × 50%) × 50%)
测试大纲：
1. 关闭数据库资源管理器
2. 使用KSO账户启动一个会话
3. 为每个映射到不同使用者组的用户账户启动20个并发的CPU密集型查询，这些用户账户按如下规则映射到各自的使用者组：
HR -> APPS
KSO -> REPORTS
SRCB -> MAINTENANCE
SH -> OTHER_GROUPS
4. 通過V$SESSION的RESOURCE_CONSUMER_GROUP列检查使用者组的分配情况。此时这一列应为空，因为DBRM还没启用。
5. 在会话KSO上启动10046会话跟踪。
6. 在会话KSO上运行一个CPU密集型查询。
7. 使用tail命令实时显示会话跟踪文件，并注意观察等待事件resmgr:CPU quantum的出现。此时应该还没有这个等待事件，因为DBRM还没启用。
8. 在负载测试运行期间，激活DAYTIME资源计划。
9. 再次检查使用者组的分配，现在由于启用了DBRM，会话应该被分配到各自的使用者组中了。
10. 再次检查KSO会话跟踪文件，由于激活了DAYTIME资源计划，应该可以看待resmgr:CPU quantum等待事件。
11. 检查V$RSRC_CONSUMER_GROUP试图中的资源管理指标，观察在整个测试过程中CPU资源是如何分配的，应该可以看到CPU根据资源计划中定义的指令进行了分配。
第1步：停用DBRM
使用ALTER SYSTEM命令设置数据库实例参数RESOURCE_MANAGER_PLAN为’’(空字符串)来关闭DBRM：
SQL> show parameter resource NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_limit boolean FALSE resource_manager_cpu_allocation integer 1 resource_manager_plan string DAYTIME SQL> alter system set resource_manager_plan=''; System altered. SQL> show parameter resource_manager_plan NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_manager_plan string
第2部：以KSO用户登录
db11@oracle /home/ora11g$ sqlplus kso/kso SQL*Plus: Release 11.2.0.4.0 Production on Sun Jan 18 17:36:12 2015 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL>
第3部：启动负载测试
在四个不同的终端窗口上，分别为每个用户运行一个shell脚本，这个脚本会为它所对应的用户启动3个SQL*Plus会话。每个会话启动下面的查询，它创建出一个笛卡尔乘积。表skew0有1.5万行（由于我的测试环境是Exadata的仿真虚拟机，性能不是很好，所以不敢用大表做笛卡尔乘积），这个表连接将会生成上亿的逻辑I/O操作。Skew表的定义，表的列COL1和COL2上有索引：
---在kso用户下创建该表 CREATE TABLE SKEW4 ( PK_COL NUMBER, COL1 NUMBER, COL2 VARCHAR2(30BYTE), COL3 DATE, COL4 VARCHAR2(1BYTE) ); CREATE INDEX SKEW4_COL1 ON SKEW4 (COL1); CREATE INDEX SKEW4_COL2 ON SKEW4 (COL2); SQL> grant select on kso.skew4 to hr; Grant succeeded. SQL> grant select on kso.skew4 to srcb; Grant succeeded. 查询SQL，burn_cpu.sql： select a.col2,sum(a.col1) from kso.skew4 a, kso.skew4 b group by a.col2;
初始化数据
CREATE SEQUENCE SEQ_T START WITH 1 INCREMENT BY 1 NOMAXVALUE CACHE 20; ---插入1万行数据 begin for i in 1 .. 10000 loop insert into skew4 values(seq_t.nextval,i,'hxy'||i,sysdate,'h'); end loop; end; / commit;
下面的shell脚本burn_cpu.sh，它并发3份burn_cpu.sql脚本的拷贝。为每个用户，即HR、SRCB、KSO和SH，分别运行一次这个脚本
#!/bin/bash export user=$1 export passwd=$2 export parallel=$3 [ $# != 3 ]&&echo "usage: burn_cpu.sh username password parallel"&&exit echo "" > burn_cpu.sql echo "select a.col2, sum(a.col1)" >> burn_cpu.sql echo " from kso.skew4 a, " >> burn_cpu.sql echo " kso.skew4 b " >> burn_cpu.sql echo " group by a.col2; " >> burn_cpu.sql echo "exit" >> burn_cpu.sql burn_cpu(){ echo sqlplus -s $user/$passwd @burn_cpu.sql sqlplus -s <<EOF $user/$passwd @burn_cpu.sql exit EOF } JOBS=0 while :; do burn_cpu & JOBS=`jobs | wc -l` while [ "$JOBS" -ge "$parallel" ]; do sleep 10 JOBS=`jobs | wc -l` done done
分别在3个窗口执行上面的脚本：
sh burn_cpu.sh kso kso 3 sh burn_cpu.sh srcb srcb 3 sh burn_cpu.sh hr hr 3
第4部：检查使用者组分配
查看会话到使用者组的映射关系。当没有启用DBRM时，会话将不显示出使用者组的分配情况，这是另一种用来验证资源管理器没有启用的方法：
SQL> SELECT s.username, s.resource_consumer_group,count(*) FROM v$session s, v$process p WHERE ((s.username IS NOT NULL) AND (NVL (s.osuser,'x') <> 'SYSTEM') AND (s.TYPE <>'BACKGROUND') ) AND (p.addr(+) = s.paddr) AND s.username not in ('SYS','DBSNMP') GROUP BY s.username, s.resource_consumer_group ORDER BY s.username; USERNAME RESOURCE_CONSUMER_GROUP COUNT(*) ------------------------------ -------------------------------- ---------- HR 3 KSO 3 SCOTT 1 SRCB 3 SYSMAN 8 SYSTEM 1 6 rows selected.
第5部：对交互的KSO会话启动10046会话跟踪
对交互的KSO会话进行10046以便观察资源管理器的等待事件，这些等待事件能够只是出DBRM正在对此会话的CPU使用进行管制。记住，此时DBRM依然处于非活动状态，因而在跟踪文件中不应该看到任何关于资源管理器的等待事件
alter session set tracefile_identifier='RJOHNSON';
alter session set events'10046 trace name context forever, level 12';
第6部：从KSO会话中执行一个查询
在交互KSO会话中执行一个CPU密集型的长查询，这与步骤3负载测试中用到的查询时一样的。
SQL> select name, value from v$parameter where name = 'user_dump_dest'; NAME VALUE ------------------------------ -------------------------------------------------------------------------------- user_dump_dest /u01/app/oracle11g/diag/rdbms/db11/db11/trace
db11@oracle /home/ora11g$ cd /u01/app/oracle11g/diag/rdbms/db11/db11/trace db11@oracle /u01/app/oracle11g/diag/rdbms/db11/db11/trace$ more db11_ora_14493_RJOHNSON.trc | grep 'resmgr:cpu quantum' db11@oracle /u01/app/oracle11g/diag/rdbms/db11/db11/trace$
第8部：启动资源管理器
现在，任然运行着负载测试，把资源计划设置为定义好的DAYTIME计划来激活DBRM。资源计划被激活时，资源映射规则应该起作用，并把当前正在运行的会话切换到它们各自的使用者组中。
alter system set resource_manager_plan='DAYTIME';
第9部：检查使用者组的分配
在此运行步骤4中的查询，以观察使用者组的分配情况
SELECT s.username, s.resource_consumer_group,count(*) FROM v$session s, v$process p WHERE ( (s.username IS NOT NULL) AND (NVL (s.osuser,'x') <> 'SYSTEM') AND (s.TYPE <>'BACKGROUND') ) AND (p.addr(+) = s.paddr) AND s.username not in ('SYS','DBSNMP') GROUP BY s.username, s.resource_consumer_group ORDER BY s.username; USERNAME RESOURCE_CONSUMER_GROUP COUNT(*) ------------------------------ -------------------------------- ---------- HR APPS 2 KSO REPORTS 4 SCOTT OTHER_GROUPS 1 SRCB MAINTENANCE 3 SYSMAN OTHER_GROUPS 7 SYSTEM OTHER_GROUPS 1 6 rows selected.
这个查询显示出一壶会话映射机制工作得很好，所有一壶会话已经根据先前定义好的映射规则切换到各自的使用者组。
第10部：检查会话跟踪文件
不要结束前面跑的3个脚本，继续在交互KSO用户会话中继续执行那个长查询，再看看此时的会话跟踪文件，并注意DBRM等待事件(resmgr: CPU quantum)的出现。Oracle使用这个等待事件统计交互的KSO会话花在DBRM执行队列中等待以获取CPU资源的
grant alter session to kso; ---- 让kso用户有权限使用alter session SQL> conn kso/kso Connected. SQL> alter session set tracefile_identifier='kso'; Session altered. SQL> alter session set events '10046 trace name context forever,level 12'; Session altered. SQL> select a.col2,sum(a.col1) ----继续执行长查询 2 from kso.skew4 a, 3 kso.skew4 b 4 group by a.col2;
db11@oracle /u01/app/oracle11g/diag/rdbms/db11/db11/trace$ ls -ltr total 1896 ...... -rw-r-----. 1 ora11g oinstall 573793 Jan 19 22:40 db11_dbrm_41953.trc -rw-r-----. 1 ora11g oinstall 1562 Jan 19 22:41 db11_ora_24530_kso.trm -rw-r-----. 1 ora11g oinstall 22153 Jan 19 22:41 db11_ora_24530_kso.trc
产生上面的trace文件
db11@oracle /u01/app/oracle11g/diag/rdbms/db11/db11/trace$ tail -f db11_ora_24530_kso.trc WAIT #139863124233496: nam='resmgr:cpu quantum' ela= 2218634 location=3 consumer group id=91000 =0 obj#=-1 tim=1421678538448342 *** 2015-01-19 22:42:23.075 WAIT #139863124233496: nam='resmgr:cpu quantum' ela= 4524147 location=3 consumer group id=91000 =0 obj#=-1 tim=1421678543075152 *** 2015-01-19 22:42:25.290 WAIT #139863124233496: nam='resmgr:cpu quantum' ela= 2111538 location=3 consumer group id=91000 =0 obj#=-1 tim=1421678545290724 *** 2015-01-19 22:42:30.524 WAIT #139863124233496: nam='resmgr:cpu quantum' ela= 5129696 location=3 consumer group id=91000 =0 obj#=-1 tim=1421678550524420 *** 2015-01-19 22:42:32.939 WAIT #139863124233496: nam='resmgr:cpu quantum' ela= 2310687 location=3 consumer group id=91000 =0 obj#=-1 tim=1421678552939137 *** 2015-01-19 22:42:36.758 WAIT #139863124233496: nam='resmgr:cpu quantum' ela= 3715636 location=3 consumer group id=91000 =0 obj#=-1 tim=1421678556758298 *** 2015-01-19 22:42:42.118 WAIT #139863124233496: nam='resmgr:cpu quantum' ela= 5256776 location=3 consumer group id=91000 =0 obj#=-1 tim=1421678562118166 *** 2015-01-19 22:42:44.732 WAIT #139863124233496: nam='resmgr:cpu quantum' ela= 2509343 location=3 consumer group id=91000 =0 obj#=-1 tim=1421678564732023
如上，KSO用户会话只被分配了有限的CPU时间。在跟踪记录里的ela=attribute显示了这个会话花在等待事件resmgr: CPU quantum上的时间值(单位为μs)。这些等待事件对应的ela时间的综合代表着这个会话遵循DAYTIME计划中所定义好的分配指令而被迫放弃的CPU时间总量。
把3个脚本ctrl +C 结束掉以后，等待立马消失~~~
第11部：检查DBRM指标
最后，通过V$RSRC_CONSUMER_GROUP视图，可以看到Oracle为了监控DBRM所提供的各种指标。当激活一个新的资源计划是，这些计数器被复位。一些指标在整个计划的生存周期里进行累计，而另一些则使用百分比进行显示，代表当前的计数。
注：V_$RSRCMGRMETRIC和V_$RSRCMGRMETRIC_HISTORY视图对于健康DBRM资源分配对数据库会话的影响也是非常有用的。
注：V$RSRC_CONSUMER_GROUP视图中和CPU相关的列
|
列 |
描述 |
|
NAME |
使用者组的名字 |
|
ACTIVE_SESSIONS |
使用者组中的活动会话的个数 |
|
EXECUTION_WAITERS |
等待CPU时间片的活动会话的个数 |
|
REQUESTS |
使用者组的会话所发出请求的累计值 |
|
CPU_WAIT_TIME |
资源管理器引起的使用者组里的会话等CPU的时间累计值。这个等待事件不包括I/O等待、队列(Queue)或闩(Latch)竞争引起的延迟，或者注诸如此类的时间。CPU_WAIT_TIME是使用者组花在resmgr: CPU quantum等待事件上的时间总和 |
|
CPU_WAITS |
由于资源管理，会话被迫等待次数的累计值 |
|
CONSUMED_CPU_TIME |
使用者组的会话所使用的CPU时间总和 |
|
YIELDS |
由于资源管理，使用者组里的会话对其他会话做出CPU让步的次数累计值 |
下面的清单用来显示V$RSRC_CONSUMER_GROUP视图中所收集到的指标，这些指标在确定测试过程中各个使用者组的资源分配策略是非常有价值的。
set line 200 col name format a12 heading "Name" col active_sessions format 999 heading "Active|Sessions" col execution_waiters format 999 heading "Execution|Waiters" col requests format 9,999,999 heading "Requests" col cpu_wait_time format 999,999,999 heading "CPU Wait|Time" col cpu_waits format 99,999,999 heading "CPU|Waits" col consumed_cpu_time format 99,999,999 heading "Consumed|CPU Time" col yields format 9,999,999 heading "Yields" SELECT DECODE(name,'_ORACLE_BACKGROUND_GROUP_','BACKGROUND', name) name, active_sessions, execution_waiters, requests, cpu_wait_time, cpu_waits, consumed_cpu_time, yields FROM v$rsrc_consumer_group ORDER BY cpu_wait_time;
Active Execution CPU Wait CPU Consumed Name Sessions Waiters Requests Time Waits CPU Time Yields ------------ -------- --------- ---------- ------------ ----------- ----------- ---------- BACKGROUND 23 0 33 0 0 0 0 OTHER_GROUPS 3 0 84 63,643 60 6,177 2 APPS 0 0 29 917,908 3,756 378,741 3,708 REPORTS 0 0 10 1,440,990 1,035 141,358 1,020 MAINTENANCE 0 0 3 1,486,729 441 43,895 435
注明：摘录自《深入理解Oracle Exadata》