（參考?http://blog.csdn.net/mrluoe/article/details/7969436 -- 整理并實踐通過）

第1步，創(chuàng)建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步：創(chuàng)建使用者組(Consumer Groups)

下面的清單創(chuàng)建三個使用者組，APPS、REPORTS和MAINTENANCE。一旦創(chuàng)建了使用者組，就能夠把用戶會話映射到這些使用者組上面。

注：如果使用者組已經(jīng)存在，則可先delete掉，否則直接創(chuàng)建。

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步：創(chuàng)建使用者映射規(guī)則(Consumer Group Mapping Rules)

使用者組映射規(guī)則，是會話到使用者組的映射關(guān)系。以下清單為三個用戶賬戶（srcb、kso、hr）創(chuàng)建了映射關(guān)系，同時也為toad.exe和plsqldev.exe工具用戶創(chuàng)建一個映射關(guān)系，這也能體現(xiàn)出會話屬性映射優(yōu)先級是如果工作的。

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, -- 以O(shè)racle用戶添加，其他屬性類型如上圖所示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; /

?

注：這里還需要一個主要的步驟，就是賦予這些用戶把他們的會話切換到映射規(guī)則中指定的用戶者組的權(quán)限。如果不這樣做，將無法把會話切換到所需的用戶者組，而會被分配到默認的用戶者組OTHER_GROUPS中。所以，如果發(fā)現(xiàn)用戶會話進入了OTHER_GROUPS，而不是在映射規(guī)則中指定的用戶組組，很有可能是忘了吧switch_consumer_group權(quán)限授予這個用戶了。請記住，如果映射規(guī)則吧一個會話關(guān)聯(lián)到當(dāng)前活動計劃中沒有定義的使用者組，這種情況也會發(fā)生。在下面清單中的參數(shù)GRANT_OPTION決定是否允許該用戶賦予其他用戶切換到這個使用者組的權(quán)限。

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權(quán)限賦予public，但是前提是應(yīng)該確保用戶和開發(fā)人員等不會私自把會話切換到一個更高優(yōu)先級的使用者組。

第4步：設(shè)置使用者組映射優(yōu)先級(Resource Group MappingPriorities)

除了使用會話的username把會話映射到使用者組外，還是有了其他的映射規(guī)則，如進程名稱等，這就要求設(shè)置這些映射規(guī)則的優(yōu)先級。當(dāng)一個會話與多個規(guī)則相匹配時，這就會告訴DBRM應(yīng)該優(yōu)先考慮哪個規(guī)則。下面的代碼吧client_program的優(yōu)先級放在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; /

注：使用者映射規(guī)則的屬性有：

會話屬性	類型	描述
EXPLICIT	n/a	這個屬性指的是用戶通過使用下面任一個存儲過程(在DBMS_SESSION包中)明確要求切換到另一個使用者組： l? SWITCH_CURRENT_CONSUMER_GROUP l? SWITCH_CONSUMER_GROUP_FOR_SESS l? SWITCH_CONSUMER_GROUP_FOR_USER 把這個映射屬性的級別設(shè)置為最高是一種常見的做法。
ORACLE_USER	Login	這是V$SESSION中的USERNAME。登陸時，會話使用這個用戶名進行數(shù)據(jù)庫的驗證。
SERVICE_NAME	Login	這是用來連接到數(shù)據(jù)庫的數(shù)據(jù)庫服務(wù)名，也是V$SESSION的SERVICE_NAME
CLIENT_OS_USER	Login	這是用戶發(fā)起連接機器的操作系統(tǒng)用戶賬戶，也是V$SESSION中的OSUSER
CLIENT_PROGRAM	Login	這是最終用戶連接到數(shù)據(jù)庫所使用的可執(zhí)行文件名，例如，toad.exe，資源管理器并不區(qū)分其大小寫。
CLIENT_MACHINE	Login	這是用戶發(fā)起連接的機器名，也是V$SESSION的MACHINE列。
MODULE_NAME	Runtime	這是連接到數(shù)據(jù)庫的應(yīng)用程序設(shè)置的模塊名。它存儲于V$SESSION試圖的MODULE列，通過調(diào)用DBMS_APPLICATION_INFO.SET_MODULE存儲過程進行設(shè)置。這是一個可選設(shè)置，一些應(yīng)用程序并不使用它。
MODULE_NAME_ACTION	Runtime	這是模塊（MODULE）和動作(ACTION)拼接起來的，格式為module.action。應(yīng)用程序通過調(diào)用下列存儲過程進行設(shè)置： l? DBMS_APPLICATION_INFO.SET_MODULE l? DBMS_APPLICATION_INFO.SET_ACTION
SERVICE_MODULE	Runtime	這是連接到數(shù)據(jù)庫的服務(wù)名和模塊名所拼接起來的，格式為service.module
SERVICE_MODULE_ACTION	Runtime	此屬性是由服務(wù)名、模塊名和動作名拼接起來的，格式為service.module.action
ORACLE_FUNCTION	Runtime	這是一個特殊的屬性，有數(shù)據(jù)庫內(nèi)部維護。當(dāng)運行RMAN或者Data Pump時會進行相應(yīng)設(shè)置。如執(zhí)行backup…as backupset時，這個屬性會被設(shè)置為BACKUP；執(zhí)行backup…as copy時，會被設(shè)置為COPY。當(dāng)使用Data Pump加載數(shù)據(jù)到數(shù)據(jù)庫是，這個屬性會被設(shè)置為DATALOAD。這些屬性自動地被映射到內(nèi)建的如BATCH_GROUP何ETL_GROUP這些使用者組。

