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

第1步，創(chuàng)建3個(gè)用戶

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)建三個(gè)使用者組，APPS、REPORTS和MAINTENANCE。一旦創(chuàng)建了使用者組，就能夠把用戶會(huì)話映射到這些使用者組上面。

注：如果使用者組已經(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ī)則，是會(huì)話到使用者組的映射關(guān)系。以下清單為三個(gè)用戶賬戶（srcb、kso、hr）創(chuàng)建了映射關(guān)系，同時(shí)也為toad.exe和plsqldev.exe工具用戶創(chuàng)建一個(gè)映射關(guān)系，這也能體現(xiàn)出會(huì)話屬性映射優(yōu)先級(jí)是如果工作的。

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

?

注：這里還需要一個(gè)主要的步驟，就是賦予這些用戶把他們的會(huì)話切換到映射規(guī)則中指定的用戶者組的權(quán)限。如果不這樣做，將無(wú)法把會(huì)話切換到所需的用戶者組，而會(huì)被分配到默認(rèn)的用戶者組OTHER_GROUPS中。所以，如果發(fā)現(xiàn)用戶會(huì)話進(jìn)入了OTHER_GROUPS，而不是在映射規(guī)則中指定的用戶組組，很有可能是忘了吧switch_consumer_group權(quán)限授予這個(gè)用戶了。請(qǐng)記住，如果映射規(guī)則吧一個(gè)會(huì)話關(guān)聯(lián)到當(dāng)前活動(dòng)計(jì)劃中沒(méi)有定義的使用者組，這種情況也會(huì)發(fā)生。在下面清單中的參數(shù)GRANT_OPTION決定是否允許該用戶賦予其他用戶切換到這個(gè)使用者組的權(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)該確保用戶和開(kāi)發(fā)人員等不會(huì)私自把會(huì)話切換到一個(gè)更高優(yōu)先級(jí)的使用者組。

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

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

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

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

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

一般而言，資源計(jì)劃會(huì)和計(jì)劃指令同時(shí)創(chuàng)建，這是因?yàn)椴荒軇?chuàng)建一個(gè)空的計(jì)劃。資源計(jì)劃必須至少包含一個(gè)和OTHER_GROUPS使用者組對(duì)應(yīng)的計(jì)劃指令。下面的清單創(chuàng)建一個(gè)叫DAYTIME的資源計(jì)劃，并為使用者組APPS、REPORTS、MAINTENANCE定義了各自的計(jì)劃指令，當(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)建夜間計(jì)劃(Night-Time Plan)

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

通過(guò)使用ALTER SYSTEM命令設(shè)置實(shí)例參數(shù)RESOURCE_MANAGER_PLAN來(lái)激活資源計(jì)劃。如果該計(jì)劃不存在，DBRM將不會(huì)被啟用。

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

?

?

可以通過(guò)使用調(diào)度窗口來(lái)自動(dòng)地設(shè)置要激活的資源計(jì)劃，這種方法可以確保基于資源管理的業(yè)務(wù)規(guī)則得以一致地實(shí)施。下面的清單修改了內(nèi)指定調(diào)度窗口WEEKNIGHT_WINDOW，以使其使用上面定義好的NIGHTTIME資源計(jì)劃。這個(gè)調(diào)度窗口從下午6:00(18時(shí))開(kāi)始，直至上午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)建一個(gè)新窗口WEEKDAY_WINDOW，它涵蓋了正常的工作時(shí)間。這個(gè)窗口自動(dòng)地將資源計(jì)劃切換到之前所創(chuàng)建的DAYTIME資源計(jì)劃。這個(gè)窗口從上午7:00（7時(shí)）開(kāi)始，直至下午6:00(總共660分鐘)結(jié)束，接著進(jìn)入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步：測(cè)試資源計(jì)劃(Testing a Resource Plan)

如果資源計(jì)劃DAYTIME開(kāi)始工作，CPU資源將根據(jù)以下公式進(jìn)行分配。注意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%)

測(cè)試大綱：

1.???????關(guān)閉數(shù)據(jù)庫(kù)資源管理器

2.???????使用KSO賬戶啟動(dòng)一個(gè)會(huì)話

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

HR ????-> ?APPS

