（參考?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 createdSQL> 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掉，否則直接創建。

BEGINdbms_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; / BEGINdbms_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; / BEGINdbms_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; / BEGINdbms_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工具用戶創建一個映射關系，這也能體現出會話屬性映射優先級是如果工作的。

BEGINdbms_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決定是否允許該用戶賦予其他用戶切換到這個使用者組的權限。

BEGINdbms_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之前：

BEGINdbms_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。

BEGINdbms_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資源。

BEGINdbms_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分鐘)結束。

BEGINDBMS_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窗口。

BEGINDBMS_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 resourceNAME 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_planNAME TYPE VALUE ------------------------------------ ----------- ------------------------------ resource_manager_plan string

第2部：以KSO用戶登錄

db11@oracle /home/ora11g$ sqlplus kso/ksoSQL*Plus: Release 11.2.0.4.0 Production on Sun Jan 18 17:36:12 2015Copyright (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 optionsSQL>

第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_TSTART WITH 1 INCREMENT BY 1 NOMAXVALUECACHE 20; ---插入1萬行數據 beginfor 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"&&exitecho "" > 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.sqlburn_cpu(){ echo sqlplus -s $user/$passwd @burn_cpu.sql sqlplus -s <<EOF $user/$passwd @burn_cpu.sql exit EOF }JOBS=0 while :; doburn_cpu &JOBS=`jobs | wc -l`while [ "$JOBS" -ge "$parallel" ]; dosleep 10JOBS=`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 pWHERE ((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 16 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 pWHERE ( (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 16 rows selected.

?

這個查詢顯示出一壺會話映射機制工作得很好，所有一壺會話已經根據先前定義好的映射規則切換到各自的使用者組。

第10部：檢查會話跟蹤文件

不要結束前面跑的3個腳本，繼續在交互KSO用戶會話中繼續執行那個長查詢，再看看此時的會話跟蹤文件，并注意DBRM等待事件(resmgr: CPU quantum)的出現。Oracle使用這個等待事件統計交互的KSO會話花在DBRM執行隊列中等待以獲取CPU資源的

grant alter session to kso; ---- 讓kso用戶有權限使用alter sessionSQL> 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, yieldsFROM 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》

?

轉載于:https://www.cnblogs.com/haoxiaoyu/p/4310421.html

總結

以上是生活随笔為你收集整理的Oracle资源管理器（二）-- 创建和使用数据库资源计划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。