注：上表中除了ORACLE_USER和SERVICE_NAME的其他屬性，可以使用通配符，如_和%，分別對單個核多個字符進行匹配。

第5步：創(chuàng)建資源計劃(Resource Plan)和計劃指令(Plan Directives)

一般而言，資源計劃會和計劃指令同時創(chuàng)建，這是因為不能創(chuàng)建一個空的計劃。資源計劃必須至少包含一個和OTHER_GROUPS使用者組對應(yīng)的計劃指令。下面的清單創(chuàng)建一個叫DAYTIME的資源計劃，并為使用者組APPS、REPORTS、MAINTENANCE定義了各自的計劃指令，當(dāng)然還包括使用者組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步：創(chuàng)建夜間計劃(Night-Time Plan)

非工作時間通常有不同的調(diào)度優(yōu)先級策略，NIGHTTIME計劃從APPS組轉(zhuǎn)移一部分CPU資源到MAINTENNANCE組中。下面的清單創(chuàng)建了NIGHTTIME計劃，它讓維護處理作業(yè)擁有比業(yè)務(wù)應(yīng)用和報表生成更高的優(yōu)先級。即便如此，還是為APPS和REPORTS使用者組保留了50%的CPU資源，以確保業(yè)務(wù)應(yīng)用程序和報表系統(tǒng)在非高峰時段有足夠的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命令設(shè)置實例參數(shù)RESOURCE_MANAGER_PLAN來激活資源計劃。如果該計劃不存在，DBRM將不會被啟用。

ALTER SYSTEM SET resource_manager_plan='DAYTIME' SCOPE=BOTH SID='OSDBSO1'; --- 如果不是rac，則不需要加SID

?

?

可以通過使用調(diào)度窗口來自動地設(shè)置要激活的資源計劃，這種方法可以確保基于資源管理的業(yè)務(wù)規(guī)則得以一致地實施。下面的清單修改了內(nèi)指定調(diào)度窗口WEEKNIGHT_WINDOW，以使其使用上面定義好的NIGHTTIME資源計劃。這個調(diào)度窗口從下午6:00(18時)開始，直至上午7:00(總共780分鐘)結(jié)束。

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; /

現(xiàn)在再創(chuàng)建一個新窗口WEEKDAY_WINDOW，它涵蓋了正常的工作時間。這個窗口自動地將資源計劃切換到之前所創(chuàng)建的DAYTIME資源計劃。這個窗口從上午7:00（7時）開始，直至下午6:00(總共660分鐘)結(jié)束，接著進入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資源將根據(jù)以下公式進行分配。注意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.???????關(guān)閉數(shù)據(jù)庫資源管理器

2.???????使用KSO賬戶啟動一個會話

3.???????為每個映射到不同使用者組的用戶賬戶啟動20個并發(fā)的CPU密集型查詢，這些用戶賬戶按如下規(guī)則映射到各自的使用者組：

HR ????-> ?APPS

KSO ???-> ?REPORTS

SRCB ??-> ?MAINTENANCE

SH???? ?-> ?OTHER_GROUPS

4.???????通過V$SESSION的RESOURCE_CONSUMER_GROUP列檢查使用者組的分配情況。此時這一列應(yīng)為空，因為DBRM還沒啟用。

5.???????在會話KSO上啟動10046會話跟蹤。

6.???????在會話KSO上運行一個CPU密集型查詢。

7.???????使用tail命令實時顯示會話跟蹤文件，并注意觀察等待事件resmgr:CPU quantum的出現(xiàn)。此時應(yīng)該還沒有這個等待事件，因為DBRM還沒啟用。

8.???????在負載測試運行期間，激活DAYTIME資源計劃。

9.???????再次檢查使用者組的分配，現(xiàn)在由于啟用了DBRM，會話應(yīng)該被分配到各自的使用者組中了。

