創建和使用數據庫資源計劃
第1步：創建使用者組(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; / |
第2步：創建使用者映射規則(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, 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，但是前提是應該確保用戶和開發人員等不會私自把會話切換到一個更高優先級的使用者組。
第3步：設置使用者組映射優先級(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的其他屬性，可以使用通配符，如_和%，分別對單個核多個字符進行匹配。
第4步：創建資源計劃(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; /
|
第5步：創建夜間計劃(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; / |
第6步：激活資源計劃(Activate the Resource Plan)
通過使用ALTERSYSTEM命令設置實例參數RESOURCE_MANAGER_PLAN來激活資源計劃。如果該計劃不存在，DBRM將不會被啓用。
ALTERSYSTEMSETresource_manager_plan='DAYTIME'SCOPE=BOTH SID='OSDBSO1';
可以通過使用調度窗口來自動地設置要激活的資源計劃，這種方法可以確保基於資源管理的業務規則得以一致地實施。下面的清單修改了內指定調度窗口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 attimezone'-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; / |
第7步：測試資源計劃(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：
altersystemset resource_manager_plan='';
第2部：以KSO用戶登錄
[oracle@dmdb01exasql]$ sqlplus /nolog
SQL*Plus: Release11.2.0.1.0 Production on Tue Sep 11 16:17:11 2012
Copyright (c)1982, 2009, Oracle. All rights reserved.
16:17:11 @>conn kso/kso
Connected.
16:17:15osdbso1@KSO>
第3部：啓動負載測試
在四個不同的終端窗口上，分別爲每個用戶運行一個shell腳本，這個腳本會爲它所對應的用戶啓動3個SQL*Plus會話。每個會話啓動下面的查詢，它創建出一個笛卡爾乘積。表skew0有1.5萬行（由於我的測試環境是Exadata的仿真虛擬機，性能不是很好，所以不敢用大表做笛卡爾乘積），這個表連接將會生成上億的邏輯I/O操作。Skew表的定義，表的列COL1和COL2上有索引：
|
CREATETABLE SKEW4 ( PK_COL NUMBER, COL1 NUMBER, COL2 VARCHAR2(30BYTE), COL3 DATE, COL4 VARCHAR2(1BYTE) );
CREATEINDEX SKEW4_COL1ON SKEW4 (COL1); CREATEINDEX SKEW4_COL2ON SKEW4 (COL2);
查詢SQL，burn_cpu.sql： select a.col2,sum(a.col1) from kso.skew4 a, kso.skew4 b groupby a.col2; |
下面的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 |
分別在4個窗口執行上面的腳本：
sh burn_cpu.sh ksokso 3
sh burn_cpu.shsrcb srcb 3
sh burn_cpu.sh shsh 3
sh burn_cpu.sh hrhr 3
top命令的輸出結果顯示有20個正在運行的進程，用戶CPU時間爲90%：
第4部：檢查使用者組分配
查看會話到使用者組的映射關係。當沒有啓用DBRM時，會話將不顯示出使用者組的分配情況，這是另一種用來驗證資源管理器沒有啓用的方法：
|
osdbso1@SYS> SELECT s.username, s.resource_consumer_group,count(*) FROM v$session s, v$process p WHERE ( (s.usernameISNOTNULL) AND (NVL (s.osuser,'x') <> 'SYSTEM') AND (s.TYPE <>'BACKGROUND') ) AND (p.addr(+) = s.paddr) AND s.usernamenotin ('SYS','DBSNMP') GROUPBY s.username, s.resource_consumer_group ORDERBY s.username; USERNAME RESOURCE_CONSUMER_GROUP COUNT(*) ------------------------------ -------------------------------- ---------- HR 3 KSO 9 SH 15 SRCB 11 SYSMAN 3 |
第5部：對交互的KSO會話啓動10046會話跟蹤
對交互的KSO會話進行10046以便觀察資源管理器的等待事件，這些等待事件能夠只是出DBRM正在對此會話的CPU使用進行管制。記住，此時DBRM依然處於非活動狀態，因而在跟蹤文件中不應該看到任何關於資源管理器的等待事件。
18:12:47osdbso1@KSO> altersessionset tracefile_identifier='RJOHNSON';
18:12:55osdbso1@KSO> altersessionsetevents'10046 trace namecontext forever, level 12';
第6部：從KSO會話中執行一個查詢
在交互KSO會話中執行一個CPU密集型的長查詢，這與步驟3負載測試中用到的查詢時一樣的。
select a.col2,sum(a.col1)
fromkso.skew4 a,
kso.skew4 b
groupby a.col2;
第7部：檢查會話跟蹤文件
由於還沒有激活資源計劃，此時在跟蹤文件中是看不到任何的資源管理器等待事件的：
[oracle@dmdb01 ~]$cd /soft/oracle/diag/rdbms/osdbso/osdbso1/trace
[oracle@dmdb01trace]$ tail -5000f osdbso1_ora_17711_KSO.trc | grep 'resmgr:cpu quantum'
第8部：啓動資源管理器
現在，任然運行着負載測試，把資源計劃設置爲定義好的DAYTIME計劃來激活DBRM。資源計劃被激活時，資源映射規則應該起作用，並把當前正在運行的會話切換到它們各自的使用者組中。
18:21:09osdbso1@SYS> altersystemsetresource_manager_plan='DAYTIME';
第9部：檢查使用者組的分配
在此運行步驟4中的查詢，以觀察使用者組的分配情況：
|
osdbso1@SYS> SELECT s.username, s.resource_consumer_group,count(*) FROM v$session s, v$process p WHERE ( (s.usernameISNOTNULL) AND (NVL (s.osuser,'x') <> 'SYSTEM') AND (s.TYPE <>'BACKGROUND') ) AND (p.addr(+) = s.paddr) AND s.usernamenotin ('SYS','DBSNMP') GROUPBY s.username, s.resource_consumer_group ORDERBY s.username; USERNAME RESOURCE_CONSUMER_GROUP COUNT(*) ------------------------------ -------------------------------- ---------- HR APPS 3 KSO OTHER_GROUPS 8 KSO REPORTS 10 SH OTHER_GROUPS 7 SRCB MAINTENANCE 3 SRCB OTHER_GROUPS 8 SYSMAN OTHER_GROUPS 3 |
這個查詢顯示出一壺會話映射機制工作得很好，所有一壺會話已經根據先前定義好的映射規則切換到各自的使用者組。
第10部：檢查會話跟蹤文件
在交互KSO用戶會話中繼續執行那個長查詢，再看看此時的會話跟蹤文件，並注意DBRM等待事件(resmgr: CPU quantum)的出現。Oracle使用這個等待事件統計交互的KSO會話花在DBRM執行隊列中等待以獲取CPU資源的時間。
|
[oracle@dmdb01 trace]$ tail -5000f osdbso1_ora_17711_KSO.trc | grep 'resmgr:cpu quantum' WAIT #3: nam='resmgr:cpu quantum' ela= 4797 location=3 =0 =0 obj#=13484 tim=1347358904536796 WAIT #3: nam='resmgr:cpu quantum' ela= 104092 location=3 =0 =0 obj#=13484 tim=1347358904855747 WAIT #3: nam='resmgr:cpu quantum' ela= 867797 location=3 =0 =0 obj#=13484 tim=1347358905831409 WAIT #3: nam='resmgr:cpu quantum' ela= 660284 location=3 =0 =0 obj#=13484 tim=1347358906603236 WAIT #3: nam='resmgr:cpu quantum' ela= 422919 location=3 =0 =0 obj#=13484 tim=1347358907137110 WAIT #3: nam='resmgr:cpu quantum' ela= 221961 location=3 =0 =0 obj#=13484 tim=1347358907469028 WAIT #3: nam='resmgr:cpu quantum' ela= 211970 location=3 =0 =0 obj#=13484 tim=1347358907781950 WAIT #3: nam='resmgr:cpu quantum' ela= 1171768 location=3 =0 =0 obj#=13484 tim=1347358909056669 |
如上，KSO用戶會話只被分配了有限的CPU時間。在跟蹤記錄裏的ela=attribute顯示了這個會話花在等待事件resmgr: CPU quantum上的時間值(單位爲μs)。這些等待事件對應的ela時間的綜合代表着這個會話遵循DAYTIME計劃中所定義好的分配指令而被迫放棄的CPU時間總量。
第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視圖中所收集到的指標，這些指標在確定測試過程中各個使用者組的資源分配策略是非常有價值的。
|
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 ORDERBY cpu_wait_time;
Active Execution CPU Wait CPU Consumed Name Sessions Waiters Requests Time Waits CPU Time Yields ------------ -------- --------- ---------- ------------ ----------- ----------- ---------- BACKGROUND 41 0 48 0 0 0 0 APPS 3 1 255 1,976,674 21,224 3,026,854 20,894 MAINTENANCE 3 3 50 4,776,855 4,601 487,867 4,527 REPORTS 4 3 99 5,290,710 8,272 871,792 8,140 OTHER_GROUPS 5 4 425 9,200,106 5,806 574,156 5,391 |
註明：摘錄自《深入理解Oracle Exadata》