KSO ???-> ?REPORTS

SRCB ??-> ?MAINTENANCE

SH???? ?-> ?OTHER_GROUPS

4.???????通過(guò)V$SESSION的RESOURCE_CONSUMER_GROUP列檢查使用者組的分配情況。此時(shí)這一列應(yīng)為空，因?yàn)镈BRM還沒(méi)啟用。

5.???????在會(huì)話KSO上啟動(dòng)10046會(huì)話跟蹤。

6.???????在會(huì)話KSO上運(yùn)行一個(gè)CPU密集型查詢。

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

8.???????在負(fù)載測(cè)試運(yùn)行期間，激活DAYTIME資源計(jì)劃。

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

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

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

?

第1步：停用DBRM

使用ALTER SYSTEM命令設(shè)置數(shù)據(jù)庫(kù)實(shí)例參數(shù)RESOURCE_MANAGER_PLAN為’’(空字符串)來(lái)關(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部：啟動(dòng)負(fù)載測(cè)試

在四個(gè)不同的終端窗口上，分別為每個(gè)用戶運(yùn)行一個(gè)shell腳本，這個(gè)腳本會(huì)為它所對(duì)應(yīng)的用戶啟動(dòng)3個(gè)SQL*Plus會(huì)話。每個(gè)會(huì)話啟動(dòng)下面的查詢，它創(chuàng)建出一個(gè)笛卡爾乘積。表skew0有1.5萬(wàn)行（由于我的測(cè)試環(huán)境是Exadata的仿真虛擬機(jī)，性能不是很好，所以不敢用大表做笛卡爾乘積），這個(gè)表連接將會(huì)生成上億的邏輯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萬(wàn)行數(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腳本的拷貝。為每個(gè)用戶，即HR、SRCB、KSO和SH，分別運(yùn)行一次這個(gè)腳本

#!/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個(gè)窗口執(zhí)行上面的腳本：

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

?

?

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

查看會(huì)話到使用者組的映射關(guān)系。當(dāng)沒(méi)有啟用DBRM時(shí)，會(huì)話將不顯示出使用者組的分配情況，這是另一種用來(lái)驗(yàn)證資源管理器沒(méi)有啟用的方法：

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部：對(duì)交互的KSO會(huì)話啟動(dòng)10046會(huì)話跟蹤

對(duì)交互的KSO會(huì)話進(jìn)行10046以便觀察資源管理器的等待事件，這些等待事件能夠只是出DBRM正在對(duì)此會(huì)話的CPU使用進(jìn)行管制。記住，此時(shí)DBRM依然處于非活動(dòng)狀態(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會(huì)話中執(zhí)行一個(gè)查詢

在交互KSO會(huì)話中執(zhí)行一個(gè)CPU密集型的長(zhǎng)查詢，這與步驟3負(fù)載測(cè)試中用到的查詢時(shí)一樣的。

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部：啟動(dòng)資源管理器

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

alter system set resource_manager_plan='DAYTIME';

第9部：檢查使用者組的分配

在此運(yùn)行步驟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.

?

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

第10部：檢查會(huì)話跟蹤文件

不要結(jié)束前面跑的3個(gè)腳本，繼續(xù)在交互KSO用戶會(huì)話中繼續(xù)執(zhí)行那個(gè)長(zhǎng)查詢，再看看此時(shí)的會(huì)話跟蹤文件，并注意DBRM等待事件(resmgr: CPU quantum)的出現(xiàn)。Oracle使用這個(gè)等待事件統(tǒng)計(jì)交互的KSO會(huì)話花在DBRM執(zhí)行隊(duì)列中等待以獲取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í)行長(zhǎng)查詢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用戶會(huì)話只被分配了有限的CPU時(shí)間。在跟蹤記錄里的ela=attribute顯示了這個(gè)會(huì)話花在等待事件resmgr: CPU quantum上的時(shí)間值(單位為μs)。這些等待事件對(duì)應(yīng)的ela時(shí)間的綜合代表著這個(gè)會(huì)話遵循DAYTIME計(jì)劃中所定義好的分配指令而被迫放棄的CPU時(shí)間總量。

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

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

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

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

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

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

?

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

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资源管理器（二）-- 创建和使用数据库资源计划的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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