10.???再次檢查KSO會話跟蹤文件，由于激活了DAYTIME資源計劃，應(yīng)該可以看待resmgr:CPU quantum等待事件。

11.???檢查V$RSRC_CONSUMER_GROUP試圖中的資源管理指標(biāo)，觀察在整個測試過程中CPU資源是如何分配的，應(yīng)該可以看到CPU根據(jù)資源計劃中定義的指令進行了分配。

?

第1步：停用DBRM

使用ALTER SYSTEM命令設(shè)置數(shù)據(jù)庫實例參數(shù)RESOURCE_MANAGER_PLAN為’’(空字符串)來關(guān)閉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腳本，這個腳本會為它所對應(yīng)的用戶啟動3個SQL*Plus會話。每個會話啟動下面的查詢，它創(chuàng)建出一個笛卡爾乘積。表skew0有1.5萬行（由于我的測試環(huán)境是Exadata的仿真虛擬機，性能不是很好，所以不敢用大表做笛卡爾乘積），這個表連接將會生成上億的邏輯I/O操作。Skew表的定義，表的列COL1和COL2上有索引：

---在kso用戶下創(chuàng)建該表 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;

?

初始化數(shù)據(jù)

CREATE SEQUENCE SEQ_TSTART WITH 1 INCREMENT BY 1 NOMAXVALUECACHE 20; ---插入1萬行數(shù)據(jù) 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，它并發(fā)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個窗口執(zhí)行上面的腳本：

sh burn_cpu.sh kso kso 3 sh burn_cpu.sh srcb srcb 3 sh burn_cpu.sh hr hr 3

?

?

第4部：檢查使用者組分配

查看會話到使用者組的映射關(guān)系。當(dāng)沒有啟用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依然處于非活動狀態(tài)，因而在跟蹤文件中不應(yīng)該看到任何關(guān)于資源管理器的等待事件

alter session set tracefile_identifier='RJOHNSON'; alter session set events'10046 trace name context forever, level 12';

第6部：從KSO會話中執(zhí)行一個查詢

在交互KSO會話中執(zhí)行一個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部：啟動資源管理器

現(xiàn)在，任然運行著負載測試，把資源計劃設(shè)置為定義好的DAYTIME計劃來激活DBRM。資源計劃被激活時，資源映射規(guī)則應(yīng)該起作用，并把當(dāng)前正在運行的會話切換到它們各自的使用者組中。

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.

?

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

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

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

grant alter session to kso; ---- 讓kso用戶有權(quán)限使用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) ----繼續(xù)執(zhí)行長查詢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

?

?產(chǎn)生上面的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)。這些等待事件對應(yīng)的ela時間的綜合代表著這個會話遵循DAYTIME計劃中所定義好的分配指令而被迫放棄的CPU時間總量。

把3個腳本ctrl +C 結(jié)束掉以后，等待立馬消失~~~

第11部：檢查DBRM指標(biāo)

最后，通過V$RSRC_CONSUMER_GROUP視圖，可以看到Oracle為了監(jiān)控DBRM所提供的各種指標(biāo)。當(dāng)激活一個新的資源計劃是，這些計數(shù)器被復(fù)位。一些指標(biāo)在整個計劃的生存周期里進行累計，而另一些則使用百分比進行顯示，代表當(dāng)前的計數(shù)。

注：V_$RSRCMGRMETRIC和V_$RSRCMGRMETRIC_HISTORY視圖對于健康DBRM資源分配對數(shù)據(jù)庫會話的影響也是非常有用的。

注：V$RSRC_CONSUMER_GROUP視圖中和CPU相關(guān)的列

列	描述
NAME	使用者組的名字
ACTIVE_SESSIONS	使用者組中的活動會話的個數(shù)
EXECUTION_WAITERS	等待CPU時間片的活動會話的個數(shù)
REQUESTS	使用者組的會話所發(fā)出請求的累計值
CPU_WAIT_TIME	資源管理器引起的使用者組里的會話等CPU的時間累計值。這個等待事件不包括I/O等待、隊列(Queue)或閂(Latch)競爭引起的延遲，或者注諸如此類的時間。CPU_WAIT_TIME是使用者組花在resmgr: CPU quantum等待事件上的時間總和
CPU_WAITS	由于資源管理，會話被迫等待次數(shù)的累計值
CONSUMED_CPU_TIME	使用者組的會話所使用的CPU時間總和
YIELDS	由于資源管理，使用者組里的會話對其他會話做出CPU讓步的次數(shù)累計值

?

下面的清單用來顯示V$RSRC_CONSUMER_GROUP視圖中所收集到的指標(biāo)，這些指標(biāo)在確定測試過程中各個使用者組的資源分配策略是非常有價值的。

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》

?

轉(zhuǎn)載于:https://www.cnblogs.com/haoxiaoyu/p/4310421.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。