oracle gc buffur,【性能調優】Oracle AWR報告指標全解析

最新推荐文章于 2022-04-25 18:16:41 发布

3菲菲

最新推荐文章于 2022-04-25 18:16:41 发布

阅读量960

点赞数

文章标签： oracle gc buffur

1-1 內存參數大小

Cache Sizes BeginEnd

~~~~~~~~~~~ ---------- ----------

Buffer Cache: 49,152M 49,152M Std Block Size: 8K

Shared Pool Size: 13,312M 13,312M Log Buffer: 334,848K

內存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)

小內存有小內存的問題，大內存有大內存的麻煩！ ORA-04031???!!

Buffer cache和shared pool size的begin/end值在ASMM、AMM和11gR2 MSMM下可是會動的哦！

這里說 shared pool一直收縮，則在shrink過程中一些row cache 對象被lock住可能導致前台row cache lock等解析等待，最好別讓shared pool shrink。如果這里shared pool一直在grow，那說明shared pool原有大小不足以滿足需求(可能是大量硬解析)，結合下文的解析信息和SGA breakdown來一起診斷問題。

1-2 LoadProfile

LoadProfile PerSecondPerTransactionPerExecPer Call

~~~~~~~~~~~~ --------------- --------------- ---------- ----------

DB Time(s): 256.6 0.2 0.07 0.03

DB CPU(s): 3.7 0.0 0.00 0.00

Redo size: 1,020,943.0 826.5

Logical reads: 196,888.0 159.4

Block changes: 6,339.4 5.1

Physical reads: 5,076.7 4.1

Physical writes: 379.2 0.3

Usercalls: 10,157.4 8.2

Parses: 204.0 0.2

Hard parses: 0.9 0.0

W/A MB processed: 5.0 0.0

Logons: 1.7 0.0

Executes: 3,936.6 3.2

Rollbacks: 1,126.3 0.9

Transactions: 1,235.3

% Blocks changed per Read: 53.49 Recursive Call %: 98.04

Rollbackpertransaction%: 36.57Rowsper Sort: 73.70

指標指標含義

redo size單位 bytes，redosize可以用來估量update/insert/delete的頻率，大的redosize往往對lgwr寫日志，和arch歸檔造成I/O壓力， PerTransaction可以用來分辨是大量小事務，還是少量大事務。如上例每秒redo 約1MB ，每個事務800 字節，符合OLTP特征

Logical Read單位次數*塊數，相當於 “人*次”，如上例 196,888 * db_block_size=1538MB/s ，邏輯讀耗CPU，主頻和CPU核數都很重要，邏輯讀高則DB CPU往往高，也往往可以看到latch: cache buffer chains等待。大量OLTP系統(例如siebel)可以高達幾十乃至上百Gbytes。

Block changes 單位次數*塊數，描繪數據變化頻率

Physical Read單位次數*塊數，如上例 5076 * 8k = 39MB/s，物理讀消耗IO讀，體現在IOPS和吞吐量等不同緯度上；但減少物理讀可能意味着消耗更多CPU。好的存儲每秒物理讀能力達到幾GB，例如Exadata。這個physicalread包含了physical reads cache和physical reads direct

Physical writes 單位次數*塊數，主要是DBWR寫datafile，也有direct path write。 dbwr長期寫出慢會導致定期log file switch(checkpointnocomplete) 檢查點無法完成的前台等待。這個physical write 包含了physical writes direct +physical writesfromcache

UserCalls 單位次數，用戶調用數，more detailsfrominternal

Parses 解析次數，包括軟解析+硬解析，軟解析優化得不好，則誇張地說幾乎等於每秒SQL執行次數。即執行解析比1:1，而我們希望的是解析一次到處運行哦！

Hard Parses 萬惡之源．　Cursorpin sonX， library cache: mutex X ， latch: row cache objects /shared pool……………..。硬解析最好少於每秒20次

W/A MB processed 單位MB W/A workarea workarea中處理的數據數量

結合 In-memory Sort%， sorts (disk) PGA Aggr一起看

Logons 登陸次數， logon storm 登陸風暴，結合AUDIT審計數據一起看。短連接的附帶效應是游標緩存無用

Executes 執行次數，反應執行頻率

Rollback回滾次數，反應回滾頻率，但是這個指標不太精確，參考而已，別太當真

Transactions 每秒事務數，是數據庫層的TPS，可以看做壓力測試或比對性能時的一個指標，孤立看無意義

% Blocks changed per Read每次邏輯讀導致數據塊變化的比率；如果’redosize’, ‘block changes’ ‘pctofblocks changed perread’三個指標都很高，則說明系統正執行大量insert/update/delete;

pct ofblocks changed perread= (block changes ) /( logical reads)

Recursive Call % 遞歸調用的比率;Recursive Call % = (recursive calls)/(usercalls)

Rollbackpertransaction% 事務回滾比率。Rollbackpertransaction%= (rollback)/(transactions)

Rowsper Sort 平均每次排序涉及到的行數 ;Rowsper Sort= ( sorts(rows) ) / ( sorts(disk) + sorts(memory))

注意這些LoadProfile 負載指標在本環節提供了 2個維度 persecond和 pertransaction。

per Second: 主要是把快照內的delta值除以快站時間的秒數，例如在 A快照中V$SYSSTAT視圖反應tablescans (long tables) 這個指標是 100 ，在B快照中V$SYSSTAT視圖反應tablescans (long tables) 這個指標是 3700, 而A快照和B快照之間間隔了一個小時 3600秒，則對於tablescans (long tables) persecond就是 ( 3700- 100) /3600=1。

pert Second是我們審視數據的主要維度，任何性能數據脫離了時間模型則毫無意義。

在statspack/AWR出現之前的調優洪荒時代，有很多DBA 依賴 V$SYSSTAT等視圖中的累計統計信息來調優，以當前的調優眼光來看，那無異於刀耕火種。

per transaction: 基於事務的維度，與persecond相比是把除數從時間的秒數改為了該段時間內的事務數。這個維度的很大用戶是用來識別應用特性的變化，若2個AWR性能報告中該維度指標出現了大幅變化，例如 redosize從本來pertransaction1k變化為 10k pertransaction，則說明SQL業務邏輯肯定發生了某些變化。

注意AWR中的這些指標並不僅僅用來孤立地了解 Oracle數據庫負載情況，實施調優工作。對於故障診斷例如HANG、Crash等，完全可以通過對比問題時段的性能報告和常規時間來對比，通過各項指標的對比往往可以找出病灶所在。

SELECTVALUEFROMDBA_HIST_SYSSTATWHERESNAP_ID = :B4ANDDBID = :B3ANDINSTANCE_NUMBER = :B2ANDSTAT_NAMEin("db block changes","user calls","user rollbacks","user commits",redosize","physical reads direct","physical writes","parsecount(hard)","parsecount(total)","session logical reads","recursive calls","redo logspacerequests","redo entries","sorts (memory)","sorts (disk)","sorts (rows)","logons cumulative","parsetimecpu","parsetimeelapsed","executecount","logonscurrent","opened cursorscurrent","DBWR fusion writes","gcs messages sent","ges messages sent","globalenqueue gets sync","globalenqueue gettime","gc cr blocks received","gc cr block receivetime","gccurrentblocks received","gccurrentblock receivetime","gc cr blocks served","gc cr block buildtime","gc cr block flushtime","gc cr block sendtime","gccurrentblocks served","gccurrentblock pintime","gccurrentblock flushtime","gccurrentblock sendtime","physical reads","physical reads direct (lob)",

SELECTTOTAL_WAITSFROMDBA_HIST_SYSTEM_EVENTWHERESNAP_ID = :B4ANDDBID = :B3ANDINSTANCE_NUMBER = :B2ANDEVENT_NAMEin("gc buffer busy","buffer busy waits"

SELECTVALUEFROMDBA_HIST_SYS_TIME_MODELWHEREDBID = :B4ANDSNAP_ID = :B3ANDINSTANCE_NUMBER = :B2ANDSTAT_NAMEin("DB CPU","sql execute elapsed time","DB time"

SELECTVALUEFROMDBA_HIST_PARAMETERWHERESNAP_ID = :B4ANDDBID = :B3ANDINSTANCE_NUMBER = :B2ANDPARAMETER_NAMEin("__db_cache_size","__shared_pool_size","sga_target","pga_aggregate_target","undo_management","db_block_size","log_buffer","timed_statistics","statistics_level"

SELECTBYTESFROMDBA_HIST_SGASTATWHERESNAP_ID = :B4ANDDBID = :B3ANDINSTANCE_NUMBER = :B2ANDPOOLIN('shared pool','all pools')ANDNAMEin("free memory",

SELECTBYTESFROMDBA_HIST_SGASTATWHERESNAP_ID = :B4ANDDBID = :B3ANDINSTANCE_NUMBER = :B2ANDNAME= :B1ANDPOOLISNULL

SELECT(E.BYTES_PROCESSED - B.BYTES_PROCESSED)FROMDBA_HIST_PGA_TARGET_ADVICE B, DBA_HIST_PGA_TARGET_ADVICE EWHEREB.DBID = :B4ANDB.SNAP_ID = :B3ANDB.INSTANCE_NUM

BER = :B2 ANDB.ADVICE_STATUS ='ON'ANDE.DBID = B.DBIDANDE.SNAP_ID = :B1ANDE.INSTANCE_NUMBER = B.INSTANCE_NUMBERANDE.PGA_TARGET_FACTOR = 1ANDB.PGA_TARGET_FACT

OR= 1ANDE.ADVICE_STATUS ='ON'

SELECTSUM(E.TOTAL_WAITS - NVL(B.TOTAL_WAITS, 0))FROMDBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT EWHEREB.SNAP_ID(+) = :B4ANDE.SNAP_ID = :B3ANDB.DBID(+) = :B2

ANDE.DBID = :B2ANDB.INSTANCE_NUMBER(+) = :B1ANDE.INSTANCE_NUMBER = :B1ANDB.EVENT_ID(+) = E.EVENT_IDAND(E.EVENT_NAME ='latch free'ORE.EVENT_NAMELIKE'latch

:%')

SELECTDECODE(B.TOTAL_SQL, 0, 0, 100*(1-B.SINGLE_USE_SQL/B.TOTAL_SQL)), DECODE(E.TOTAL_SQL, 0, 0, 100*(1-E.SINGLE_USE_SQL/E.TOTAL_SQL)), DECODE(B.TOTAL_SQL_MEM, 0, 0, 1

00*(1-B.SINGLE_USE_SQL_MEM/B.TOTAL_SQL_MEM)), DECODE(E.TOTAL_SQL_MEM, 0, 0, 100*(1-E.SINGLE_USE_SQL_MEM/E.TOTAL_SQL_MEM)) FROMDBA_HIST_SQL_SUMMARY B, DBA_HIST_SQL_SUMM

ARY E WHEREB.SNAP_ID = :B4ANDE.SNAP_ID = :B3ANDB.INSTANCE_NUMBER = :B2ANDE.INSTANCE_NUMBER = :B2ANDB.DBID = :B1ANDE.DBID = :B1

SELECTEVENT, WAITS,TIME, DECODE(WAITS,NULL, TO_NUMBER(NULL), 0, TO_NUMBER(NULL),TIME/WAITS*1000) AVGWT, PCTWTT, WAIT_CLASSFROM(SELECTEVENT, WAITS,TIME, PCTWTT,

WAIT_CLASS FROM(SELECTE.EVENT_NAME EVENT, E.TOTAL_WAITS - NVL(B.TOTAL_WAITS,0) WAITS, (E.TIME_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0)) / 1000000TIME, 100 * (E.TIME

_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0)) / :B1 PCTWTT, E.WAIT_CLASS WAIT_CLASS FROMDBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT EWHEREB.SNAP_ID(+) = :B5ANDE.S

NAP_ID = :B4 ANDB.DBID(+) = :B3ANDE.DBID = :B3ANDB.INSTANCE_NUMBER(+) = :B2ANDE.INSTANCE_NUMBER = :B2ANDB.EVENT_ID(+) = E.EVENT_IDANDE.TOTAL_WAITS > NVL(B.TO

TAL_WAITS,0) ANDE.WAIT_CLASS !='Idle'UNIONALLSELECT'CPU time'EVENT, TO_NUMBER(NULL) WAITS, :B6 /1000000TIME, 100 * :B6 / :B1 PCTWTT,NULLWAIT_CLASSFROMDUAL W

HERE :B6 > 0) ORDERBYTIMEDESC, WAITSDESC)WHEREROWNUM <= :B7

SELECTSUM(E.TIME_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0))FROMDBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT EWHEREB.SNAP_ID(+) = :B4ANDE.SNAP_ID = :B3ANDB.DB

ID(+) = :B2 ANDE.DBID = :B2ANDB.INSTANCE_NUMBER(+) = :B1ANDE.INSTANCE_NUMBER = :B1ANDB.EVENT_ID(+) = E.EVENT_IDANDE.WAIT_CLASS ='User I/O'

SELECT(E.ESTD_LC_TIME_SAVED - B.ESTD_LC_TIME_SAVED)FROMDBA_HIST_SHARED_POOL_ADVICE B, DBA_HIST_SHARED_POOL_ADVICE EWHEREB.DBID = :B3ANDB.INSTANCE_NUMBER = :B2 AN

D B.SNAP_ID = :B4 ANDE.DBID = :B3ANDE.INSTANCE_NUMBER = :B2ANDE.SNAP_ID = :B1ANDE.SHARED_POOL_SIZE_FACTOR = 1ANDB.SHARED_POOL_SIZE_FACTOR = 1

1-3 Instance Efficiency Percentages (Target 100%)

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Buffer Nowait %: 99.97 Redo NoWait %: 100.00

Buffer Hit %: 97.43 In-memory Sort %: 100.00

Library Hit %: 99.88 Soft Parse %: 99.58

ExecutetoParse %: 94.82 Latch Hit %: 99.95

Parse CPU toParse Elapsd %: 1.75 % Non-Parse CPU: 99.85

上述所有指標的目標均為100%，即越大越好，在少數bug情況下可能超過100%或者為負值。

◾80%以上 %Non-Parse CPU

◾90%以上 Buffer Hit%, In-memory Sort%, Soft Parse%

◾95%以上 Library Hit%, Redo Nowait%, Buffer Nowait%

◾98%以上 Latch Hit%

1、 Buffer Nowait % session申請一個buffer(兼容模式)不等待的次數比例。需要訪問buffer時立即可以訪問的比率，不兼容的情況在9i中是 buffer busy waits，從10g以后 buffer busy waits 分離為 buffer busy wait 和 readbyother session2個等待事件 :

9i 中 waitstat的總次數基本等於buffer busy waits等待事件的次數

SQL> selectsum(TOTAL_WAITS)fromv$system_eventwhereevent='buffer busy waits';

SUM(TOTAL_WAITS)

—————-

33070394

SQL> selectsum(count)fromv$waitstat;

SUM(COUNT)

———-

33069335

10g waitstat的總次數基本等於 buffer busy waits 和 readbyother session 等待的次數總和

SQL> selectsum(TOTAL_WAITS)fromv$system_eventwhereevent='buffer busy waits'orevent='read by other session';

SUM(TOTAL_WAITS)

—————-

60675815

SQL> selectsum(count)fromv$waitstat;

SUM(COUNT)

———-

60423739

Buffer Nowait %的計算公式是 sum(v$waitstat.wait_count) / (v$sysstat statistic session logical reads)，例如在AWR中：

Class

Waits

Total Wait Time(s)

AvgTime(ms)

data block 24,543 2,267 92

undo header 743 2 3

undo block 1,116 0 0

1st levelbmb 35 0 0

session logical reads 40,769,800 22,544.84 204.71

Buffer Nowait %: 99.94

Buffer Nowait= ( 40,769,800 – (24543+743+1116+35))/ ( 40,769,800) = 0.99935= 99.94%

SELECTSUM(WAIT_COUNT)FROMDBA_HIST_WAITSTATWHERESNAP_ID = :B3ANDDBID = :B2ANDINSTANCE_NUMBER = :B1

2、buffer HIT%: 經典的經典，高速緩存命中率，反應物理讀和緩存命中間的糾結，但這個指標即便99% 也不能說明物理讀等待少了

不合理的db_cache_size，或者是SGA自動管理ASMM /Memory 自動管理AMM下都可能因為db_cache_size過小引起大量的db file sequential /scattered read等待事件； maclean曾經遇到過因為大量硬解析導致ASMM 下shared pool共享池大幅度膨脹，而db cache相應縮小shrink的例子，最終db cache收縮到只有幾百兆，本來沒有的物理讀等待事件都大幅涌現出來。

此外與 buffer HIT%相關的指標值得關注的還有 tablescans(long tables) 大表掃描這個統計項目、此外相關的欄目還有Buffer PoolStatistics、Buffer Pool Advisory等(如果不知道在哪里，直接找一個AWR 去搜索這些關鍵詞即可)。

buffer HIT%在不同版本有多個計算公式：

在9i中

Buffer Hit Ratio = 1 – ((physical reads – physical reads direct – physical reads direct (lob)) / (db block gets + consistent gets – physical reads direct – physical reads direct (lob))

在10g以后：

Buffer Hit Ratio= 1 – ((‘physical reads cache’) / (‘consistent gets fromcache’ + ‘db block getsfromcache’)

注意：但是實際AWR中似乎還是按照9i中的算法，雖然算法的區別對最后算得的比率影響不大。

對於buffer hit % 看它的命中率有多高沒有意義，主要是關注未命中的次數有多少。通過上述公式很容易反推出未命中的物理讀的次數。

db block gets 、consistent gets 以及 session logical reads的關系如下：

db block gets＝db block gets direct＋　db block gets fromcache

consistent gets　＝　consistent gets fromcache＋　consistent gets direct

consistent gets fromcache＝　consistent gets – examination +else

consistent gets – examination==>指的是不需要pin buffer直接可以執行consistent get的次數，常用於索引，只需要一次latch get

session logical reads = db block gets +consistent gets

其中physical reads 、physical reads cache、physical reads direct、physical reads direct (lob)幾者的關系為：

physical reads = physical reads cache +　physical reads direct

這個公式其實說明了物理讀有2種：

◾物理讀進入buffer cache中，是常見的模式 physical reads cache

◾物理讀直接進入PGA 直接路徑讀，即physical reads direct

physical reads 8 Total number ofdata blocksreadfromdisk. This value can be greater than the valueof“physical reads direct” plus “physical reads cache”asreadsintoprocess private buffers also includedinthis statistic.

physical reads cache 8 Total number ofdata blocksreadfromdiskintothe buffer cache. Thisisa subsetof“physical reads” statistic.

physical reads direct 8 Number ofreads directlyfromdisk, bypassing the buffer cache.Forexample,inhigh bandwidth, data-intensive operations suchasparallel query, readsofdisk blocks bypass the buffer cachetomaximize transfer ratesandtoprevent the premature agingofshared data blocks residentinthe buffer cache.

physical reads direct = physical reads direct (lob) + physical reads direct temporarytablespace + physical reads direct(普通)

這個公式也說明了直接路徑讀分成三個部分：

◾physical reads direct (lob) 直接路徑讀LOB對象

◾physical reads direct temporarytablespace 直接路徑讀臨時表空間

◾physical readdirect(普通) 普通的直接路徑讀，一般是11g開始的自動的大表direct pathread和並行引起的direct pathread

physical writes direct= physical writes direct (lob)+ physical writes direct temporarytablespace

DBWR checkpointbuffers written = DBWR threadcheckpointbuffers written+ DBWR tablespacecheckpointbuffers written+ DBWR PQ tablespacecheckpointbuffers written+….

3、Redo nowait%: session在生成redo entry時不用等待的比例，redo相關的資源爭用例如redo spacerequest爭用可能造成生成redo時需求等待。此項數據來源於v$sysstat中的(redo logspacerequests/redo entries)。一般來說10g以后不太用關注log_buffer參數的大小，需要關注是否有十分頻繁的 log switch ；過小的redo logfilesize如果配合較大的SGA和頻繁的commit提交都可能造成該問題。考慮增到redo logfile 的尺寸 : 1~4G 每個，7~10組都是合適的。同時考慮優化redo logfile和datafile 的I/O。

4、In-memory Sort%:這個指標因為它不計算workarea中所有的操作類型，所以現在越來越雞肋了。純粹在內存中完成的排序比例。數據來源於v$sysstatstatisticssorts (disk) 和 sorts (memory)，In-memory Sort% = sort(memory) / ( sort(disk)+ sort(memory) )

5、

Library Hit%: library cache命中率，申請一個library cache object例如一個SQL cursor時，其已經在library cache中的比例。數據來源 V$librarycache的pins和pinhits。合理值：>95% ，該比例來源於1- ( Σ(pin Requests * Pct Miss) /Sum(Pin Requests) )

維護這個指標的重點是保持shared pool共享池有足夠的FreeMemory，且沒有過多的內存碎片，具體可以參考這里。顯然過小的shared pool可用空間會導致library cache object被agedout換出共享池。

此外保證SQL語句綁定變量和游標可以共享也是很重要的因素。

Library Cache Activity DB/Inst: G10R25/G10R25 Snaps: 2964-2965

-> "Pct Misses"should be very low http://www.askmaclean.com

Get Pct Pin Pct Invali-

Namespace Requests Miss Requests Miss Reloads dations

--------------- ------------ ------ -------------- ------ ---------- --------

BODY 5 0.0 6 16.7 1 0

CLUSTER 10 0.0 26 0.0 0 0

SQL AREA 601,357 99.8 902,828 99.7 47 2

TABLE/PROCEDURE83 9.6 601,443 0.0 48 0

GETS NUMBER Number oftimes a lock was requestedforobjectsofthis namespace

GETHITS NUMBER Number oftimes an object’s handle was foundinmemory

GETHITRATIO NUMBER Ratio ofGETHITStoGETS

PINS NUMBER Number oftimes a PIN was requestedforobjectsofthis namespace

PINHITS NUMBER Number oftimesallofthe metadata piecesofthe library object were foundinmemory

PINHITRATIO NUMBER Ratio ofPINHITStoPINS

RELOADS NUMBER AnyPINofan object thatisnotthefirstPIN performed since the object handle was created,andwhich requires loading the objectfromdisk

INVALIDATIONS NUMBER Total number oftimes objectsinthis namespace were marked invalid because a dependent object was modified

SELECTSUM(PINS),SUM(PINHITS)FROMDBA_HIST_LIBRARYCACHEWHERESNAP_ID = :B3ANDDBID = :B2ANDINSTANCE_NUMBER = :B1

6、

Soft Parse: 軟解析比例，無需多說的經典指標，數據來源v$sysstat statistics的parsecount(total)和parsecount(hard)。合理值>95%

Soft Parse %是AWR中另一個重要的解析指標，該指標反應了快照時間內軟解析次數和總解析次數 (soft+hard 軟解析次數+硬解析次數)的比值，若該指標很低，那么說明了可能存在劇烈的hard parse硬解析，大量的硬解析會消耗更多的CPU時間片並產生解析爭用(此時可以考慮使用cursor_sharing=FORCE)；理論上我們總是希望 Soft Parse % 接近於100%，但並不是說100%的軟解析就是最理想的解析狀態，通過設置 session_cached_cursors參數和反復重用游標我們可以讓解析來的更輕量級，即通俗所說的利用會話緩存游標實現的軟軟解析(soft soft parse)。

7、

ExecutetoParse% 指標反映了執行解析比其公式為 1-(parse/execute) , 目標為100% 及接近於只執行而不解析。數據來源v$sysstatstatisticsparsecount(total) 和executecount

在oracle中解析往往是執行的先提工作，但是通過游標共享可以解析一次執行多次，執行解析可能分成多種場景：

1.hard coding => 硬編碼代碼硬解析一次，執行一次，則理論上其執行解析比為 1:1 ，則理論上ExecutetoParse =0 極差，且soft parse比例也為0%

2.綁定變量但是仍軟解析=》軟解析一次，執行一次，這種情況雖然比前一種好但是執行解析比(這里的parse，包含了軟解析和硬解析)仍是1:1，理論上ExecutetoParse =0 極差，但是soft parse比例可能很高

3.使用靜態SQL、動態綁定、session_cached_cursor、opencursors等技術實現的解析一次，執行多次，執行解析比為N:1，則ExecutetoParse= 1- (1/N) 執行次數越多ExecutetoParse越接近100% ，這種是我們在OLTP環境中喜聞樂見的！

通俗地說 soft parse% 反映了軟解析率，而軟解析在oracle中仍是較昂貴的操作，我們希望的是解析1次執行N次，如果每次執行均需要軟解析，那么雖然soft parse%=100% 但是parse time仍可能是消耗DBTIME的大頭。

ExecutetoParse反映了執行解析比，ExecutetoParse和soft parse% 都很低那么說明確實沒有綁定變量，而如果 soft parse% 接近99% 而ExecutetoParse 不足90% 則說明沒有執行解析比低，需要通過靜態SQL、動態綁定、session_cached_cursor、opencursors等技術減少軟解析。

8、

Latch Hit%: willing-to-wait latch閂申請不要等待的比例。數據來源V$latch gets和misses

Latch Name

----------------------------------------

Get Requests Misses Sleeps Spin Gets Sleep1 Sleep2 Sleep3

-------------- ----------- ----------- ---------- -------- -------- --------

shared pool

9,988,637 364 23 341 0 0 0

library cache

6,753,468 152 6 146 0 0 0

Memory Management Latch

369 1 1 0 0 0 0

qmn task queue latch

24 1 1 0 0 0 0

Latch Hit%:= (1 – (Sum(misses) /Sum(gets)))

關於Latch的更多信息內容可以參考 AWR后面的專欄Latch Statistics，注意對於一個並發設計良好的OLTP應用來說，Latch、Enqueue等並發控制不應當成為系統的主要瓶頸，同時對於這些並發爭用而言堆積硬件CPU和內存很難有效改善性能。

SELECTSUM(GETS),SUM(MISSES)FROMDBA_HIST_LATCHWHERESNAP_ID = :B3ANDDBID = :B2ANDINSTANCE_NUMBER = :B1

9、

Parse CPU ToParse Elapsd:該指標反映了快照內解析CPU時間和總的解析時間的比值(Parse CPUTime/ Parse ElapsedTime)；若該指標水平很低，那么說明在整個解析過程中實際在CPU上運算的時間是很短的，而主要的解析時間都耗費在各種其他非空閑的等待事件上了(如latch:shared pool,row cache lock之類等) 數據來源 V$sysstat 的 parsetimecpu和parsetimeelapsed

10、

%Non-Parse CPU 非解析cpu比例，公式為 (DB CPU – Parse CPU)/DB CPU，若大多數CPU都用在解析上了，則可能好鋼沒用在刃上了。數據來源 v$sysstat 的 parse timecpu和 cpu usedbythis session

1-4 Shared Pool Statistics

Shared Pool StatisticsBeginEnd

------ ------

Memory Usage %: 84.64 79.67

% SQL withexecutions>1: 93.77 24.69

% Memory forSQL w/exec>1: 85.36 34.8

該環節提供一個大致的SQL重用及shared pool內存使用的評估。應用是否共享SQL? 有多少內存是給只運行一次的SQL占掉的，對比共享SQL呢？

如果該環節中% SQL withexecutions>1的比例小於%90 ，考慮用下面鏈接的SQL去抓硬編碼的非綁定變量SQL語句。

利用FORCE_MATCHING_SIGNATURE捕獲非綁定變量SQL

Memory Usage %: (shared pool 的實時大小- shared pool freememory)/ shared pool 的實時大小，代表shared pool的空間使用率，雖然有使用率但沒有標明碎片程度

% SQL withexecutions>1 復用的SQL占總的SQL語句的比率,數據來源 DBA_HIST_SQL_SUMMARY 的 SINGLE_USE_SQL和TOTAL_SQL：1 – SINGLE_USE_SQL / TOTAL_SQL

% Memory forSQL w/exec>1 執行2次以上的SQL所占內存占總的SQL內存的比率，數據來源DBA_HIST_SQL_SUMMARY 的SINGLE_USE_SQL_MEM和TOTAL_SQL_MEM：1 – SINGLE_USE_SQL_MEM / TOTAL_SQL_MEM

==》上面2個指標也可以用來大致了解shared pool中的內存碎片程序，因為SINGLE_USE_SQL 單次執行的SQL多的話，那么顯然可能有較多的共享池內存碎片

SQL復用率低的原因一般來說就是硬綁定變量(hard Coding)未合理使用綁定變量(bind variable)，對於這種現象短期無法修改代表使用綁定變量的可以ALTERSYSTEMSETCURSOR_SHARING=FORCE; 來繞過問題，對於長期來看還是要修改代碼綁定變量。 Oracle 從11g開始宣稱今后將廢棄CURSOR_SHARING的SIMILAR選項，同時SIMILAR選項本身也造成了很多問題，所以一律不推薦用CURSOR_SHARING=SIMILAR。

如果memory usage%比率一直很高，則可以關注下后面sga breakdown中的shared pool freememory大小，一般推薦至少讓freememroy有個300~500MB 以避免隱患。

1-5 Top5 Timed Events

Top5 Timed EventsAvg%Total

~~~~~~~~~~~~~~~~~~ wait Call

Event Waits Time(s) (ms)TimeWait Class

------------------------------ ------------ ----------- ------ ------ ----------

gc buffer busy 79,083 73,024 923 65.4 Cluster

enq: TX - row lock contention 35,068 17,123 488 15.3 Applicatio

CPU time12,205 10.9

gc currentrequest 2,714 3,315 1221 3.0 Cluster

gc cr multi block request 83,666 1,008 12 0.9 Cluster

基於Wait Interface的調優是目前的主流！每個指標都重要！

基於命中比例的調優，好比是統計局的報告，張財主家財產100萬，李木匠家財產1萬，平均財產50.5萬。

基於等待事件的調優，好比馬路上100輛汽車的行駛記錄表，上車用了幾分鍾，紅燈等了幾分鍾，擁堵塞了幾分鍾。。。

豐富的等待事件以足夠的細節來描繪系統運行的性能瓶頸，這是Mysql夢寐以求的東西……

Waits : 該等待事件發生的次數，對於DB CPU此項不可用

Times : 該等待事件消耗的總計時間，單位為秒，對於DB CPU 而言是前台進程所消耗CPU時間片的總和，但不包括Wait onCPU QUEUE

AvgWait(ms) : 該等待事件平均等待的時間，實際就是 Times/Waits，單位ms，對於DB CPU此項不可用

% Total Call Time，該等待事件占總的calltime的比率

total call time= total CPUtime+ total waittimefornon-idle events

% Total Call Time=timeforeach timed event / total calltime

Wait Class: 等待類型：

Concurrency,System I/O,UserI/O,Administrative,Other,Configuration,Scheduler,Cluster,Application,Idle,Network,Commit

CPU 上在干什么？

邏輯讀？解析？Latch spin? PL/SQL、函數運算?

DB CPU/CPU time是Top1 是好事情嗎？未必！

注意DB CPU不包含 wait oncpu queue！

SELECTe.event_name event,

e.total_waits - NVL (b.total_waits, 0) waits,

DECODE (

e.total_waits - NVL (b.total_waits, 0),

0, TO_NUMBER (NULL),

DECODE (

e.total_timeouts - NVL (b.total_timeouts, 0),

0, TO_NUMBER (NULL),

100

* (e.total_timeouts - NVL (b.total_timeouts, 0))

/ (e.total_waits - NVL (b.total_waits, 0))))

pctto,

(e.time_waited_micro - NVL (b.time_waited_micro, 0)) / 1000000 time,

DECODE (

(e.total_waits - NVL (b.total_waits, 0)),

0, TO_NUMBER (NULL),

( (e.time_waited_micro - NVL (b.time_waited_micro, 0)) / 1000)

/ (e.total_waits - NVL (b.total_waits, 0)))

avgwt,

DECODE (e.wait_class, 'Idle', 99, 0) idle

FROMdba_hist_system_event b, dba_hist_system_event e

WHEREb.snap_id(+) = &bid

ANDe.snap_id = &eid

--AND b.dbid(+) = :dbid

--AND e.dbid = :dbid

ANDb.instance_number(+) = 1

ANDe.instance_number = 1

ANDb.event_id(+) = e.event_id

ANDe.total_waits > NVL (b.total_waits, 0)

ANDe.event_nameNOTIN

('smon timer',

'pmon timer',

'dispatcher timer',

'dispatcher listen timer',

'rdbms ipc message')

ORDERBYidle,

timeDESC,

waits DESC,

event

幾種常見的等待事件

=========================>

db file scattered read,Avgwaittime應當小於20ms 如果數據庫執行全表掃描或者是全索引掃描會執行 Multi block I/O ，此時等待物理I/O 結束會出現此等待事件。一般會從應用程序(SQL)，I/O 方面入手調整; 注意和《Instance Activity Stats》中的indexfastfullscans (full) 以及tablescans (long tables)集合起來一起看。

db file sequential read，該等待事件Avgwaittime平均單次等待時間應當小於20ms

”db file sequential read”單塊讀等待是一種最為常見的物理IO等待事件，這里的sequential指的是將數據塊讀入到相連的內存空間中(contiguous memoryspace)，而不是指所讀取的數據塊是連續的。該wait event可能在以下情景中發生:

http://www.askmaclean.com/archives/db-file-sequential-read-wait-event.html

latch free其實是未獲得latch ，而進入latch sleep，見《全面解析9i以后Oracle Latch閂鎖原理》

enq:XX 隊列鎖等待，視乎不同的隊列鎖有不同的情況：

◾你有多了解Oracle Enqueue lock隊列鎖機制？

◾Oracle隊列鎖: Enqueue HW

◾Oracle隊列鎖enq:US,Undo Segment

◾enq: TX – row lock/indexcontention、allocate ITL等待事件

◾enq: TT – contention等待事件

◾Oracle隊列鎖enq:TS,TemporarySegment (also TableSpace)

◾enq: JI – contention等待事件

◾enq: US – contention等待事件

◾enq: TM – contention等待事件

◾enq: RO fast object reuse等待事件

◾enq: HW – contention等待事件

freebuffer waits：是由於無法找到可用的buffer cache 空閑區域，需要等待DBWR 寫入完成引起

◾一般是由於

◾低效的sql

◾過小的buffer cache

◾DBWR 工作負荷過量

buffer busy wait/ readbyother session 一般以上2個等待事件可以歸為一起處理，建議客戶都進行監控。以上等待時間可以由如下操作引起

◾select/select—-readbyother session: 由於需要從數據文件中將數據塊讀入 buffer cache 中引起，有可能是大量的邏輯/物理讀 ;或者過小的 buffer cache 引起

◾select/update—- buffer busy waits/readbyother session 是由於更新某數據塊后需要在undo 中重建構建過去時間的塊，有可能伴生 enq:cr-contention 是由於大量的物理讀/邏輯讀造成。

◾update/update—- buffer busy waits 由於更新同一個數據塊(非同一行，同一行是enq:TX-contention) 此類問題是熱點塊造成

◾insert/insert—- buffer busy waits 是由於freelist 爭用造成，可以將表空間更改為ASSM 管理或者加大freelist 。

write complete waits :一般此類等待事件是由於 DBWR 將臟數據寫入數據文件，其他進程如果需要修改 buffer cache會引起此等待事件，一般是 I/O 性能問題或者是DBWR 工作負荷過量引起

Wait time1 Seconds.

control file parallel write：頻繁的更新控制文件會造成大量此類等待事件，如日志頻繁切換，檢查點經常發生，nologging 引起頻繁的數據文件更改，I/O 系統性能緩慢。

log file sync：一般此類等待時間是由於 LGWR 進程講redo log buffer 寫入redo log 中發生。如果此類事件頻繁發生，可以判斷為：

◾commit次數是否過多

◾I/O 系統問題

◾重做日志是否不必要被創建

◾redo log buffer 是否過大

2-1 TimeModelStatistics

TimeModelStatisticsDB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723

-> Total timeindatabaseuser-calls (DBTime): 883542.2s

-> Statisticsincluding the word"background"measure background process

time,andso donotcontributetothe DBtimestatistic

-> Ordered by%orDBtimedesc, Statisticname

Statistic NameTime(s) %ofDBTime

------------------------------------------ ------------------ ------------

sql executeelapsedtime805,159.7 91.1

sequenceloadelapsedtime41,159.2 4.7

DB CPU 20,649.1 2.3

parse timeelapsed 1,112.8 .1

hard parse elapsed time995.2 .1

hard parse (sharing criteria) elapsed time237.3 .0

hard parse (bind mismatch) elapsed time227.6 .0

connectionmanagement call elapsedtime29.7 .0

PL/SQL execution elapsed time9.2 .0

PL/SQL compilation elapsed time6.6 .0

failed parse elapsed time2.0 .0

repeated bind elapsed time0.4 .0

DB time883,542.2

background elapsed time25,439.0

background cpu time1,980.9

-------------------------------------------------------------

TimeModelStatistics幾個特別有用的時間指標：

◾parse timeelapsed、hard parse elapsedtime結合起來看解析是否是主要矛盾，若是則重點是軟解析還是硬解析

◾sequenceloadelapsedtimesequence序列爭用是否是問題焦點

◾PL/SQL compilation elapsed timePL/SQL對象編譯的耗時

◾注意PL/SQL execution elapsed time純耗費在PL/SQL解釋器上的時間。不包括花在執行和解析其包含SQL上的時間

◾connectionmanagement call elapsedtime建立數據庫session連接和斷開的耗時

◾failed parse elapsed time解析失敗，例如由於ORA-4031

◾hard parse (sharing criteria) elapsed time由於無法共享游標造成的硬解析

◾hard parse (bind mismatch) elapsed time由於bind typeorbindsize不一致造成的硬解析

注意該時間模型中的指標存在包含關系所以TimeModelStatistics加起來超過100%再正常不過

1) background elapsed time

2) background cpu time

3) RMAN cpu time(backup/restore)

1) DB time

2) DB CPU

2) connectionmanagement call elapsedtime

2) sequenceloadelapsedtime

2) sql executeelapsedtime

2) parse timeelapsed

3) hard parse elapsed time

4) hard parse (sharing criteria) elapsed time

5) hard parse (bind mismatch) elapsed time

3) failed parse elapsed time

4) failed parse (outofshared memory) elapsedtime

2) PL/SQL execution elapsed time

2) inbound PL/SQL rpc elapsed time

2) PL/SQL compilation elapsed time

2) Java execution elapsed time

2) repeated bind elapsed time

2-2 Foreground Wait Class

Foreground Wait Class

-> s - second, ms - millisecond - 1000thofasecond

-> ordered bywaittimedesc, waitsdesc

-> %Timeouts: value of0 indicates value was

-> Captured Timeaccountsfor102.7%ofTotal DBtime883,542.21 (s)

-> Total FG Wait Time: 886,957.73 (s) DB CPUtime: 20,649.06 (s)

Avg

%TimeTotal Wait wait

Wait Class Waits -outs Time(s) (ms) %DBtime

-------------------- ---------------- ----- ---------------- -------- ---------

Cluster 9,825,884 1 525,134 53 59.4

Concurrency 688,375 0 113,782 165 12.9

UserI/O 34,405,042 0 76,695 2 8.7

Commit172,193 0 62,776 365 7.1

Application 11,422 0 57,760 5057 6.5

Configuration 19,418 1 48,889 2518 5.5

DB CPU 20,649 2.3

Other 1,757,896 94 924 1 0.1

System I/O 30,165 0 598 20 0.1

Network 171,955,673 0 400 0 0.0

Administrative 2 100 0 101 0.0

-------------------------------------------------------------

selectdistinctwait_classfromv$event_name;

WAIT_CLASS

----------------------------------------------------------------

Concurrency

UserI/O

System I/O

Administrative

Other

Configuration

Scheduler

Cluster

Application

Queueing

Idle

Network

Commit

◾Wait Class: 等待事件的類型，如上查詢所示，被分作12個類型。 10.2.0.5有916個等待事件，其中Other類型占622個。

◾Waits: 該類型所屬等待事件在快照時間內的等待次數

◾%TimeOut等待超時的比率，未超時次數/waits * 100 (%)

◾Total Wait Time: 該類型所屬等待事件總的耗時，單位為秒

◾AvgWait(ms) : 該類型所屬等待事件的平均單次等待時間，單位為ms ，實際這個指標對commit和useri/o 以及system i/o類型有點意義，其他等待類型由於等待事件差異較大所以看平均值的意義較小

◾waits / txn: 該類型所屬等待事件的等待次數和事務比

Other 類型，遇到該類型等待事件的話常見的原因是Oracle Bug或者網絡、I/O存在問題，一般推薦聯系Maclean。

Concurrency 類型並行爭用類型的等待事件，典型的如 latch: shared pool、latch: library cache、row cache lock、library cache pin/lock

Cluster 類型為RealApplication Cluster RAC環境中的等待事件，需要注意的是如果啟用了RACoption，那么即使你的集群中只啟動了一個實例，那么該實例也可能遇到 Cluster類型的等待事件, 例如gc buffer busy

System I/O 主要是后台進程維護數據庫所產生的I/O，例如control file parallel write 、log file parallel write、db file parallel write。

UserI/O 主要是前台進程做了一些I/O操作，並不是說后台進程不會有這些等待事件。典型的如db file sequential/scatteredread、direct pathread

Configuration 由於配置引起的等待事件，例如日志切換的log file switch completion (日志文件大小/數目不夠)，sequence的enq: SQ – contention (Sequence使用nocache) ； Oracle認為它們是由於配置不當引起的，但實際未必真是這樣的配置引起的。

Application 應用造成的等待事件，例如enq: TM – contention和enq: TX – row lock contention； Oracle認為這是由於應用設計不當造成的等待事件，但實際這些Application class 等待可能受到 Concurrency、Cluster、System I/O 、UserI/O等多種類型等待的影響，例如本來commit只要1ms ，則某一行數據僅被鎖定1ms，但由於commit變慢從而釋放行鎖變慢，引發大量的enq: TX – row lock contention等待事件。

Commit僅log file sync ，log file sync的影響十分廣泛，值得我們深入討論。

Network : 網絡類型的等待事件例如 SQL*Net more data toclient 、SQL*Net more datatodblink

Idle 空閑等待事件，最為常見的是rdbms ipc message (等待實例內部的ipc通信才干活，即別人告知我有活干，我才干，否則我休息==》Idle)， SQL*Net message fromclient(等待SQL*NET傳來信息，否則目前沒事干)

2-3 前台等待事件

Foreground Wait Events Snaps: 70719-70723

-> s - second, ms - millisecond - 1000thofasecond

-> OnlyeventswithTotal WaitTime(s) >= .001 are shown

-> ordered bywaittimedesc, waitsdesc(idle eventslast)

-> %Timeouts: value of0 indicates value was

Avg

%TimeTotal Wait wait Waits % DB

Event Waits -outs Time(s) (ms) /txntime

-------------------------- ------------ ----- ---------- ------- -------- ------

gc buffer busy acquire 3,274,352 3 303,088 93 13.3 34.3

gc buffer busy release 387,673 2 128,114 330 1.6 14.5

enq: TX - indexcontention 193,918 0 97,375 502 0.8 11.0

cell single block physical 30,738,730 0 63,606 2 124.8 7.2

log file sync 172,193 0 62,776 365 0.7 7.1

gc currentblock busy 146,154 0 53,027 363 0.6 6.0

enq: TM - contention 1,060 0 47,228 44555 0.0 5.3

enq: SQ - contention 17,431 0 35,683 2047 0.1 4.0

gc cr block busy 105,204 0 33,746 321 0.4 3.8

buffer busy waits 279,721 0 12,646 45 1.1 1.4

enq: HW - contention 1,201 3 12,192 10151 0.0 1.4

enq: TX - row lock content 9,231 0 10,482 1135 0.0 1.2

cell multiblock physical r 247,903 0 6,547 26 1.0 .7

Foreground Wait Events 前台等待事件，數據主要來源於DBA_HIST_SYSTEM_EVENT

Event 等待事件名字

Waits 該等待事件在快照時間內等待的次數

%Timeouts : 每一個等待事件有其超時的設置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件單次等待達到timeout的時間，則會進入下一次該等待事件

Total Wait Time該等待事件總的消耗的時間，單位為秒

Avgwait(ms): 該等待事件的單次平均等待時間，單位為毫秒

Waits/Txn: 該等待事件的等待次數和事務比

2-4 后台等待事件

Background Wait Events Snaps: 70719-70723

-> ordered bywaittimedesc, waitsdesc(idle eventslast)

-> OnlyeventswithTotal WaitTime(s) >= .001 are shown

-> %Timeouts: value of0 indicates value was

Avg

%TimeTotal Wait wait Waits % bg

Event Waits -outs Time(s) (ms) /txntime

-------------------------- ------------ ----- ---------- ------- -------- ------

db file parallel write 90,979 0 7,831 86 0.4 30.8

gcs log flush sync 4,756,076 6 4,714 1 19.3 18.5

enq: CF - contention 2,123 40 4,038 1902 0.0 15.9

control file sequential re 90,227 0 2,380 26 0.4 9.4

log file parallel write 108,383 0 1,723 16 0.4 6.8

control file parallel writ 4,812 0 988 205 0.0 3.9

Disk file operations I/O 26,216 0 731 28 0.1 2.9

flashback log file write 9,870 0 720 73 0.0 2.8

LNS wait onSENDREQ 202,747 0 600 3 0.8 2.4

ASM file metadata operatio 15,801 0 344 22 0.1 1.4

cell single block physical 39,283 0 341 9 0.2 1.3

LGWR-LNS wait onchannel 183,443 18 203 1 0.7 .8

gc currentblock busy 122 0 132 1082 0.0 .5

gc buffer busy release 60 12 127 2113 0.0 .5

Parameter File I/O 592 0 116 195 0.0 .5

log file sequential read1,804 0 104 58 0.0 .4

Background Wait Events 后台等待事件，數據主要來源於DBA_HIST_BG_EVENT_SUMMARY

Event 等待事件名字

Waits 該等待事件在快照時間內等待的次數

Total Wait Time該等待事件總的消耗的時間，單位為秒

Avgwait(ms): 該等待事件的單次平均等待時間，單位為毫秒

Waits/Txn: 該等待事件的等待次數和事務比

2-5 Operating System Statistics

Operating System StatisticsSnaps: 70719-70723

TIMEstatisticvaluesare diffed.

Allothers display actualvalues.EndValueisdisplayed if different

-> ordered bystatistic type (CPU Use, Virtual Memory, Hardware Config),Name

Statistic Value EndValue

------------------------- ---------------------- ----------------

BUSY_TIME 2,894,855

IDLE_TIME 5,568,240

IOWAIT_TIME 18,973

SYS_TIME 602,532

USER_TIME 2,090,082

LOAD8 13

VM_IN_BYTES 0

VM_OUT_BYTES 0

PHYSICAL_MEMORY_BYTES 101,221,343,232

NUM_CPUS 24

NUM_CPU_CORES 12

NUM_CPU_SOCKETS 2

GLOBAL_RECEIVE_SIZE_MAX 4,194,304

GLOBAL_SEND_SIZE_MAX 2,097,152

TCP_RECEIVE_SIZE_DEFAULT 87,380

TCP_RECEIVE_SIZE_MAX 4,194,304

TCP_RECEIVE_SIZE_MIN 4,096

TCP_SEND_SIZE_DEFAULT 16,384

TCP_SEND_SIZE_MAX 4,194,304

TCP_SEND_SIZE_MIN 4,096

-------------------------------------------------------------

Operating System Statistics操作系統統計信息

數據來源於V$OSSTAT / DBA_HIST_OSSTAT，, TIME相關的指標單位均為百分之一秒

統計項描述

NUM_CPU_SOCKETS 物理CPU的數目

NUM_CPU_CORES CPU的核數

NUM_CPUS 邏輯CPU的數目

SYS_TIME 在內核態被消耗掉的CPU時間片，單位為百分之一秒

USER_TIME 在用戶態被消耗掉的CPU時間片，單位為百分之一秒

BUSY_TIME Busy_Time=SYS_TIME+USER_TIME 消耗的CPU時間片，單位為百分之一秒

AVG_BUSY_TIME AVG_BUSY_TIME= BUSY_TIME/NUM_CPUS

IDLE_TIME 空閑的CPU時間片，單位為百分之一秒

所有CPU所能提供總的時間片 BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT

OS_CPU_WAIT_TIME 進程等OS調度的時間，cpu queuing

VM_IN_BYTES 換入頁的字節數

VM_OUT_BYTES 換出頁的字節數，部分版本下並不准確，例如Bug 11712010 Abstract: VIRTUAL MEMORY PAGING ON11.2.0.2 DATABASES，僅供參考

IOWAIT_TIME 所有CPU花費在等待I/O完成上的時間單位為百分之一秒

RSRC_MGR_CPU_WAIT_TIME 是指當resource manager控制CPU調度時，需要控制對應進程暫時不使用CPU而進程到內部運行隊列中，以保證該進程對應的consumer group(消費組)沒有消耗比指定resource manager指令更多的CPU。RSRC_MGR_CPU_WAIT_TIME指等在內部運行隊列上的時間，在等待時不消耗CPU

2-6 Service Statistcs

Service StatisticsSnaps: 70719-70723

-> ordered byDBTime

Physical Logical

Service NameDBTime(s) DB CPU (s) Reads (K) Reads (K)

---------------------------- ------------ ------------ ------------ ------------

itms-contentmasterdb-prod 897,099 20,618 35,668 1,958,580

SYS$USERS 4,312 189 5,957 13,333

itmscmp 1,941 121 14,949 18,187

itscmp 331 20 114 218

itscmp_dgmgrl 121 1 0 0

SYS$BACKGROUND 0 0 142 30,022

ITSCMP1_PR 0 0 0 0

its-reference-prod 0 0 0 0

itscmpXDB 0 0 0 0

按照Service Name來分組時間模型和物理、邏輯讀取，部分數據來源於 WRH$_SERVICE_NAME;

Service Name對應的服務名 (v$services)， SYS$BACKGROUND代表后台進程， SYS$USERS一般是系統用戶登錄

DB TIME(s): 本服務名所消耗的DBTIME時間，單位為秒

DB CPU(s): 本服務名所消耗的DB CPU 時間，單位為秒

Physical Reads : 本服務名所消耗的物理讀

Logical Reads : 本服務所消耗的邏輯讀

2-7 Service Wait Class Stats

Service Wait Class Stats Snaps: 70719-70723

-> Wait Class info forservicesinthe ServiceStatisticssection.

-> Total Waits andTimeWaited displayedforthe following wait

classes: UserI/O, Concurrency, Administrative, Network

-> TimeWaited (WtTime)inseconds

Service Name

----------------------------------------------------------------

UserI/OUserI/O Concurcy Concurcy Admin Admin Network Network

Total Wts Wt TimeTotal Wts WtTimeTotal Wts WtTimeTotal Wts WtTime

--------- --------- --------- --------- --------- --------- --------- ---------

itms-contentmasterdb-prod

33321670 71443 678373 113759 0 0 1.718E+08 127

SYS$USERS

173233 3656 6738 30 2 0 72674 3

itmscmp

676773 1319 1831 0 0 0 2216 0

itscmp

219577 236 1093 0 0 0 18112 0

itscmp_dgmgrl

34 0 8 0 0 0 9 0

SYS$BACKGROUND

71940 1300 320677 56 0 0 442252 872

-------------------------------------------------------------

◾UserI/O Total Wts : 對應該服務名下用戶I/O類等待的總的次數

◾UserI/O WtTime: 對應該服務名下用戶I/O累等待的總時間，單位為 1/100秒

◾Concurcy Total Wts: 對應該服務名下 Concurrency 類型等待的總次數

◾Concurcy Wt Time:對應該服務名下 Concurrency 類型等待的總時間，單位為 1/100秒

◾Admin Total Wts: 對應該服務名下Admin 類等待的總次數

◾Admin Wt Time: 對應該服務名下Admin類等待的總時間，單位為 1/100秒

◾Network Total Wts : 對應服務名下Network類等待的總次數

◾Network Wt Time：對應服務名下Network類等待的總事件，單位為 1/100秒

2-8 Host CPU

Host CPU (CPUs: 24 Cores: 12 Sockets: 2)

~~~~~~~~ LoadAverage

BeginEnd%User%System %WIO %Idle

--------- --------- --------- --------- --------- ---------

8.41 12.84 24.7 7.1 0.2 65.8

“LoadAverage”begin/end值代表每個CPU的大致運行隊列大小。上例中快照開始到結束，平均 CPU負載增加了；與《2-5 Operating SystemStatistics》中的LOAD相呼應。

%User+%System=> 總的CPU使用率，在這里是31.8%

Elapsed Time* NUM_CPUS * CPU utilization= 60.23 (mins) * 24 * 31.8% = 459.67536 mins=BusyTime

2-8 Instance CPU

Instance CPU

~~~~~~~~~~~~

% oftotal CPUforInstance: 26.7

% ofbusy CPUforInstance: 78.2

%DB timewaitingforCPU - Resource Mgr: 0.0

%Total CPU,該實例所使用的CPU占總CPU的比例 % oftotal CPUforInstance

%Busy CPU，該實例所使用的Cpu占總的被使用CPU的比例 % ofbusy CPUforInstance

例如共4個邏輯CPU，其中3個被完全使用，3個中的1個完全被該實例使用，則%Total CPU= ¼ =25%，而%Busy CPU= 1/3= 33%

當CPU高時一般看%Busy CPU可以確定CPU到底是否是本實例消耗的，還是主機上其他程序

% ofbusy CPUforInstance= (DB CPU+ background cputime) / (BUSY_TIME /100)= (20,649.1 + 1,980.9)/ (2,894,855 /100)= 78.17%

% ofTotal CPUforInstance = ( DB CPU+ background cputime)/( BUSY_TIME+IDLE_TIME/100) = (20,649.1 + 1,980.9)/ ((2,894,855+5,568,240) /100) = 26.73%

%DB timewaitingforCPU (Resource Manager)= (RSRC_MGR_CPU_WAIT_TIME/100)/DBTIME

3 TOPSQL

TOPSQL 的數據部分來源於 dba_hist_sqlstat

3-1 SQL ordered byElapsedTime，按照SQL消耗的時間來排列TOPSQL

SQL ordered byElapsedTimeSnaps: 70719-70723

-> Resources reported forPL/SQL code includes the resources usedbyallSQL

statements called bythe code.

-> % Total DB Timeisthe ElapsedTimeofthe SQL statement divided

intothe TotalDatabaseTimemultipliedby100

-> %Total - Elapsed Timeasa percentageofTotal DBtime

-> %CPU - CPU Timeasa percentageofElapsedTime

-> %IO - UserI/OTimeasa percentageofElapsedTime

-> Captured SQL account for53.9%ofTotal DBTime(s): 883,542

-> Captured PL/SQL account for0.5%ofTotal DBTime(s): 883,542

Elapsed Elapsed Time

Time(s) Executions perExec(s) %Total %CPU %IO SQL Id

---------------- -------------- ------------- ------ ------ ------ -------------

181,411.3 38,848 4.67 20.5 .0 .1 g0yc9szpuu068

注意對於PL/SQL，SQL Statistics不僅會體現該PL/SQL的執行情況，還會包括該PL/SQL包含的SQL語句的情況。如上例一個TOPPL/SQL執行了448s，而這448s中絕大多數是這個PL/SQL下的一個SQL執行500次耗費的。

則該TOPPL/SQL和TOPSQL都上榜，一個執行一次耗時448s，一個執行500次耗時448s。如此情況則ElapsedTime加起來可能超過100%的ElapsedTime，這是正常的。

對於鶴立雞群的SQL很有必要一探究竟，跑個@?/rdbms/admin/awrsqrpt看看吧！

Elapsed Time(s): 該SQL累計運行所消耗的時間，

Executions : 該SQL在快照時間內總計運行的次數；注意，對於在快照時間內還沒有執行完的SQL 不計為1一次，所以如果看到executions=0而又是TOPSQL，則很有可能是因為該SQL 運行較舊還沒執行完，需要特別關注一下。

Elapsed TimeperExec(s)：平均每次執行該SQL耗費的時間，對於OLTP類型的SELECT/INSERT/UPDATE/DELETE而言平均單次執行時間應當非常短，如0.1秒或者更短才能滿足其業務需求，如果這類輕微的OLTP操作單次也要幾秒鍾的話，是無法滿足對外業務的需求的；例如你在ATM上提款，並不僅僅是對你的賬務庫的簡單UPDATE，而需要在類似風險控制的前置系統中記錄你本次的流水操作記錄，實際取一次錢可能要有幾十乃至上百個OLTP類型的語句被執行，但它們應當都是十分快速的操作；如果這些操作也變得很慢，則會出現大量事務阻塞，系統負載升高，DBTIME急劇上升的現象。對於OLTP數據庫而言如果執行計划穩定，那么這些OLTP操作的性能應當是鐵板釘釘的，但是一旦某個因素發生變化，例如存儲的明顯變慢、內存換頁的大量出現時則上述的這些transaction操作很可能成數倍到幾十倍的變慢，這將讓此事務系統短期內不可用。

對於維護操作，例如加載或清除數據，大的跑批次、報表而言 Elapsed TimeperExec(s)高一些是正常的。

%Total 該SQL所消耗的時間占總的DB Time的百分比，即 (SQL ElapsedTime/ Total DBTIME)

% CPU 該SQL 所消耗的CPU 時間占該SQL消耗的時間里的比例，即 (SQL CPU Time/ SQL ElapsedTime) ，該指標說明了該語句是否是CPU敏感的

%IO 該SQL 所消耗的I/O 時間占該SQL消耗的時間里的比例，即(SQL I/O Time/SQL ElapsedTime) ，該指標說明了該語句是否是I/O敏感的

SQL Id : 通過計算SQL 文本獲得的SQL_ID ，不同的SQL文本必然有不同的SQL_ID，對於10g~11g而言只要SQL文本不變那么在數據庫之間該SQL 對應的SQL_ID應當不不變的， 12c中修改了SQL_ID的計算方法

Captured SQL account for53.9%ofTotal DBTime(s) 對於不綁定變量的應用來說TopSQL有可能失准，所以要參考本項

3-2 SQL ordered byCPUTime

SQL ordered byCPUTimeSnaps: 70719-70723

-> Resources reported forPL/SQL code includes the resources usedbyallSQL

statements called bythe code.

-> %Total - CPU Timeasa percentageofTotal DB CPU

-> %CPU - CPU Timeasa percentageofElapsedTime

-> %IO - UserI/OTimeasa percentageofElapsedTime

-> Captured SQL account for34.9%ofTotal CPUTime(s): 20,649

-> Captured PL/SQL account for0.5%ofTotal CPUTime(s): 20,649

CPU CPU per Elapsed

Time(s) ExecutionsExec(s) %TotalTime(s) %CPU %IO SQL Id

---------- ------------ ---------- ------ ---------- ------ ------ -------------

1,545.0 1,864,424 0.00 7.5 4,687.8 33.0 65.7 8g6a701j83c8q

Module: MZIndexer

SELECTt0.BOOLEAN_VALUE, t0.CLASS_CODE, t0.CREATED, t0.END_DATE, t0.PRODUCT_ATTR

IBUTE_ID, t0.LAST_MODIFIED, t0.OVERRIDE_FLAG, t0.PRICE, t0.PRODUCT_ATTRIBUTE_TYP

E_ID, t0.PRODUCT_ID, t0.PRODUCT_PUB_RELEASE_TYPE_ID, t0.PRODUCT_VOD_TYPE_ID, t0.

SAP_PRODUCT_ID, t0.START_DATE, t0.STRING_VALUE FROMmz_product_attribute t0 WHER

CPU TIME: 該SQL 在快照時間內累計執行所消耗的CPU 時間片，單位為s

Executions : 該SQL在快照時間內累計執行的次數

CPU per Exec(s) ：該SQL 平均單次執行所消耗的CPU時間，即 ( SQL CPUTIME/ SQL Executions )

%Total : 該SQL 累計消耗的CPU時間占該時段總的 DB CPU的比例，即 ( SQL CPU TIME/ Total DB CPU)

% CPU 該SQL 所消耗的CPU 時間占該SQL消耗的時間里的比例，即 (SQL CPU Time/ SQL ElapsedTime) ，該指標說明了該語句是否是CPU敏感的

%IO 該SQL 所消耗的I/O 時間占該SQL消耗的時間里的比例，即(SQL I/O Time/SQL ElapsedTime) ，該指標說明了該語句是否是I/O敏感的

3-3 Buffer Gets SQL ordered byGets

SQL ordered byGets DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723

-> Resources reported forPL/SQL code includes the resources usedbyallSQL

statements called bythe code.

-> %Total - Buffer Gets asa percentageofTotal Buffer Gets

-> %CPU - CPU Timeasa percentageofElapsedTime

-> %IO - UserI/OTimeasa percentageofElapsedTime

-> Total Buffer Gets: 2,021,476,421

-> Captured SQL account for68.2%ofTotal

Buffer Gets Elapsed

Gets Executions per Exec%TotalTime(s) %CPU %IO SQL Id

----------- ----------- ------------ ------ ---------- ------ ------ -----------

4.61155E+08 1,864,424 247.3 22.8 4,687.8 33.0 65.7 8g6a701j83c

注意 buffer gets 邏輯讀是消耗CPU TIME的重要源泉，但並不是說消耗CPUTIME的只有buffer gets。大多數情況下 SQLorderbyCPUTIME和 SQLorderbybuffers gets 2個部分的TOPSQL 及其排列順序都是一樣的，此種情況說明消耗最多buffer gets的就是消耗最多CPU 的SQL ，如果我們希望降低系統的CPU使用率，那么只需要調優SQL 降低buffer gets 即可。

但也並不是100%的情況都是如此， CPU TIME的消耗者還包括函數運算、PL/SQL 控制、Latch /Mutex 的Spin等等，所以SQLorderbyCPUTIME和 SQLorderbybuffers gets 2個部分的TOPSQL 完全不一樣也是有可能的，需要因地制宜來探究到底是什么問題導致的High CPU，進而裁度解決之道。

Buffer Gets : 該SQL在快照時間內累計運行所消耗的buffer gets，包括了consistent read和currentread

Executions : 該SQL在快照時間內累計執行的次數

Gets per Exec: 該SQL平均單次的buffer gets ，對於事務型transaction操作而言一般該單次buffer gets小於2000

% Total 該SQL 累計運行所消耗的buffer gets占總的db buffer gets的比率， (SQL buffer gets / DB total buffer gets)

3-4 Physical Reads SQL ordered byReads

SQL ordered byReads DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723

-> %Total - Physical Reads asa percentageofTotal Disk Reads

-> %CPU - CPU Timeasa percentageofElapsedTime

-> %IO - UserI/OTimeasa percentageofElapsedTime

-> Total Disk Reads: 56,839,035

-> Captured SQL account for34.0%ofTotal

Physical Reads Elapsed

Reads Executions per Exec%TotalTime(s) %CPU %IO SQL Id

----------- ----------- ---------- ------ ---------- ------ ------ -------------

9,006,163 1 9.0062E+06 15.8 720.9 5.9 80.9 4g36tmp70h185

Physical reads : 該SQL累計運行所消耗的物理讀

Executions : 該SQL在快照時間內累計執行的次數

Reads per Exec: 該SQL 單次運行所消耗的物理讀， (SQL Physical reads/Executions) ，對於OLTPtransaction類型的操作而言單次一般不超過100

%Total : 該SQL 累計消耗的物理讀占該時段總的物理讀的比例，即 ( SQL physical read/ Total DB physicalread)

3-5 Executions SQL ordered byExecutions

SQL ordered byExecutions Snaps: 70719-70723

-> %CPU - CPU Timeasa percentageofElapsedTime

-> %IO - UserI/OTimeasa percentageofElapsedTime

-> Total Executions: 48,078,147

-> Captured SQL account for50.4%ofTotal

Elapsed

Executions RowsProcessedRowsperExecTime(s) %CPU %IO SQL Id

------------ --------------- -------------- ---------- ------ ------ -----------

6,327,963 11,249,645 1.8 590.5 47.8 52.7 1avv7759j8r

按照執行次數來排序的話，也是性能報告對比時一個重要的參考因素，因為如果TOPSQL的執行次數有明顯的增長，那么性能問題的出現也是意料之中的事情了。當然執行次數最多的，未必便是對性能影響最大的TOPSQL

Executions : 該SQL在快照時間內累計執行的次數

RowsProcessed：該SQL在快照時間內累計執行所處理的總行數

RowsperExec：　SQL平均單次執行所處理的行數，這個指標在診斷一些數據問題造成的SQL性能問題時很有用

3-6 Parse Calls SQL ordered byParse Calls

SQL ordered byParse Calls Snaps: 70719-70723

-> Total Parse Calls: 2,160,124

-> Captured SQL account for58.3%ofTotal

% Total

Parse Calls Executions Parses SQL Id

------------ ------------ --------- -------------

496,475 577,357 22.98 d07gaa3wntdff

Parse Calls : 解析調用次數，與上文的 LoadProfile中的Parse 數一樣包括軟解析soft parse和硬解析hard parse

Executions : 該SQL在快照時間內累計執行的次數

%Total Parses : 本SQL 解析調用次數占該時段數據庫總解析次數的比率，為 (SQL Parse Calls / Total DB Parse Calls)

3-7 SQL ordered bySharable Memory

SQL ordered bySharable Memory Snaps: 70719-70723

-> OnlyStatementswithSharable Memory greater than 1048576 are displayed

Sharable Mem (b) Executions % Total SQL Id

---------------- ------------ -------- -------------

8,468,359 39 0.08 au89sasqfb2yn

Module: MZContentBridge

SELECTt0.ASPECT_RATIO, t0.CREATED, t0.FILE_EXTENSION, t0.HEIGHT, t0.VIDEO_FILE_

DIMENSIONS_ID, t0.LAST_MODIFIED, t0.NAME, t0.WIDTHFROMMZ_VIDEO_FILE_DIMENSIONS

t0 WHERE(t0.HEIGHT = :1ANDt0.WIDTH = :2 )

SQL ordered bySharable Memory , 一般該部分僅列出Sharable Mem (b)為1 MB以上的SQL 對象 (OnlyStatementswithSharable Memory greater than 1048576 are displayed) 數據來源是 DBA_HIST_SQLSTAT.SHARABLE_MEM

Shareable Mem(b): SQL 對象所占用的共享內存使用量

Executions : 該SQL在快照時間內累計執行的次數

%Total : 該SQL 對象鎖占共享內存占總的共享內存的比率

3-8 SQL ordered byVersionCount

Version CountOracle中的執行計划可以是多版本的，即對於同一個SQL語句有多個不同版本的執行計划，這些執行計划又稱作子游標，而一個SQL語句的文本可以稱作一個父游標。一個父游標對應多個子游標，產生不同子游標的原因是 SQL在被執行時無法共享之前已經生成的子游標，原因是多種多樣的，例如在本session中做了一個優化器參數的修改例如optimizer_index_cost_adj 從100 修改到99，則本session的優化環境optimizer env將不同於之前的子游標生成環境，這樣就需要生成一個新的子游標，例如：

SQL> createtableempasselect*fromscott.emp;

Tablecreated.

SQL> select*fromempwhereempno=1;

norowsselected

SQL> select/*+ MACLEAN */ *fromempwhereempno=1;

norowsselected

SQL> selectSQL_ID,version_countfromV$SQLAREAWHERESQL_TEXTlike'%MACLEAN%'andSQL_TEXTnotlike'%like%';

SQL_ID VERSION_COUNT

------------- -------------

bxnnm7z1qmg26 1

SQL> selectcount(*)fromv$SQLwhereSQL_ID='bxnnm7z1qmg26';

COUNT(*)

----------

SQL> altersessionsetoptimizer_index_cost_adj=99;

Session altered.

SQL> select/*+ MACLEAN */ *fromempwhereempno=1;

norowsselected

SQL> selectSQL_ID,version_countfromV$SQLAREAWHERESQL_TEXTlike'%MACLEAN%'andSQL_TEXTnotlike'%like%';

SQL_ID VERSION_COUNT

------------- -------------

bxnnm7z1qmg26 2

SQL> selectcount(*)fromv$SQLwhereSQL_ID='bxnnm7z1qmg26';

COUNT(*)

----------

SQL> selectchild_number ,OPTIMIZER_ENV_HASH_VALUE,PLAN_HASH_VALUEfromv$SQLwhereSQL_ID='bxnnm7z1qmg26';

CHILD_NUMBER OPTIMIZER_ENV_HASH_VALUE PLAN_HASH_VALUE

------------ ------------------------ ---------------

0 3704128740 3956160932

1 3636478958 3956160932

可以看到上述演示中修改optimizer_index_cost_adj=99 導致CBO 優化器的優化環境發生變化，表現為不同的OPTIMIZER_ENV_HASH_VALUE，之后生成了2個子游標，但是這2個子游標的PLAN_HASH_VALUE同為3956160932，則說明了雖然是不同的子游標但實際子游標里包含了的執行計划是一樣的；所以請注意任何一個優化環境的變化 (V$SQL_SHARED_CURSOR)以及相關衍生的BUG 都可能導致子游標無法共享，雖然子游標無法共享但這些子游標扔可能包含完全一樣的執行計划，這往往是一種浪費。

注意V$SQLAREA.VERSION_COUNT 未必等於selectcount(*)FROMV$SQLWHERESQL_ID=” ，即 V$SQLAREA.VERSION_COUNT 顯示的子游標數目未必等於當前實例中還存有的子游標數目，由於shared pool agedout算法和其他一些可能導致游標失效的原因存在，所以子游標被清理掉是很常見的事情。 V$SQLAREA.VERSION_COUNT只是一個計數器，它告訴我們曾經生成了多少個childcursor，但不保證這些child 都還在shared pool里面。

此外可以通過v$SQL的child_number字段來分析該問題，如果child_number存在跳號則也說明了部分child被清理了。

子游標過多的影響，當子游標過多(例如超過3000個時),進程需要去掃描長長的子游標列表child cursorlist以找到一個合適的子游標childcursor，進而導致cursorsharing 性能問題現大量的Cursor: Mutex S 和 library cache lock等待事件。

關於子游標的數量控制，可以參考《11gR2游標共享新特性帶來的一些問題以及_cursor_features_enabled、_cursor_obsolete_threshold和106001 event》。

Executions : 該SQL在快照時間內累計執行的次數

Hash Value : 共享SQL 的哈希值

OnlyStatementswithVersionCountgreater than 20 are displayed 注意該環節僅列出versioncount> 20的語句

3-9 Cluster Wait TimeSQL orderedbyCluster WaitTime

SQL ordered byCluster WaitTimeDB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723

-> %Total - Cluster Timeasa percentageofTotal Cluster WaitTime

-> %Clu - Cluster Timeasa percentageofElapsedTime

-> %CPU - CPU Timeasa percentageofElapsedTime

-> %IO - UserI/OTimeasa percentageofElapsedTime

-> OnlySQLwithCluster WaitTime> .005 secondsisreported

-> Total Cluster Wait Time(s): 525,480

-> Captured SQL account for57.2%ofTotal

Cluster Elapsed

Wait Time(s) Executions %TotalTime(s) %Clu %CPU %IO SQL Id

-------------- ------------ ------ ---------- ------ ------ ------ -------------

132,639.3 38,848 25.2 181,411.3 73.1 .0 .1 g0yc9szpuu068

OnlySQLwithCluster WaitTime> .005 secondsisreported 這個環節僅僅列出Cluster WaitTime> 0.005 s的SQL

該環節的數據主要來源於 DBA_HIST_SQLSTAT.CLWAIT_DELTA Delta value ofcluster waittime

Cluster Wait Time: 該SQL語句累計執行過程中等待在集群等待上的時間，單位為秒，你可以理解為當一個SQL 執行過程中遇到了gc buffer busy、gc cr multi block request 之類的Cluster等待，則這些等待消耗的時間全部算在 Cluster WaitTime里。

Executions : 該SQL在快照時間內累計執行的次數

%Total: 該SQL所消耗的Cluster Wait time占總的Cluster Waittime的比率，為(SQL cluster waittime/ DB total cluster WaitTime)

%Clu: 該SQL所消耗的Cluster Wait time占該SQL 總的耗時的比率，為(SQL cluster waittime/ SQL elapsedTime),該指標說明了該語句是否是集群等待敏感的

% CPU 該SQL 所消耗的CPU 時間占該SQL消耗的時間里的比例，即 (SQL CPU Time/ SQL ElapsedTime) ，該指標說明了該語句是否是CPU敏感的

%IO 該SQL 所消耗的I/O 時間占該SQL消耗的時間里的比例，即(SQL I/O Time/SQL ElapsedTime) ，該指標說明了該語句是否是I/O敏感的

4 Instance Activity Stats

Instance Activity Stats DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723

-> Ordered bystatisticname

Statistic Total per Secondper Trans

-------------------------------- ------------------ -------------- -------------

Batched IO (bound) vector count450,449 124.6 1.8

Batched IO (full) vectorcount5,485 1.5 0.0

Batched IO (space) vectorcount1,467 0.4 0.0

Batched IO block miss count4,119,070 1,139.7 16.7

Batched IO buffer defrag count39,710 11.0 0.2

Batched IO doublemisscount297,357 82.3 1.2

Batched IO same unit count1,710,492 473.3 7.0

Batched IO single block count329,521 91.2 1.3

Batched IO slow jump count47,104 13.0 0.2

Batched IO vector block count2,069,852 572.7 8.4

Batched IO vector readcount262,161 72.5 1.1

Block Cleanout Optim referenced 37,574 10.4 0.2

CCursor + sql area evicted 1,457 0.4 0.0

...............

Instance Activity Stats 的數據來自於 DBA_HIST_SYSSTAT，DBA_HIST_SYSSTAT來自於V$SYSSTAT。

這里每一個指標都代表一種數據庫行為的活躍度，例如redo size是指生成redo的量，sorts (disk) 是指磁盤排序的次數，tablescans (directread) 是指直接路徑掃描表的次數。

雖然這些指標均只有Total、per Second每秒、 per Trans每事務三個維度，但對診斷問題十分有用。

我們來舉幾個例子：

1、例如當 TopEvent 中存在direct pathread為Top等待事件，則需要分清楚是對普通堆表的directread還是由於大量LOB讀造成的direct pathread，這個問題可以借助tablescans (directread)、tablescans (long tables)、physical reads direct 、physical reads direct (lob) 、physical reads directtemporary幾個指標來分析，假設 physical reads direct >> 遠大於 physical reads direct (lob)+physical reads directtemporary，且有較大的tablescans (directread)、tablescans (long tables) (注意這2個指標代表的是掃描表的次數不同於上面的phsical reads 的單位為塊數*次數)，則說明了是大表掃描引起的direct pathread。

2、例如當 TopEvent中存在enq Tx:indexcontention等待事件，則需要分析root node splits 、branch node splits 、leaf node 90-10 splits 、leaf node splits 、failed probesonindexblock rec 幾個指標，具體可以見文檔《Oracle索引塊分裂split信息匯總》

3、系統出現IO類型的等待事件為TOpFive 例如 db file sequential/scatteredread，我們需要通過AWR來獲得系統IO吞吐量和IOPS:

physical readbytes 主要是應用造成的物理讀取(Totalsizeinbytesofalldisk readsbyapplication activity (andnotother instance activity)only.) 而physicalreadtotal bytes則包括了 rman備份恢復和后台維護任務所涉及的物理讀字節數，所以我們在研究IO負載時一般參考 physicalreadtotal bytes；以下4對指標均存在上述的關系

physical readbytes physicalreadtotal bytes 物理讀的吞吐量/秒

physical readIO requests physicalreadtotal IO requests 物理讀的IOPS

physical write bytes physical write total bytes 物理寫的吞吐量/秒

physical write IO requests physical write total IO requests 物理寫的IOPS

總的物理吞吐量/秒=physical readtotal bytes+physical write total bytes

總的物理IOPS= physical readtotal IO requests+ physical write total IO requests

IO的主要指標吞吐量、IOPS和延遲均可以從AWR中獲得了， IO延遲的信息可以從 UserI/O的Wait ClassAvgWaittime獲得，也可以參考11g出現的IOStatbyFunctionsummary

Instance Activity Stats有大量的指標，但是對於這些指標的介紹沒有那一份文檔有完整詳盡的描述，即便在Oracle原廠內部要沒有(或者是Maclean沒找到)，實際是開發人員要引入某一個Activity Stats是比較容易的，並不像申請引入一個新后台進程那樣麻煩，Oracle對於新版本中新后台進程的引入有嚴格的要求，但Activity Stats卻很容易，往往一個one-offpatch中就可以引入了，實際上Activity Stats在源代碼層僅僅是一些計數器。’

較為基礎的statistics，大家可以參考官方文檔的StatisticsDescriptions描述，地址在這里。

對於深入的指標例如 “Batched IO (space) vectorcount”這種由於某些新特性被引入的，一般沒有很詳細的材料，需要到源代碼中去閱讀相關模塊才能總結其用途，對於這個工作一般原廠是很延遲去完成的，所以沒有一個完整的列表。如果大家有對此的疑問，請去t.askmaclean.com 發一個帖子提問。

Instance Activity Stats - AbsoluteValuesSnaps: 7071

-> Statisticswithabsolutevalues(shouldnotbe diffed)

Statistic BeginValueEndValue

-------------------------------- --------------- ---------------

session pga memory max1.157882826E+12 1.154290304E+12

session cursorcachecount157,042,373 157,083,136

session uga memory 5.496429019E+14 5.496775467E+14

opened cursors current268,916 265,694

workarea memory allocated 827,704 837,487

logons current2,609 2,613

session uga memory max1.749481584E+13 1.749737418E+13

session pga memory 4.150306913E+11 4.150008177E+11

Instance Activity Stats – AbsoluteValues是顯示快照起點和終點的一些指標的絕對值

◾logon current當前時間點的登錄數

◾opened cursors current當前打開的游標數

◾session cursorcachecount當前存在的session緩存游標數

Instance Activity Stats - Thread ActivityDB/Inst: G10R25/G10R25 Snaps: 3663-3

-> Statisticsidentifiedby'(derived)'comefromsources other than SYSSTAT

Statistic Total per Hour

-------------------------------- ------------------ ---------

log switches (derived) 17 2,326.47

log switches (derived) 日志切換次數，見《理想的在線重做日志切換時間是多長？》

5 IO 統計

5-1 Tablespace IO Stats 基於表空間分組的IO信息

Tablespace IO Stats DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723

-> ordered byIOs (Reads + Writes)desc

Tablespace

------------------------------

Av Av Av Av Buffer Av Buf

Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)

-------------- ------- ------- ------- ------------ -------- ---------- -------

DATA_TS

17,349,398 4,801 2.3 1.5 141,077 39 4,083,704 5.8

INDEX_TS

9,193,122 2,544 2.0 1.0 238,563 66 3,158,187 46.1

UNDOTBS1

1,582,659 438 0.7 1.0 2 0 12,431 69.0

reads : 指該表空間上發生的物理讀的次數(單位不是塊，而是次數)

Av Reads/s : 指該表空間上平均每秒的物理讀次數 (單位不是塊，而是次數)

Av Rd(ms): 指該表空間上每次讀的平均讀取延遲

Av Blks/Rd: 指該表空間上平均每次讀取的塊數目，因為一次物理讀可以讀多個數據塊；如果Av Blks/Rd>>1 則可能系統有較多db file scattered read可能是診斷FULLTABLESCAN或FASTFULLINDEXSCAN，需要關注tablescans (long tables) 和indexfastfullscans (full) 2個指標

Writes : 該表空間上發生的物理寫的次數 ; 對於那些Writes總是等於0的表空間不妨了解下是否數據為只讀，如果是可以通過readonlytablespace來解決 RAC中的一些性能問題。

Av Writes/s : 指該表空間上平均每秒的物理寫次數

buffer Waits: 該表空間上發生buffer busy waits和readbyother session的次數( 9i中buffer busy waits包含了readbyother session)。

Av Buf Wt(ms): 該表空間上發生buffer Waits的平均等待時間，單位為ms

5-2 File I/O

File IO Stats Snaps: 70719-70723

-> ordered byTablespace, File

Tablespace Filename

------------------------ ----------------------------------------------------

Av Av Av Av Buffer Av Buf

Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)

-------------- ------- ------- ------- ------------ -------- ---------- -------

AMG_ALBUM_IDX_TS +DATA/itscmp/plugged/data2/amg_album_idx_ts01.dbf

23,298 6 0.6 1.0 2 0 0 0.0

AMG_ALBUM_IDX_TS +DATA/itscmp/plugged/data3/amg_album_idx_ts02.dbf

3,003 1 0.6 1.0 2 0 0 0.0

Tablespace 表空間名

FileName 數據文件的路徑

Reads: 該數據文件上累計發生過的物理讀次數，不是塊數

Av Reads/s: 該數據文件上平均每秒發生過的物理讀次數，不是塊數

Av Rd(ms): 該數據文件上平均每次物理讀取的延遲，單位為ms

Av Blks/Rd: 該數據文件上平均每次讀取涉及到的塊數，OLTP環境該值接近 1

Writes : 該數據文件上累計發生過的物理寫次數，不是塊數

Av Writes/s: 該數據文件上平均每秒發生過的物理寫次數，不是塊數

buffer Waits: 該數據文件上發生buffer busy waits和readbyother session的次數( 9i中buffer busy waits包含了readbyother session)。

Av Buf Wt(ms): 該數據文件上發生buffer Waits的平均等待時間，單位為ms

若某個表空間上有較高的IO負載，則有必要分析一下是否其所屬的數據文件上的IO 較為均勻還是存在傾斜，是否需要結合存儲特征來將數據均衡分布到不同磁盤上的數據文件上，以優化 I/O

6 緩沖池統計 Buffer Pool Statistics

Buffer Pool StatisticsSnaps: 70719-70723

-> Standard block sizePools D:default, K: keep, R: recycle

-> DefaultPoolsforother block sizes: 2k, 4k, 8k, 16k, 32k

FreeWrit Buffer

Number ofPool Buffer Physical Physical Buff Comp Busy

P Buffers Hit% Gets Reads Writes Wait Wait Waits

--- ---------- ---- ------------ ------------ ----------- ------ ------ --------

16k 15,720 N/A 0 0 0 0 0 0

D 2,259,159 98 2.005084E+09 42,753,650 560,460 0 1 8.51E+06

該環節的數據主要來源於WRH$_BUFFER_POOL_STATISTICS，而WRH$_BUFFER_POOL_STATISTICS是定期匯總v$SYSSTAT中的數據

P pool池的名字 D: 默認的緩沖池 defaultbuffer pool , K : Keep Pool , R: Recycle Pool ; 2k 4k 8k 16k 32k: 代表各種非標准塊大小的緩沖池

Number ofbuffers: 實際的緩沖塊數目，約等於池的大小 / 池的塊大小

Pool Hit % : 該緩沖池的命中率

Buffer Gets: 對該緩沖池的中塊的訪問次數包括 consistent gets 和 db block gets

Physical Reads: 該緩沖池Buffer Cache引起了多少物理讀，其實是physical reads cache ，單位為塊數*次數

Physical Writes ：該緩沖池中Buffer cache被寫的物理寫，其實是physical writes fromcache，單位為塊數*次數

FreeBuffer Waits: 等待空閑緩沖的次數，可以看做該buffer pool 發生freebuffer waits 等待的次數

Write Comp Wait: 等待DBWR寫入臟buffer到磁盤的次數，可以看做該buffer pool發生write complete waits等待的次數

Buffer Busy Waits: 該緩沖池發生buffer busy wait 等待的次數

7-1 CheckpointActivity 檢查點與 Instance Recovery Stats 實例恢復

CheckpointActivity Snaps: 70719-70723

-> Total Physical Writes: 590,563

Other Autotune Thread

MTTR Log SizeLog Ckpt Settings Ckpt Ckpt

Writes Writes Writes Writes Writes Writes

----------- ----------- ----------- ----------- ----------- -----------

0 0 0 0 12,899 0

-------------------------------------------------------------

Instance Recovery Stats Snaps: 70719-70723

-> B: BeginSnapshot, E:EndSnapshot

Estd

Targt Estd Log Ckpt Log Ckpt Opt RAC

MTTR MTTR Recovery Actual Target Log Sz Timeout Interval Log Avail

(s) (s) Estd IOs RedoBlks RedoBlks RedoBlks RedoBlks RedoBlks Sz(M) Time

- ----- ----- -------- -------- -------- -------- -------- -------- ------ -----

B 0 6 12828 477505 1786971 5096034 1786971 N/A N/A 3

E 0 7 16990 586071 2314207 5096034 2314207 N/A N/A 3

-------------------------------------------------------------

該環節的數據來源於WRH$_INSTANCE_RECOVERY

MTTR Writes : 為了滿足FAST_START_MTTR_TARGET 指定的MTTR值而做出的物理寫 WRITES_MTTR

Log SizeWrites ：由於最小的redo log file而做出的物理寫 WRITES_LOGFILE_SIZE

Log Ckpt writes: 由於 LOG_CHECKPOINT_INTERVAL 和 LOG_CHECKPOINT_TIMEOUT 驅動的增量檢查點而做出的物理寫 WRITES_LOG_CHECKPOINT_SETTINGS

Other Settings Writes ：由於其他設置(例如FAST_START_IO_TARGET)而引起的物理寫， WRITES_OTHER_SETTINGS

Autotune Ckpt Writes : 由於自動調優檢查點而引起的物理寫， WRITES_AUTOTUNE

Thread Ckpt Writes ：由於thread checkpoint而引起的物理寫，WRITES_FULL_THREAD_CKPT

B 代表開始點， E 代表結尾

Targt MTTR (s) : 目標MTTR (mean timetorecover)意為有效恢復時間，單位為秒。 TARGET_MTTR 的計算基於給定的參數FAST_START_MTTR_TARGET，而TARGET_MTTR作為內部使用。實際在使用中 Target MTTR未必能和FAST_START_MTTR_TARGET一樣。如果FAST_START_MTTR_TARGET過小，那么TARGET_MTTR 將是系統條件所允許的最小估算值；如果FAST_START_MTTR_TARGET過大，則TARGET_MTTR以保守算法計算以獲得完成恢復的最長估算時間。

estimated_mttr (s): 當前基於臟buffer和重做日志塊的數量，而評估出的有效恢復時間。它的估算告訴用戶以當下系統的負載若發生實例crash，則需要多久時間來做crash recovery的前滾操作，之后才能打開數據庫。

Recovery Estd IOs ：實際是當前buffer cache中的臟塊數量，一旦實例崩潰這些臟塊要被前滾

Actual RedoBlks ：當前實際需要恢復的redo重做塊數量

Target RedoBlks ：是 Log Sz RedoBlks 、Log Ckpt Timeout RedoBlks、 Log Ckpt Interval RedoBlks 三者的最小值

Log Sz RedoBlks : 代表必須在log file switch日志切換之前完成的 checkpoint中涉及到的redo block，也叫maxlog lag；數據來源selectLOGFILESZfromX$targetrba;selectLOG_FILE_SIZE_REDO_BLKSfromv$instance_recovery;

Log Ckpt Timeout RedoBlks ：為了滿足LOG_CHECKPOINT_TIMEOUT 所需要處理的redo block數，lag forcheckpointtimeout ；數據來源selectCT_LAGfromx$targetrba;

Log Ckpt Interval RedoBlks ：為了滿足LOG_CHECKPOINT_INTERVAL 所需要處理的redo block數， lag forcheckpointinterval；數據來源selectCI_LAGfromx$targetrba;

Opt Log Sz(M) : 基於FAST_START_MTTR_TARGET 而估算出來的redo logfile 的大小，單位為MB 。 Oracle官方推薦創建的重做日志大小至少大於這個估算值

Estd RAC Avail Time：指評估的 RAC中節點失敗后集群從凍結到部分可用的時間，這個指標僅在RAC中可用，單位為秒。 ESTD_CLUSTER_AVAILABLE_TIME

7-2 Buffer Pool Advisory 緩沖池建議

Buffer Pool Advisory DB/Inst: ITSCMP/itscmp2 Snap: 70723

-> Onlyrowswithestimated physical reads >0 are displayed

-> ordered byBlockSize, BuffersForEstimate

Est

Phys Estimated Est

SizeforSizeBuffersReadPhys Reads Est Phys %DBtime

P Est (M) Factor (thousands) Factor (thousands) ReadTimeforRds

--- -------- ------ ------------ ------ -------------- ------------ -------

D 1,920 .1 227 4.9 1,110,565,597 1 1.0E+09

D 3,840 .2 454 3.6 832,483,886 1 7.4E+08

D 5,760 .3 680 2.8 634,092,578 1 5.6E+08

D 7,680 .4 907 2.2 500,313,589 1 4.3E+08

D 9,600 .5 1,134 1.8 410,179,557 1 3.5E+08

D 11,520 .6 1,361 1.5 348,214,283 1 2.9E+08

D 13,440 .7 1,588 1.3 304,658,441 1 2.5E+08

D 15,360 .8 1,814 1.2 273,119,808 1 2.2E+08

D 17,280 .9 2,041 1.1 249,352,943 1 2.0E+08

D 19,200 1.0 2,268 1.0 230,687,206 1 1.8E+08

D 19,456 1.0 2,298 1.0 228,664,269 1 1.8E+08

D 21,120 1.1 2,495 0.9 215,507,858 1 1.7E+08

D 23,040 1.2 2,722 0.9 202,816,787 1 1.6E+08

D 24,960 1.3 2,948 0.8 191,974,196 1 1.5E+08

D 26,880 1.4 3,175 0.8 182,542,765 1 1.4E+08

D 28,800 1.5 3,402 0.8 174,209,199 1 1.3E+08

D 30,720 1.6 3,629 0.7 166,751,631 1 1.2E+08

D 32,640 1.7 3,856 0.7 160,002,420 1 1.2E+08

D 34,560 1.8 4,082 0.7 153,827,351 1 1.1E+08

D 36,480 1.9 4,309 0.6 148,103,338 1 1.1E+08

D 38,400 2.0 4,536 0.6 142,699,866 1 1.0E+08

緩沖池的顆粒大小可以參考 SELECT*FROMV$SGAINFOwherenamelike(‘Granule%’);

P 指緩沖池的名字可能包括有 D defaultbuffer pool , K Keep Pool , R recycle Pool

SizeForEst(M): 指以該尺寸的buffer pool作為評估的對象，一般是目前currentsize的 10% ~ 200%，以便了解 buffer pool 增大 ~減小對物理讀的影響

SizeFactor : 尺寸因子，只對應buffer pool 大小對當前設置的比例因子，例如current_size是 100M ，則如果評估值是110M 那么sizeFactor 就是 1.1

Buffers (thousands) ：指這個buffer pool 尺寸下的buffer 數量，要乘以1000才是實際值

Est Phys ReadFactor ：評估的物理讀因子，　例如當前尺寸的buffer pool 會引起100個物理讀，則別的尺寸的buffer pool如果引起 120個物理讀，那么對應尺寸的Est PhysReadFactor就是1.2

Estimated Phys Reads (thousands)：評估的物理讀數目，　要乘以　1000才是實際值，顯然不同尺寸的buffer pool對應不同的評估的物理讀數目

Est Phys ReadTime：評估的物理讀時間

Est %DBtime forRds：評估的物理讀占DBTIME的比率

我們看buffer pool advisory 一般有2個目的：

1.在物理讀較多的情況下，希望通過增加buffer pool 大小來緩解物理讀等待，這是我們關注SizeFactor > 1的buffer pool尺寸是否能共有效減少Est PhysReadFactor，如果Est PhysReadFactor隨着SizeFactor 增大而顯著減少，那么說明增大buffer cache 是可以有效減少物理讀的。

2. 在內存緊張的情況下，希望從buffer pool中勻出部分內存來移作他用，但是又不希望 buffer cache變小導致物理讀增多性能下降，則此時觀察Est Phys ReadFactor 是否隨着SizeFactor 減小而顯著增大，如果不是則說明減少部分buffer cache 不會導致物理讀大幅增加，也就可以安心減少 buffer cache

注意 SizeFactor 和 Est PhysReadFactor之間不是簡單的線性關系，所以需要人為介入評估得失

7-3 PGA Aggr Summary

PGA Aggr Summary Snaps: 70719-70723

-> PGA cache hit % - percentage ofW/A (WorkArea) data processedonlyin-memory

PGA Cache Hit % W/A MB Processed Extra W/A MB Read/Written

--------------- ------------------ --------------------------

99.9 412,527 375

PGA Cache Hit % : 指 W/A WorkArea工作區的數據僅在內存中處理的比率， PGA緩存命中率

workarea是PGA中負責處理排序、哈希連接和位圖合並操作的區域; workarea 也叫做 SQL 作業區域

W/A MB processes: 指在Workarea中處理過的數據的量，單位為MB

Extra W/A MB Read/Written : 指額外從磁盤上讀寫的工作區數據，單位為 MB

7-4 PGA Aggr Target Stats

Warning: pga_aggregate_target was settoo lowforcurrentworkload,asthis

value was exceeded during this interval. Use the PGA Advisory view

tohelp identify a different valueforpga_aggregate_target.

PGA Aggr Target Stats Snaps: 70719-70723

-> B: BeginSnap E:EndSnap (rowsdentifiedwithBorE contain data

which isabsolutei.e.notdiffed over the interval)

-> Auto PGA Target - actual workarea memory target

-> W/A PGA Used - amount ofmemory usedforallWorkareas (manual + auto)

-> %PGA W/A Mem - percentage ofPGA memory allocatedtoworkareas

-> %Auto W/A Mem - percentage ofworkarea memory controlledbyAuto Mem Mgmt

-> %Man W/A Mem - percentage ofworkarea memory under manual control

%PGA %Auto %Man

PGA Aggr Auto PGA PGA Mem W/A PGA W/A W/A W/A GlobalMem

Target(M) Target(M) Alloc(M) Used(M) Mem Mem Mem Bound(K)

- ---------- ---------- ---------- ---------- ------ ------ ------ ----------

B 8,192 512 23,690.5 150.1 .6 100.0 .0 838,860

E 8,192 512 23,623.6 156.9 .7 100.0 .0 838,860

-------------------------------------------------------------

此環節的數據來源主要是 WRH$_PGASTAT

PGA Aggr Target(M) ：本質上就是pga_aggregate_target ，當然在AMM(memory_target)環境下這個值可能會自動變化

Auto PGA Target(M) : 在自動PGA 管理模式下實際可用的工作區內存 “aggregate PGA auto target “，因為PGA還有其他用途，不能全部作為workarea memory

PGA Mem Alloc(M) ：目前已分配的PGA內存，　alloc 不等於 inuse 即分配的內存不等於在使用的內存，理論上PGA會將確實不使用的內存返回給OS(PGA memory freed back toOS) ，但是存在PGA占用大量內存而不釋放的場景

在上例中 pga_aggregate_target 僅為8192M ，而實際processes 在 2,615~ 8000之間，如果一個進程耗費5MB的PGA 也需要 10000M的PGA ，而實際這里 PGA Mem Alloc(M)是23,690 M ，這說明存在PGA 的過載，需要調整pga_aggregate_target

W/A PGA Used(M) ：所有的工作區workarea(包括manual和 auto)使用的內存總和量，單位為MB

%PGA W/A Mem: 分配給workarea的內存量占總的PGA的比例， (W/A PGA Used)/PGA Mem Alloc

%Auto W/A Mem : AUTO 自動工作區管理所控制的內存(workarea_size_policy=AUTO) 占總的workarea內存的比例

%Man W/A Mem : MANUAL 手動工作區管理所控制的內存(workarea_size_policy=MANUAL)占總的workarea內存的比例

GlobalMem Bound(K) : 指在自動PGA管理模式下一個工作區所能分配的最大內存(注意一個SQL執行過程中可能有多個工作區workarea)。GlobalMem Bound(K)這個指標在實例運行過程中將被持續性的修正，以反應數據庫當時工作區的負載情況。顯然在有眾多活躍工作區的系統負載下相應地GlobalMem Bound將會下降。但應當保持globalbound值不要小於1 MB ，否則建議調高pga_aggregate_target

7-5 PGA Aggr Target Histogram

PGA Aggr Target Histogram Snaps: 70719-70723

-> Optimal Executions are purely in-memory operations

Low High

Optimal Optimal Total Execs Optimal Execs 1-Pass Execs M-Pass Execs

------- ------- -------------- -------------- ------------ ------------

2K 4K 262,086 262,086 0 0

64K 128K 497 497 0 0

128K 256K 862 862 0 0

256K 512K 368 368 0 0

512K 1024K 440,585 440,585 0 0

1M 2M 68,313 68,313 0 0

2M 4M 169 161 8 0

4M 8M 50 42 8 0

8M 16M 82 82 0 0

16M 32M 1 1 0 0

32M 64M 12 12 0 0

128M 256M 2 0 2 0

-------------------------------------------------------------

數據來源：WRH$_SQL_WORKAREA_HISTOGRAM

Low Optimal：此行所包含工作區workarea最適合內存要求的下限

High Optimal：此行所包含工作區workarea最適合內存要求的上限

Total Execs: 在 Low Optimal~High Optimal 范圍工作區內完成的總執行數

Optimal execs: optimal 執行是指完全在PGA內存中完成的執行次數

1-pass Execs : 指操作過程中僅發生1次磁盤讀取的執行次數

M-pass Execs: 指操作過程中發生了1次以上的磁盤讀取，頻發磁盤讀取的執行次數

7-6 PGA Memory Advisory

PGA Memory Advisory Snap: 70723

-> Whenusing Auto Memory Mgmt, minimally choose a pga_aggregate_target value

whereEstd PGA OverallocCountis0

Estd Extra Estd P Estd PGA

PGA Target SizeW/A MB W/A MBRead/ Cache Overallo Estd

Est (MB) Factr Processed Written toDisk Hit %CountTime

---------- ------- ---------------- ---------------- ------ -------- -------

1,024 0.1 2,671,356,938.7 387,531,258.9 87.0 1.07E+07 7.9E+11

2,048 0.3 2,671,356,938.7 387,529,979.1 87.0 1.07E+07 7.9E+11

4,096 0.5 2,671,356,938.7 387,518,881.8 87.0 1.07E+07 7.9E+11

6,144 0.8 2,671,356,938.7 387,420,749.5 87.0 1.07E+07 7.9E+11

8,192 1.0 2,671,356,938.7 23,056,196.5 99.0 1.07E+07 6.9E+11

9,830 1.2 2,671,356,938.7 22,755,192.6 99.0 6.81E+06 6.9E+11

11,469 1.4 2,671,356,938.7 20,609,438.5 99.0 4.15E+06 6.9E+11

13,107 1.6 2,671,356,938.7 19,021,139.1 99.0 581,362 6.9E+11

14,746 1.8 2,671,356,938.7 18,601,191.0 99.0 543,531 6.9E+11

16,384 2.0 2,671,356,938.7 18,561,361.1 99.0 509,687 6.9E+11

24,576 3.0 2,671,356,938.7 18,527,422.3 99.0 232,817 6.9E+11

32,768 4.0 2,671,356,938.7 18,511,872.6 99.0 120,180 6.9E+11

49,152 6.0 2,671,356,938.7 18,500,815.3 99.0 8,021 6.9E+11

65,536 8.0 2,671,356,938.7 18,498,733.0 99.0 0 6.9E+11

PGA Target Est (MB) 用以評估的 PGA_AGGREGATE _TARGET值

SizeFactr ，當前用以評估的PGA_AGGREGATE _TARGET 和當前實際設置的PGA_AGGREGATE _TARGET 之間的比例因子 PGA Target Est / PGA_AGGREGATE_TARGE

W/A MB Processed ：workarea中要處理的數據量，單位為MB

Estd Extra W/A MB Read/ WrittentoDisk : 以 one-pass 、M-Pass方式處理的數據量預估值，單位為MB

Estd P Cache Hit % : 預估的PGA緩存命中率

Estd PGA Overalloc Count: 預估的PGA過載量，如上文所述PGA_AGGREGATE _TARGET僅是一個目標值，無法真正限制PGA內存的使用，當出現 PGA內存硬性需求時會產生PGA overallocate 過載(Whenusing Auto Memory Mgmt, minimally choose a pga_aggregate_target valuewhereEstd PGA OverallocCountis0)

7-7 Shared Pool Advisory

Shared Pool Advisory Snap: 70723

-> SP: Shared Pool Est LC: Estimated Library Cache Factr: Factor

-> Note there isoften a 1:Many correlationbetweena single logical object

inthe Library Cache,andthe physical numberofmemory objects associated

withit. Therefore comparing the numberofLib Cache objects (e.g.in

v$librarycache), withthe numberofLib Cache Memory Objectsisinvalid.

Est LC Est LC Est LC Est LC

Shared SP Est LC TimeTimeLoadLoadEst LC

Pool SizeSizeEst LC Saved SavedTimeTimeMem Obj

Size(M) Factr (M) Mem Obj (s) Factr (s) Factr Hits (K)

-------- ----- -------- ------------ -------- ------ ------- ------ ------------

304 .8 56 3,987 7,728 1.0 61 1.4 332

352 .9 101 6,243 7,745 1.0 44 1.0 334

400 1.0 114 7,777 7,745 1.0 44 1.0 334

448 1.1 114 7,777 7,745 1.0 44 1.0 334

496 1.2 114 7,777 7,745 1.0 44 1.0 334

544 1.4 114 7,777 7,745 1.0 44 1.0 334

592 1.5 114 7,777 7,745 1.0 44 1.0 334

640 1.6 114 7,777 7,745 1.0 44 1.0 334

688 1.7 114 7,777 7,745 1.0 44 1.0 334

736 1.8 114 7,777 7,745 1.0 44 1.0 334

784 2.0 114 7,777 7,745 1.0 44 1.0 334

832 2.1 114 7,777 7,745 1.0 44 1.0 334

-------------------------------------------------------------

Shared Pool Size(M) : 用以評估的shared pool共享池大小，在AMM /ASMM環境下 shared_pool 大小都可能浮動

SP SizeFactr ：共享池大小的比例因子，　(Shared PoolSizeforEstim / SHARED_POOL_SIZE)

Estd LC Size(M) : 評估的 library cache 大小，單位為MB ，因為是shared pool中包含 library cache 當然還有其他例如row cache

Est LC Mem Obj 指評估的指定大小的共享池內的library cache memory object的數量 ESTD_LC_MEMORY_OBJECTS

Est LC TimeSaved(s): 指在指定的共享池大小情況下可找到需要的library cache memory objects，從而節約的解析時間。這些節約的解析時間也是花費在共享池內重復加載需要的對象(reload)，這些對象可能因為共享池沒有足夠的freememory而被agedout. ESTD_LC_TIME_SAVED

Est LC TimeSaved Factr : Est LCTimeSaved(s)的比例因子，( Est LCTimeSaved(s)/CurrentLCTimeSaved(s) ) ESTD_LC_TIME_SAVED_FACTOR

Est LC LoadTime(s): 在指定的共享池大小情況下解析的耗時

Est LC LoadTimeFactr：Est LCLoadTime(s)的比例因子， (Est LCLoadTime(s)/CurrentLCLoadTime(s)) ESTD_LC_LOAD_TIME_FACTOR

Est LC Mem Obj Hits (K) : 在指定的共享池大小情況下需要的library cache memory object正好在共享池中被找到的次數 ESTD_LC_MEMORY_OBJECT_HITS；

對於想縮小 shared_pool_size 共享池大小的需求，可以關注Est LC Mem Obj Hits (K) ，如上例中共享池為352M時Est LC Mem Obj Hits (K) 就為334且之后不動，則可以考慮縮小shared_pool_size到該值，但要注意每個版本/平台上對共享池的最低需求，包括RAC中gcs resource 、gcs shadow等資源均駐留在shared pool中，增大db_cache_size時要對應關注。

7-8 SGA Target Advisory

SGA Target Advisory Snap: 70723

SGA Target SGA SizeEst DB Est Physical

Size(M) FactorTime(s) Reads

---------- ---------- ------------ ----------------

3,752 0.1 1.697191E+09 1.4577142918E+12

7,504 0.3 1.222939E+09 832,293,601,354

11,256 0.4 1.000162E+09 538,390,923,784

15,008 0.5 895,087,191 399,888,743,900

18,760 0.6 840,062,594 327,287,716,803

22,512 0.8 806,389,685 282,881,041,331

26,264 0.9 782,971,706 251,988,446,808

30,016 1.0 765,293,424 228,664,652,276

33,768 1.1 751,135,535 210,005,616,650

37,520 1.3 739,350,016 194,387,820,900

41,272 1.4 733,533,785 187,299,216,679

45,024 1.5 732,921,550 187,299,216,679

48,776 1.6 732,691,962 187,299,216,679

52,528 1.8 732,538,908 187,299,216,679

56,280 1.9 732,538,917 187,299,216,679

60,032 2.0 732,462,391 187,299,458,716

-------------------------------------------------------------

該環節數據來源於WRH$_SGA_TARGET_ADVICE

SGA target Size: 用以評估的sga target大小 (sga_target)

SGA SizeFactor: SGASize的比例因子， (est SGA targetSize/CurrentSGA targetSize)

Est DB Time(s): 評估對應於該指定sga targetsize會產生多少量的DBTIME，單位為秒

Est Physical Reads：評估對應該指定的sga target size會產生多少的物理讀

7-9 Streams Pool Advisory

Streams Pool Advisory DB/Inst: ITSCMP/itscmp2 Snap: 70723

SizeforSizeEst Spill Est Spill Est Unspill Est Unspill

Est (MB) Factor CountTime(s)CountTime(s)

---------- --------- ----------- ----------- ----------- -----------

64 0.5 0 0 0 0

128 1.0 0 0 0 0

192 1.5 0 0 0 0

256 2.0 0 0 0 0

320 2.5 0 0 0 0

384 3.0 0 0 0 0

448 3.5 0 0 0 0

512 4.0 0 0 0 0

576 4.5 0 0 0 0

640 5.0 0 0 0 0

704 5.5 0 0 0 0

768 6.0 0 0 0 0

832 6.5 0 0 0 0

896 7.0 0 0 0 0

960 7.5 0 0 0 0

1,024 8.0 0 0 0 0

1,088 8.5 0 0 0 0

1,152 9.0 0 0 0 0

1,216 9.5 0 0 0 0

1,280 10.0 0 0 0 0

該環節只有當使用了Streams 流復制時才會有必要數據，數據來源 WRH$_STREAMS_POOL_ADVICE

SizeforEst (MB) : 用以評估的 streams pool大小

SizeFactor ：streams pool大小的比例因子

Est Spill Count：評估出的當使用該大小的流池時 message溢出到磁盤的數量 ESTD_SPILL_COUNT

Est Spill Time(s)：評估出的當使用該大小的流池時 message溢出到磁盤的耗時，單位為秒 ESTD_SPILL_TIME

Est Unspill Count：評估的　當使用該大小的流池時　message unspill 即從磁盤上讀取的數量 ESTD_UNSPILL_COUNT

Est Unspill Time(s) ：評估的　當使用該大小的流池時 message unspill 即從磁盤上讀取的耗時，單位為秒 ESTD_UNSPILL_TIME

7-10 Java Pool Advisory

java pool的相關指標與shared pool相似，不再鏖述

8 Wait Statistics

8-1 Buffer Wait Statistics

Buffer Wait StatisticsSnaps: 70719-70723

-> ordered bywaittimedesc, waitsdesc

Class Waits Total Wait Time(s)AvgTime(ms)

------------------ ----------- ------------------- --------------

data block 8,442,041 407,259 48

undo header 16,212 1,711 106

undo block 21,023 557 26

1st levelbmb 1,038 266 256

2nd levelbmb 540 185 342

bitmap block 90 25 276

segment header 197 13 66

file header block 132 6 43

bitmap indexblock 18 0 1

extent map 2 0 0

數據來源： WRH$_WAITSTAT

該環節是對緩沖池中各類型(class) 塊等待的匯總信息， wait的原因一般是 buffer busy waits 和 readbyother session

class 數據塊的class，一個oracle數據塊即有class 屬性還有type 屬性，數據塊中記錄type屬性(KCBH)，而在buffer header里存有class屬性(X$BH.class)

Waits: 該類型數據塊的等待次數

Total Wait Time(s) : 該類型數據塊的合計等待時間單位為秒

AvgTime(ms) : 該類型數據塊平均每次等待的耗時，單位 ms

如果用戶正使用 undo_management=AUTO 的SMU 則一般不會因為rollbacksegment過少而引起undo header block類塊的等待

對於INSERT而引起的 buffer爭用等待：

1、對於手動segment 管理MSSM 考慮增加Freelists、Freelist Groups

2、使用ASSM ，當然ASSM本身沒什么參數可調

對於INSERTONINDEX引起的爭用：

◾使用反向索引key

◾使用HASH分區和本地索引

◾可能的情況下減少index的density

8-2 Enqueue Activity

enqueue 隊列鎖等待

Enqueue Activity Snaps: 70719-70723

-> onlyenqueueswithwaits are shown

-> Enqueue stats gathered priorto10g shouldnotbe comparedwith10g data

-> ordered byWaitTimedesc, Waitsdesc

Enqueue Type (Request Reason)

------------------------------------------------------------------------------

Requests Succ Gets Failed Gets Waits Wt Time(s) Av WtTime(ms)

------------ ------------ ----------- ----------- ------------ --------------

TX-Transaction(indexcontention)

201,270 201,326 0 193,948 97,517 502.80

TM-DML

702,731 702,681 4 1,081 46,671 43,174.08

SQ-SequenceCache

28,643 28,632 0 17,418 35,606 2,044.19

HW-Segment High Water Mark

9,210 8,845 376 1,216 12,505 10,283.85

TX-Transaction(row lock contention)

9,288 9,280 0 9,232 10,486 1,135.80

CF-Controlfile Transaction

15,851 14,094 1,756 2,798 4,565 1,631.64

TX-Transaction(allocate ITL entry)

471 369 102 360 169 469.28

Enqueue Type (Request Reason) enqueue 隊列的類型，大家在研究 enqueue 問題前至少搞清楚enqueue type 和enqueue mode ， enqueue type是隊列鎖所要保護的資源如 TM 表鎖 CF 控制文件鎖， enqueue mode 是持有隊列鎖的模式 (SS、SX 、S、SSX、X)

Requests : 申請對應的enqueue type資源或者隊列轉換(enqueue conversion 例如 S 轉 SSX ) 的次數

Succ Gets ：對應的enqueue被成功申請或轉換的次數

Failed Gets ：對應的enqueue的申請　或者轉換失敗的次數

Waits　：由對應的enqueue的申請或者轉換而造成等待的次數

Wt Time(s) ：由對應的enqueue的申請或者轉換而造成等待的等待時間

Av Wt Time(ms) ：由對應的enqueue的申請或者轉換而造成等待的平均等待時間， WtTime(s) / Waits ,單位為ms

主要的enqueue 等待事件：

enq: TX – row lock/indexcontention、allocate ITL等待事件

enq: TM – contention等待事件

Oracle隊列鎖enq:TS,TemporarySegment (also TableSpace)

9-1 Undo Segment Summary

Undo Segment Summary Snaps: 70719-70723

-> Min/MaxTR (mins) -MinandMaxTuned Retention (minutes)

-> STO - Snapshot Too Old count, OOS -OutofSpacecount

-> Undo segment block stats:

-> uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed

-> eS - expired Stolen, eR - expired Released, eU - expired reUsed

Undo Num Undo Number ofMaxQryMaxTxMin/MaxSTO/ uS/uR/uU/

TS# Blocks (K) Transactions Len (s) Concurcy TR (mins) OOS eS/eR/eU

---- ---------- --------------- -------- -------- --------- ----- --------------

4 85.0 200,127 55,448 317 1040.2/10 0/0 0/0/0/0/0/0

-------------------------------------------------------------

Undo Segment Stats Snaps: 70719-70723

-> Most recent 35 Undostat rows, orderedbyTimedesc

Num Undo Number ofMaxQryMaxTx Tun Ret STO/ uS/uR/uU/

EndTimeBlocks Transactions Len (s) Concy (mins) OOS eS/eR/eU

------------ ----------- ------------ ------- ------- ------- ----- ------------

29-Aug 05:52 11,700 35,098 55,448 234 1,070 0/0 0/0/0/0/0/0

29-Aug 05:42 12,203 24,677 54,844 284 1,065 0/0 0/0/0/0/0/0

29-Aug 05:32 14,132 37,826 54,241 237 1,060 0/0 0/0/0/0/0/0

29-Aug 05:22 14,379 32,315 53,637 317 1,050 0/0 0/0/0/0/0/0

29-Aug 05:12 15,693 34,157 53,033 299 1,045 0/0 0/0/0/0/0/0

29-Aug 05:02 16,878 36,054 52,428 250 1,040 0/0 0/0/0/0/0/0

數據來源： WRH$_UNDOSTAT ， undo相關的使用信息每10分鍾刷新到v$undostat中

Undo Extent有三種狀態 active 、unexpired 、expired

active => extent中包括了活動的事務，active的undo extent 一般不允許被其他事務重用覆蓋

unexpired => extent中沒有活動的事務，但相關undo 記錄從inactive到目前還未經過undo retention(注意 auto undo retention的問題因為這個特性可能在觀察dba_undo_extents時看到大部分block都是unexpired，這是正常的) 指定的時間，所以為unexpired。對於沒有guarantee retention的undo tablespace而言，unexpired extent可能被 steal 為其他事物重用

expired => extent中沒有活動事務，且超過了undo retention的時間

Undo TS# 在使用的這個undo 表空間的表空間號，一個實例同一時間只能用1個undo tablespace ， RAC不同節點可以用不同的undo tablespace

Num Undo Blocks (K) 指被消費的 undo 數據塊的數量, (K)代表要乘以1000才是實際值；可以用該指標來評估系統對undo block的消費量，以便基於實際負載情況來評估UNDO表空間的大小

Number ofTransactions 指該段時間內該undo表空間上執行過的事務transaction總量

MaxQry Len (s) 該時段內持續最久的查詢時間，單位為秒

MaxTx Concy 該時段內最大的事務並發量

Min/MaxTR (mins) 最小和最大的tuned undo retention ，單位為分鍾； tuned undo retention 是自動undo調優特性，見undo自動調優介紹。

STO/ OOS STO 指 ORA-01555 Snapshot Too Old錯誤出現的次數； OOS – 指OutofSpacecount錯誤出現的次數

uS – unexpired Stolen 嘗試從未過期的undo extent中偷取undo space的次數

uR – unexpired Released 從未過期的undo extent中釋放的塊數目

uU – unexpired reUsed 未過期的undo extent中的block被其他事務重用的塊數目

eS – expired Stolen 嘗試從過期的undo extent中偷取undo space的次數

eR – expired Released 從過期的undo extent中釋放的塊數目

eU – expired reUsed 過期的undo extent中的block被其他事務重用的塊數目

UNXPSTEALCNT NUMBER Number ofattemptstoobtain undospacebystealing unexpired extentsfromother transactions

UNXPBLKRELCNT NUMBER Number ofunexpired blocks removedfromcertain undo segments so they can be usedbyother transactions

UNXPBLKREUCNT NUMBER Number ofunexpired undo blocks reusedbytransactions

EXPSTEALCNT NUMBER Number ofattemptstosteal expired undo blocksfromother undo segments

EXPBLKRELCNT NUMBER Number ofexpired undo blocks stolenfromother undo segments

EXPBLKREUCNT NUMBER Number ofexpired undo blocks reused within the same undo segments

SSOLDERRCNT NUMBER Identifies the number oftimes the error ORA-01555 occurred. You can use this statistictodecide whetherornotthe UNDO_RETENTION initialization parameterissetproperly given thesizeofthe undo tablespace. Increasing the valueofUNDO_RETENTION can reduce the occurrenceofthis error.

10-1 Latch Activity

Latch Activity Snaps: 70719-70723

-> "Get Requests","Pct Get Miss"and"Avg Slps/Miss"arestatisticsfor

willing-to-wait latch get requests

-> "NoWait Requests","Pct NoWait Miss"areforno-wait latch get requests

-> "Pct Misses"forboth should be verycloseto0.0

Pct AvgWait Pct

Get Get Slps TimeNoWait NoWait

Latch NameRequests Miss /Miss (s) Requests Miss

------------------------ -------------- ------ ------ ------ ------------ ------

AQ deq hash tablelatch 4 0.0 0 0 N/A

ASM Keyed state latch 9,048 0.1 0.2 0 0 N/A

ASM allocation 15,017 0.2 0.8 1 0 N/A

ASM db client latch 72,745 0.0 0 0 N/A

ASM map headers 5,860 0.6 0.6 1 0 N/A

ASM map loadwaiting lis 1,462 0.0 0 0 N/A

ASM map operation freeli 63,539 0.1 0.4 1 0 N/A

ASM map operation hash t 76,484,447 0.1 1.0 66 0 N/A

latch nameLatch閂的名字

Get Requests latch被以willing-to-wait模式申請並獲得的次數

Pct Get Miss miss是指latch被以willing-to-wait 模式申請但是申請者必須等待的次數， Pct Get Miss = Miss/Get Requests ; miss可以從后面的Latch Sleep Breakdown 獲得

AvgSlps /Miss Sleep 是指latch被以willing-to-wait模式申請最終導致session需要sleep以等待該latch的次數；AvgSlps /Miss = Sleeps/ Misses ; Sleeps可以從后面的Latch Sleep Breakdown 獲得

Wait Time(s) 指花費在等待latch上的時間，單位為秒

NoWait Requests 指latch被以no-wait模式來申請的次數

Pct NoWait Miss 以no-wait模式來申請latch但直接失敗的次數

對於高並發的latch例如cache buffers chains，其Pct Misses應當十分接近於0

一般的調優原則：

如果latch : cache buffers chains是 Top5 事件，則需要考慮優化SQL減少全表掃描並減少Topbuffer gets SQL語句的邏輯讀

如果latch : redo copy 、redo allocation 等待較多，則可以考慮增大LOG_BUFFER

如果latch:library cache 發生較多，則考慮增大shared_pool_size

10-2 Latch Sleep Breakdown

Latch Sleep Breakdown DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723

-> ordered bymissesdesc

Get Spin

Latch NameRequests Misses Sleeps Gets

-------------------------- --------------- ------------ ----------- -----------

cache buffers chains 3,365,097,866 12,831,875 130,058 12,683,450

row cache objects 69,050,058 349,839 1,320 348,649

session idle bit389,437,460 268,285 2,768 265,752

enqueue hash chains 8,698,453 239,880 22,476 219,950

ges resource hash list 8,388,730 158,894 70,728 91,104

gc element 100,383,385 135,759 6,285 129,742

gcs remastering latch 12,213,169 72,373 1 72,371

enqueues 4,662,545 46,374 259 46,155

ASM map operation hash tab 76,484,447 46,231 45,210 1,952

Lsod array latch 72,598 24,224 24,577 1,519

latch nameLatch閂的名字

Get Requests latch被以willing-to-wait模式申請並獲得的次數

misses 是指latch被以willing-to-wait 模式申請但是申請者必須等待的次數

9i以后miss之后一般有2種情況 spin gets了或者sleep一睡不醒直到被post，具體見全面解析9i以后Oracle Latch閂鎖原理；

8i以前的latch算法可以參考：Oracle Latch:一段描繪Latch運作的偽代碼

所以一般來說9i以后的 misses= Sleeps+ Spin Gets ，雖然不是絕對如此

Sleeps 是指latch被以willing-to-wait模式申請最終導致session需要sleep以等待該latch的次數

Spin Gets 以willing-to-wait模式去申請latch，在miss之后以spin方式獲得了latch的次數

10-3 Latch Miss Sources

Latch Miss Sources Snaps: 70719-70723

-> onlylatcheswithsleeps are shown

-> ordered byname, sleepsdesc

NoWait Waiter

Latch NameWhereMisses Sleeps Sleeps

------------------------ -------------------------- ------- ---------- --------

ASM Keyed state latch kfksolGet 0 1 1

ASM allocation kfgpnSetDisks2 0 17 0

ASM allocation kfgpnClearDisks 0 5 0

ASM allocation kfgscCreate 0 4 0

ASM allocation kfgrpGetByName 0 1 26

ASM map headers kffmUnidentify_3 0 7 8

ASM map headers kffmAllocate 0 6 0

ASM map headers kffmIdentify 0 6 11

ASM map headers kffmFree 0 1 0

ASM map operation freeli kffmTranslate2 0 15 8

ASM map operation hash t kffmUnidentify 0 44,677 36,784

ASM map operation hash t kffmTranslate 0 220 3,517

數據來源為DBA_HIST_LATCH_MISSES_SUMMARY

latch nameLatch閂的名字

where: 指哪些代碼路徑內核函數持有過這些該latch ，而不是哪些代碼路徑要申請這些latch；例如kcbgtcr函數的作用是Get a blockforConsistentread，其持有latch :cache buffers chain是很正常的事情

NoWait Misses: 以no-wait模式來申請latch但直接失敗的次數

Sleeps: 指latch被以willing-to-wait模式申請最終導致session需要sleep以等待該latch的次數timeofsleeps resultedinmaking the latch request

Waiter Sleeps：等待者休眠的次數 times ofsleeps that waiters didforeachwhere; Sleep 是阻塞者等待的次數， Waiter Sleeps是被阻塞者等待的次數

10-4 Mutex Sleep Summary

Mutex Sleep Summary Snaps: 70719-70723

-> ordered bynumberofsleepsdesc

Wait

Mutex Type Location Sleeps Time(ms)

--------------------- -------------------------------- ------------ ------------

CursorPin kksfbc [KKSCHLFSP2] 4,364 14,520

CursorPin kkslce [KKSCHLPIN2] 2,396 2,498

Library Cache kglpndl1 95 903 475

Library Cache kglpin1 4 800 458

Library Cache kglpnal2 91 799 259

Library Cache kglget1 1 553 1,697

Library Cache kglpnal1 90 489 88

Library Cache kgllkdl1 85 481 1,528

CursorPin kksLockDelete [KKSCHLPIN6] 410 666

CursorStat kkocsStoreBindAwareStats [KKSSTA 346 497

Library Cache kglhdgn2 106 167 348

Library Cache kglhdgh1 64 26 84

Library Cache kgldtin1 42 19 55

CursorPin kksfbc [KKSCHLPIN1] 13 34

Library Cache kglhdgn1 62 11 13

Library Cache kgllkal1 80 9 12

Library Cache kgllkc1 57 6 0

CursorPin kksSetBindType [KKSCHLPIN3] 5 5

Library Cache kglGetHandleReference 124 4 20

Library Cache kglUpgradeLock 119 4 0

Library Cache kglget2 2 3 0

Library Cache kglati1 45 1 0

Library Cache kglini1 32 1 0

Library Cache kglobld1 75 1 0

Library Cache kglobpn1 71 1 0

Mutex是10.2.0.2以后引入的新的內存鎖機制，具體對Mutex的描述見《深入理解Oracle中的Mutex》：http://www.askmaclean.com/archives/understanding-oracle-mutex.html

Mutex Type

Mutex的類型其實就是 mutex對應的客戶的名字，在版本10.2中基本只有KKS使用Mutex，所以僅有3種:

◾CursorStat (kgx_kks1)

◾CursorParent (kgx_kks2)

◾CursorPin (kgx_kks3)

11g中增加了Library Cache

Location 發起對該Mutex申請的代碼路徑code location，而不是還持有該Mutex的代碼路徑或曰內核函數

10.2中最常見的下面的幾個函數

kkspsc0 -負責解析游標 – 檢測我們正在解析的游標是否有對象的parent cursorheap 0存在

kksfbc – 負責找到合適的子游標或者創建一個新的子游標

kksFindCursorstat

Sleeps:

Mutex的Get和Sleep

當一個Mutex被申請時，一般稱為一個get request。若初始的申請未能得到授權，則該進程會因為此次申請而進入到255次SPIN中(_mutex_spin_count Mutex spin count)，每次SPIN循環迭代過程中該進程都會去看看Mutex被釋放了嗎。

若該Mutex在SPIN之后仍未被釋放，則該進程針對申請的mutex進入對應的mutex wait等待事件中。實際進程的等待事件和等待方式由mutex的類型鎖決定，例如 Cursorpin、CursorParent。舉例來說，這種等待可能是阻塞等待，也可以是sleep。

但是請注意在V$MUTEX_SLEEP_*視圖上的sleep列意味着等待的次數。相關代碼函數在開始進入等待時自加這個sleep字段。

等待計時從進程進入等待前開始計算等待時間，當一個進程結束其等待，則等待的時間加入都總和total中。該進程再次嘗試申請之前的Mutex，若該Mutex仍不可用，則它再次進入spin/wait的循環。

V$MUTEX_SLEEP_HISTORY視圖的GETS列僅在成功申請到一個Mutex時才增加。

Wait Time(ms) 類似於latch，spintime不算做mutex的消耗時間，它只包含等待消耗的時間。

=====================================================================

11 segment statistics段級統計

11-1 Segments byLogical Reads

Segments byLogical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total Logical Reads: 2,021,476,421

-> Captured Segments account for83.7%ofTotal

Tablespace Subobject Obj. Logical

Owner NameObjectNameNameType Reads %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX372,849,920 18.44

CONTENT_OW INDEX_TS MZ_PRODUCT__LS_PK INDEX329,829,632 16.32

CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE218,419,008 10.80

CONTENT_OW PLAYLIST_A MZ_PLAYLIST_ARTIST TABLE182,426,240 9.02

CONTENT_OW DATA_TS MZ_PRODUCT TABLE108,597,376 5.37

owner : 數據段的所有者

Tablespace Name: 數據段所在表空間名

Object Name: 對象名

Subobject Name：子對象名，例如一個分區表的某個分區

obj Type: 對象類型一般為TABLE/INDEX或者分區或子分區

Logical Reads ：該數據段上發生過的邏輯讀，單位為塊數*次數

%Total : 占總的邏輯讀的百分比， (當前對象上發生過的邏輯讀/ Total DB 邏輯讀)

11-2 Segments byPhysical Reads

Segments byPhysical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total Physical Reads: 56,839,035

-> Captured Segments account for51.9%ofTotal

Tablespace Subobject Obj. Physical

Owner NameObjectNameNameType Reads %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW SONG_TS MZ_SONG TABLE7,311,928 12.86

CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE4,896,554 8.61

CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE3,099,387 5.45

CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE1,529,971 2.69

CONTENT_OW DATA_TS MZ_PUBLICATION TABLE1,391,735 2.45

Physical Reads: 該數據段上發生過的物理讀，單位為塊數*次數

%Total : 占總的物理讀的百分比， (當前對象上發生過的邏輯讀/ Total DB 邏輯讀)

11-3 Segments byPhysicalReadRequests

Segments byPhysicalReadRequests DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total Physical ReadRequests: 33,936,360

-> Captured Segments account for45.5%ofTotal

Tablespace Subobject Obj. Phys Read

Owner NameObjectNameNameType Requests %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE3,099,346 9.13

CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE1,529,950 4.51

CONTENT_OW DATA_TS MZ_PRODUCT TABLE1,306,756 3.85

CONTENT_OW DATA_TS MZ_AUDIO_FILE TABLE910,537 2.68

CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX820,459 2.42

Phys ReadRequests ：物理讀的申請次數

%Total ：　(該段上發生的物理讀的申請次數/ physical readIO requests)

11-4 Segments byUnOptimized Reads

Segments byUnOptimized Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total UnOptimized ReadRequests: 811,466

-> Captured Segments account for58.5%ofTotal

Tablespace Subobject Obj. UnOptimized

Owner NameObjectNameNameType Reads %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE103,580 12.76

CONTENT_OW SONG_TS MZ_SONG TABLE56,946 7.02

CONTENT_OW DATA_TS MZ_IMAGE TABLE47,017 5.79

CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE40,950 5.05

CONTENT_OW DATA_TS MZ_PRODUCT TABLE30,406 3.75

UnOptimized Reads UnOptimized ReadReqs = PhysicalReadReqts – OptimizedReadReqs

Optimized ReadRequests是指哪些滿足Exadata Smart Flash Cache (orthe Smart Flash CacheinOracleExadata V2 (Note that despite samename, conceptanduseof

‘Smart Flash Cache’ inExadata V2isdifferentfrom‘Smart Flash Cache’inDatabaseSmart Flash Cache)).的物理讀次數。滿足從smart flash cache走的讀取申請唄認為是optimized ，因為這些讀取要比普通從磁盤走快得多。

此外通過smart scan 讀取storage index的情況也被認為是’optimizedreadrequests’ ，源於可以避免讀取不相關的數據。

當用戶不在使用Exadata時，則UnOptimized ReadReqs總是等於 PhysicalReadReqts

%Total : (該段上發生的物理讀的UnOptimized ReadReqs / ( physicalreadIO requests – physicalreadrequests optimized ))

11-5 Segments byOptimized Reads

Segments byOptimized Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total Optimized ReadRequests: 33,124,894

-> Captured Segments account for45.2%ofTotal

Tablespace Subobject Obj. Optimized

Owner NameObjectNameNameType Reads %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE2,995,766 9.04

CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE1,489,000 4.50

CONTENT_OW DATA_TS MZ_PRODUCT TABLE1,276,350 3.85

CONTENT_OW DATA_TS MZ_AUDIO_FILE TABLE890,775 2.69

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX816,067 2.46

關於optimizerd read上面已經解釋過了，這里的單位是 request 次數

%Total : (該段上發生的物理讀的 Optimized ReadReqs/ physicalreadrequests optimized )

11-6 Segments byDirect Physical Reads

Segments byDirect Physical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total Direct Physical Reads: 14,118,552

-> Captured Segments account for94.2%ofTotal

Tablespace Subobject Obj. Direct

Owner NameObjectNameNameType Reads %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW SONG_TS MZ_SONG TABLE7,084,416 50.18

CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE4,839,984 34.28

CONTENT_OW DATA_TS MZ_PUBLICATION TABLE1,361,133 9.64

CONTENT_OW DATA_TS SYS_LOB0000203660C00 LOB 5,904 .04

CONTENT_OW DATA_TS SYS_LOB0000203733C00 LOB 1,656 .01

Direct reads 直接路徑物理讀，單位為塊數*次數

%Total (該段上發生的direct path reads /Total physical reads direct )

11-7 Segments byPhysical Writes

Segments byPhysical Writes DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total Physical Writes: 590,563

-> Captured Segments account for38.3%ofTotal

Tablespace Subobject Obj. Physical

Owner NameObjectNameNameType Writes %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE23,595 4.00

CONTENT_OW DATA_TS MZ_PODCAST TABLE19,834 3.36

CONTENT_OW INDEX_TS MZ_IMAGE_IX2 INDEX16,345 2.77

SYS SYSAUX WRH$_ACTIVE_SESSION_ 1367_70520 TABLE14,173 2.40

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX9,645 1.63

Physical Writes ，物理寫單位為塊數*次數

Total % (該段上發生的物理寫 /Total physical writes )

11-9 Segments byPhysical Write Requests

Segments byPhysical Write Requests DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total Physical Write Requestss: 436,789

-> Captured Segments account for43.1%ofTotal

Tablespace Subobject Obj. Phys Write

Owner NameObjectNameNameType Requests %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE22,581 5.17

CONTENT_OW DATA_TS MZ_PODCAST TABLE19,797 4.53

CONTENT_OW INDEX_TS MZ_IMAGE_IX2 INDEX14,529 3.33

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX9,434 2.16

CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE8,618 1.97

Phys Write Requests 物理寫的請求次數，單位為次數

%Total (該段上發生的物理寫請求次數 /physical write IO requests )

11-10 Segments byDirect Physical Writes

Segments byDirect Physical Writes DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total Direct Physical Writes: 29,660

-> Captured Segments account for18.3%ofTotal

Tablespace Subobject Obj. Direct

Owner NameObjectNameNameType Writes %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

SYS SYSAUX WRH$_ACTIVE_SESSION_ 1367_70520 TABLE4,601 15.51

CONTENT_OW DATA_TS SYS_LOB0000203733C00 LOB 620 2.09

CONTENT_OW DATA_TS SYS_LOB0000203660C00 LOB 134 .45

CONTENT_OW DATA_TS SYS_LOB0000203779C00 LOB 46 .16

CONTENT_OW DATA_TS SYS_LOB0000203796C00 LOB 41 .14

Direct Writes 直接路徑寫，單位額為塊數*次數

%Total 為(該段上發生的直接路徑寫 /physical writes direct )

11-11 Segments byTableScans

Segments byTableScans DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total TableScans: 10,713

-> Captured Segments account for1.0%ofTotal

Tablespace Subobject Obj. Table

Owner NameObjectNameNameType Scans %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW DATA_TS MZ_PUBLICATION TABLE92 .86

CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE14 .13

CONTENT_OW SONG_TS MZ_SONG TABLE3 .03

CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE1 .01

TableScans 來源為dba_hist_seg_stat.table_scans_delta 不過這個指標並不十分精確

11-12 Segments byDB Blocks Changes

Segments byDB Blocks Changes DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> % ofCapture shows %ofDB Block Changesforeachtopsegment compared

-> withtotal DB Block Changesforallsegments capturedbythe Snapshot

Tablespace Subobject Obj. DB Block % of

Owner NameObjectNameNameType Changes Capture

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX8 INDEX347,856 10.21

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX269,504 7.91

CONTENT_OW INDEX_TS MZ_AM_REQUEST_PK INDEX251,904 7.39

CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE201,056 5.90

CONTENT_OW INDEX_TS MZ_PRODUCT_ATTRIBUTE INDEX199,888 5.86

DB Block Changes ，單位為塊數*次數

%Total : (該段上發生block changes / db block changes )

11-13 Segments byRow Lock Waits

Segments byRow Lock Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> % ofCapture shows %ofrow lock waitsforeachtopsegment compared

-> withtotal row lock waitsforallsegments capturedbythe Snapshot

Row

Tablespace Subobject Obj. Lock % of

Owner NameObjectNameNameType Waits Capture

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX72,005 43.86

CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX13,795 8.40

CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX12,383 7.54

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX8,937 5.44

CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE8,531 5.20

Row Lock Waits 是指行鎖的等待次數數據來源於 dba_hist_seg_stat.ROW_LOCK_WAITS_DELTA

11-14 Segments byITL WAITS

Segments byITL Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> % ofCapture shows %ofITL waitsforeachtopsegment compared

-> withtotal ITL waitsforallsegments capturedbythe Snapshot

Tablespace Subobject Obj. ITL % of

Owner NameObjectNameNameType Waits Capture

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX95 30.16

CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX48 15.24

CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX21 6.67

CONTENT_OW INDEX_TS MZ_SALABLE_FIRST_AVA INDEX21 6.67

CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE20 6.35

關於 ITL的介紹詳見： http://www.askmaclean.com/archives/enqueue-tx-row-lock-index-itl-wait-event.html

ITL Waits 等待 ITL 的次數，數據來源為 dba_hist_seg_stat.itl_waits_delta

11-14 Segments byBuffer Busy Waits

Segments byBuffer Busy Waits DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> % ofCapture shows %ofBuffer Busy Waitsforeachtopsegment compared

-> withtotal Buffer Busy Waitsforallsegments capturedbythe Snapshot

Buffer

Tablespace Subobject Obj. Busy % of

Owner NameObjectNameNameType Waits Capture

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX251,073 57.07

CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX36,186 8.23

CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX31,786 7.23

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX15,663 3.56

CONTENT_OW INDEX_TS MZ_CS_WORK_PENDING_R INDEX11,087 2.52

Buffer Busy Waits 該數據段上發生 buffer busy wait的次數數據來源 dba_hist_seg_stat.buffer_busy_waits_delta

11-15 Segments byGlobalCache Buffer

Segments byGlobalCache Buffer BusyDB/Inst: MAC/MAC2 Snaps: 70719-7072

-> % ofCapture shows %ofGC Buffer Busyforeachtopsegment compared

-> withGC Buffer Busyforallsegments capturedbythe Snapshot

Tablespace Subobject Obj. Buffer % of

Owner NameObjectNameNameType Busy Capture

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX2,135,528 50.07

CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE652,900 15.31

CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX552,161 12.95

CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX113,042 2.65

CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX98,134 2.30

GC Buffer Busy 數據段上發揮僧gc buffer busy的次數，數據源 dba_hist_seg_stat.gc_buffer_busy_delta

11-15 Segments byCR Blocks Received

Segments byCR Blocks Received DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total CR Blocks Received: 763,037

-> Captured Segments account for40.9%ofTotal

Tablespace Subobject Obj. Blocks

Owner NameObjectNameNameType Received %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE69,100 9.06

CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE44,491 5.83

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX36,830 4.83

CONTENT_OW DATA_TS MZ_PODCAST TABLE36,632 4.80

CONTENT_OW INDEX_TS MZ_AM_REQUEST_PK INDEX19,646 2.57

CR Blocks Received ：是指RAC中本地節點接收到globalcache CR blocks 的數量；數據來源為 dba_hist_seg_stat.gc_cu_blocks_received_delta

%Total : (該段上在本節點接收的GlobalCR blocks / gc cr blocks received )

11-16 Segments byCurrentBlocks Received

Segments byCurrentBlocks ReceivedDB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Total CurrentBlocks Received: 704,731

-> Captured Segments account for61.8%ofTotal

Current

Tablespace Subobject Obj. Blocks

Owner NameObjectNameNameType Received %Total

---------- ---------- -------------------- ---------- ----- ------------ -------

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX56,287 7.99

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX45,139 6.41

CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE40,350 5.73

CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE22,808 3.24

CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX8 INDEX13,343 1.89

CurrentBlocks Received :是指RAC中本地節點接收到globalcacheCurrentblocks 的數量，數據來源DBA_HIST_SEG_STAT.gc_cu_blocks_received_delta

%Total : (該段上在本節點接收的 globalcachecurrentblocks / gccurrentblocks received)

12 Dictionary Cache Stats

Dictionary Cache Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> "Pct Misses"should be very low ("Final Usage"isthe numberofcache entries being used

Get Pct Scan Pct Mod Final

Cache Requests Miss Reqs Miss Reqs Usage

------------------------- ------------ ------ ------- ----- -------- ----------

dc_awr_control 87 2.3 0 N/A 6 1

dc_global_oids 1,134 7.8 0 N/A 0 13

dc_histogram_data 6,119,027 0.9 0 N/A 0 11,784

dc_histogram_defs 1,898,714 2.3 0 N/A 0 5,462

dc_object_grants 175 26.9 0 N/A 0 4

dc_objects 10,254,514 0.2 0 N/A 0 3,807

dc_profiles 8,452 0.0 0 N/A 0 2

dc_rollback_segments 3,031,044 0.0 0 N/A 0 1,947

dc_segments 1,812,243 1.4 0 N/A 10 3,595

dc_sequences 15,783 69.6 0 N/A 15,782 20

dc_table_scns 70 2.9 0 N/A 0 1

dc_tablespaces 1,628,112 0.0 0 N/A 0 37

dc_users 2,037,138 0.0 0 N/A 0 52

globaldatabasename7,698 0.0 0 N/A 0 1

outstanding_alerts 264 99.6 0 N/A 8 1

sch_lj_oids 51 7.8 0 N/A 0 1

Dictionary Cache 字典緩存也叫row cache

數據來源為dba_hist_rowcache_summary

Cache 字典緩存類名kqrstcid <=> kqrsttxt cid=3(dc_rollback_segments)

Get Requests 申請獲取該數據字典緩存對象的次數 gets

Miss : GETMISSES 申請獲取該數據字典緩存對象但 miss的次數

Pct Miss ：　GETMISSES /Gets ， Miss的比例，這個pct miss應當非常低小於2%，否則有出現大量row cache lock的可能

Scan Reqs：掃描申請的次數，kqrssc 、kqrpScan 、kqrpsiv時發生scan 會導致掃描數增加 kqrstsrq++(scan requests) ，例如migrate tablespace 時調用 kttm2b函數為了安全刪除uet$中的記錄會callback kqrpsiv (used extent cache)，實際很少見

Pct Miss：SCANMISSES/SCANS

Mod Reqs: 申請修改字典緩存對象的次數，從上面的數據可以看到dc_sequences的mod reqs很高，這是因為sequence是變化較多的字典對象

Final Usage ：包含有有效數據的字典緩存記錄的總數也就是正在被使用的row cache記錄 USAGE Number ofcache entries that contain valid data

Dictionary Cache Stats (RAC) DB/Inst: MAC/MAC2 Snaps: 70719-70723

GES GES GES

Cache Requests Conflicts Releases

------------------------- ------------ ------------ ------------

dc_awr_control 14 2 0

dc_global_oids 88 0 102

dc_histogram_defs 43,518 0 43,521

dc_objects 21,608 17 21,176

dc_profiles 1 0 1

dc_segments 24,974 14 24,428

dc_sequences 25,178 10,644 347

dc_table_scns 2 0 2

dc_tablespaces 165 0 166

dc_users 119 0 119

outstanding_alerts 478 8 250

sch_lj_oids 4 0 4

GES Request kqrstilr total instance lock requests ，通過全局隊列服務GES 來申請instance lock的次數

GES request 申請的原因可能是 dump cache object、kqrbfr LCK進程要background freesomeparent objects釋放一些parent objects 等

GES Conflicts kqrstifr instance lock forced-releases ， LCK進程以AST方式釋放鎖的次數，僅出現在kqrbrl中

GES Releases kqrstisr instance lock self-releases ，LCK進程要background freesomeparent objects釋放一些parent objects 時可能自增

上述數據中可以看到僅有dc_sequences 對應的GES Conflicts較多，對於sequence使用ordered和non-cache選項會導致RAC中的一個邊際效應，即”row cache lock”等待源於DC_SEQUENCES ROW CACHE。 DC_SEQUENCES 上的GETS request、modifications 、GES requests和GES conflict 與引發生成一個新的sequencenumber的特定SQL執行頻率相關。

在Oracle 10g中，ORDERED Sequence還可能在高並發下造成大量DFS lock Handle 等待，由於bug 5209859

13 Library Cache Activity

Library Cache Activity DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> "Pct Misses"should be very low

Get Pct Pin Pct Invali-

Namespace Requests Miss Requests Miss Reloads dations

--------------- ------------ ------ -------------- ------ ---------- --------

ACCOUNT_STATUS 8,436 0.3 0 N/A 0 0

BODY 8,697 0.7 15,537 0.7 49 0

CLUSTER 317 4.7 321 4.7 0 0

DBLINK 9,212 0.1 0 N/A 0 0

EDITION 4,431 0.0 8,660 0.0 0 0

HINTSET OBJECT 1,027 9.5 1,027 14.4 0 0

INDEX792 18.2 792 18.2 0 0

QUEUE 10 0.0 1,733 0.0 0 0

RULESET 0 N/A 8 87.5 7 0

SCHEMA8,169 0.0 0 N/A 0 0

SQL AREA 533,409 4.8 -4,246,727,944 101.1 44,864 576

SQL AREA BUILD 71,500 65.5 0 N/A 0 0

SQL AREA STATS 41,008 90.3 41,008 90.3 1 0

TABLE/PROCEDURE320,310 0.6 1,033,991 3.6 25,378 0

TRIGGER847 0.0 38,442 0.3 110 0

NameSpace library cache 的命名空間

GETS Requests 該命名空間所包含對象的library cache lock被申請的次數

GETHITS 對象的 library cache handle 正好在內存中被找到的次數

Pct Misses : ( 1- ( GETHITS /GETS Requests)) *100

Pin Requests 該命名空間所包含對象上pin被申請的次數

PINHITS 要pin的對象的heap metadata正好在shared pool中的次數

Pct Miss ( 1- ( PINHITS /Pin Requests)) *100

Reloads 指從object handle 被重建開始不是第一次PIN該對象的PIN ，且該次PIN要求對象從磁盤上讀取加載的次數 ;Reloads值較高的情況建議增大shared_pool_size

INVALIDATIONS 由於以來對象被修改導致該命名空間所包含對象被標記為無效的次數

Library Cache Activity (RAC) DB/Inst: MAC/MAC2 Snaps: 70719-70723

GES Lock GES Pin GES Pin GES Inval GES Invali-

Namespace Requests Requests Releases Requests dations

--------------- ------------ ------------ ------------ ----------- -----------

ACCOUNT_STATUS 8,436 0 0 0 0

BODY 0 15,497 15,497 0 0

CLUSTER 321 321 321 0 0

DBLINK 9,212 0 0 0 0

EDITION 4,431 4,431 4,431 0 0

HINTSET OBJECT 1,027 1,027 1,027 0 0

INDEX792 792 792 0 0

QUEUE 8 1,733 1,733 0 0

RULESET 0 8 8 0 0

SCHEMA4,226 0 0 0 0

TABLE/PROCEDURE373,163 704,816 704,816 0 0

TRIGGER0 38,430 38,430 0 0

GES Lock Request: dlm_lock_requests Lock instance-lock ReQuests 申請獲得lock instance lock的次數

GES PIN request : DLM_PIN_REQUESTS Pin instance-lock ReQuests 申請獲得pin instance lock的次數

GES Pin Releases DLM_PIN_RELEASES release the pin instance lock 釋放pin instance lock的次數

GES Inval Requests DLM_INVALIDATION_REQUESTS get the invalidation instance lock 申請獲得invalidation instance lock的次數

GES Invali- dations DLM_INVALIDATIONS 接收到其他節點的invalidation pings次數

14 Process Memory Summary

Process Memory Summary DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> B: BeginSnap E:EndSnap

-> Allrowsbelow containabsolutevalues(i.e.notdiffed over the interval)

-> MaxAllocisMaximum PGA Allocationsizeatsnapshottime

-> Hist MaxAllocisthe HistoricalMaxAllocationforstill-connected processes

-> ordered byBegin/Endsnapshot, Alloc (MB)desc

Hist

AvgStd DevMaxMax

Alloc Used Alloc Alloc Alloc Alloc Num Num

Category (MB) (MB) (MB) (MB) (MB) (MB) Proc Alloc

- -------- --------- --------- -------- -------- ------- ------- ------ ------

B Other 16,062.7 N/A 6.1 66.6 3,370 3,370 2,612 2,612

SQL 5,412.2 4,462.9 2.2 89.5 4,483 4,483 2,508 2,498

Freeable 2,116.4 .0 .9 6.3 298 N/A 2,266 2,266

PL/SQL 94.0 69.8 .0 .0 1 1 2,610 2,609

E Other 15,977.3 N/A 6.1 66.9 3,387 3,387 2,616 2,616

SQL 5,447.9 4,519.0 2.2 89.8 4,505 4,505 2,514 2,503

Freeable 2,119.9 .0 .9 6.3 297 N/A 2,273 2,273

PL/SQL 93.2 69.2 .0 .0 1 1 2,614 2,613

數據來源為dba_hist_process_mem_summary，這里是對PGA 使用的一個小結，幫助我們了解到底誰用掉了PGA

B: 開始快照 E: 結束快照

該環節列出 PGA中各分類的使用量

Category 分類名，包括”SQL”, “PL/SQL”, “OLAP” 和”JAVA”. 特殊分類是 “Freeable” 和”Other”. Freememory是指哪些 OS已經分配給進程，但沒有分配給任何分類的內存。 “Other”是已經分配給分類的內存，但不是已命名的分類

Alloc (MB) allocated_total 該分類被分配的總內存

Used (MB) used_total 該分類已使用的內存

AvgAlloc (MB) allocated_avg 平均每個進程中該分類分配的內存量

Std Dev Alloc (MB) ：該分類分配的內存在每個進程之間的標准差

MaxAlloc　(MB) ALLOCATED_MAX　：在快照時間內單個進程該分類最大分配過的內存量：MaxAllocisMaximum PGA Allocationsizeatsnapshottime

Hist MaxAlloc (MB) MAX_ALLOCATED_MAX: 目前仍鏈接着的進程該分類最大分配過的內存量：HistMaxAllocisthe HistoricalMaxAllocationforstill-connected processes

Num Proc num_processes 進程數目

Num Alloc NON_ZERO_ALLOCS 分配了該類型內存的進程數目

14 SGA信息

14 -1 SGA Memory Summary

SGA Memory Summary DB/Inst: MAC/MAC2 Snaps: 70719-70723

EndSize(Bytes)

SGA regions BeginSize(Bytes) (if different)

------------------------------ ------------------- -------------------

DatabaseBuffers 20,669,530,112

Fixed Size2,241,880

Redo Buffers 125,669,376

Variable Size10,536,094,376

-------------------

sum31,333,535,744

粗粒度的sga區域內存使用信息， EndSize僅在於beginsize不同時打印

14-2 SGA breakdown difference

SGA breakdown difference DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> ordered byPool,Name

-> N/A value forBeginMBorEndMB indicates thesizeofthat Pool/Namewas

insignificant, orzerointhat snapshot

Pool NameBeginMBEndMB % Diff

------ ------------------------------ -------------- -------------- -------

java freememory 64.0 64.0 0.00

large PX msg pool 7.8 7.8 0.00

large freememory 247.8 247.8 0.00

shared Checkpointqueue 140.6 140.6 0.00

shared FileOpenBlock 2,459.2 2,459.2 0.00

shared KGH: NOACCESS 1,629.6 1,629.6 0.00

shared KGLH0 997.7 990.5 -0.71

shared KKSSP 312.2 308.9 -1.06

shared SQLA 376.6 370.6 -1.61

shared db_block_hash_buckets 178.0 178.0 0.00

shared dbktb: trace buffer 156.3 156.3 0.00

shared event statisticsper sess 187.1 187.1 0.00

shared freememory 1,208.9 1,220.6 0.97

shared gcs resources 435.0 435.0 0.00

shared gcs shadows 320.6 320.6 0.00

shared ges enqueues 228.9 228.9 0.00

shared ges resource 118.3 118.3 0.00

shared init_heap_kfsg 1,063.6 1,068.1 0.43

shared kglsim object batch 124.3 124.3 0.00

shared ksunfy : SSO freelist 174.7 174.7 0.00

stream freememory 128.0 128.0 0.00

buffer_cache 19,712.0 19,712.0 0.00

fixed_sga 2.1 2.1 0.00

log_buffer 119.8 119.8 0.00

-------------------------------------------------------------

Pool 內存池的名字

Name內存池中細分組件的名字例如KGLH0 存放KEL Heap 0 、SQLA存放SQL執行計划等

BeginMB 快照開始時該組件的內存大小

EndMB 快照結束時該組件的內存大小

% Diff 差異百分比

特別注意由於AMM /ASMM引起的shared pool收縮一般在sga breakdown中可以提現例如SQLA 、KQR等組件大幅縮小，可能導致一系列的解析等待 cursor: Pin SonX 、row cache lock等

此處的freememory信息也值得我們關注，一般推薦shared pool應當有300~400 MB 的freememory為宜

15 Streams統計

Streams CPU/IO Usage DB/Inst: ORCL/orcl1 Snaps: 556-559

-> Streams processes ordered byCPU usage

-> CPU andI/OTimeinmicro seconds

Session Type CPU TimeUserI/OTimeSys I/OTime

------------------------- -------------- -------------- --------------

QMON Coordinator 101,698 0 0

QMON Slaves 63,856 0 0

-------------------------------------------------------------

Streams Capture DB/Inst: CATGT/catgt Snaps: 911-912

-> Lag Change should be small ornegative (inseconds)

Captured Enqueued Pct Pct Pct Pct

Per Per Lag RuleEval Enqueue RedoWait Pause

Capture NameSecondSecondChangeTimeTimeTimeTime

------------ -------- -------- -------- -------- -------- -------- --------

CAPTURE_CAT 650 391 93 0 23 0 71

-------------------------------------------------------------

Streams Apply DB/Inst: CATGT/catgt Snaps: 911-912

-> Pct DB isthe percentageofallDB transactions that this apply handled

-> WDEP isthe waitfordependency

-> WCMT isthe waitforcommit

-> RBK isrollbacks -> MPSismessages persecond

-> TPM istimeper messageinmilli-seconds

-> Lag Change should be small ornegative (inseconds)

Applied Pct Pct Pct Pct Applied Dequeue Apply Lag

Apply NameTPS DB WDEP WCMT RBK MPS TPM TPM Change

------------ -------- ---- ---- ---- --- -------- -------- -------- --------

APPLY_CAT 0 0 0 0 0 0 0 0 0

-------------------------------------------------------------

Capture Name: Streams捕獲進程名

Captured Per Second：每秒挖掘出來的message 條數

Enqueued Per Second: 每秒入隊的message條數

lag change: 指日志生成的時間到挖掘到該日志生成 message的時間延遲

Pct Enqueue Time：入隊時間的比例

Pct redoWait Time: 等待redo的時間比例

Pct Pause Time: Pause 時間的比例

Apply NameStreams 應用Apply進程的名字

Applied TPS : 每秒應用的事務數

Pct DB: 所有的DB事務中 apply處理的比例

Pct WDEP: 由於等待依賴的數據而耗費的時間比例

Pct WCMT: 由於等待commit而耗費的時間比例

Pct RBK: 事務rollback回滾的比例

Applied MPS: 每秒應用的message 數

Dequeue TPM: 每毫秒出隊的message數

Lag Change:指最新message生成的時間到其被Apply收到的延遲

16 Resource Limit

Resource Limit Stats DB/Inst: MAC/MAC2 Snap: 70723

-> onlyrowswithCurrentorMaximum Utilization > 80%ofLimit are shown

-> ordered byresourcename

CurrentMaximum Initial

Resource NameUtilization Utilization Allocation Limit

------------------------------ ------------ ------------ ---------- ----------

ges_procs 2,612 8,007 10003 10003

processes 2,615 8,011 10000 10000

數據源於dba_hist_resource_limit

注意這里僅列出當前使用或最大使用量>80% *最大限制的資源名，如果沒有列在這里則說明資源使用量安全

CurrentUtilization 當前對該資源(包括Enqueue Resource、Lock和processes)的使用量

Maximum Utilization 從最近一次實例啟動到現在該資源的最大使用量

Initial Allocation 初始分配值，一般等於參數文件中指定的值

Limit 實際上限值

17 init.ora Parameters

init.ora Parameters DB/Inst: MAC/MAC2 Snaps: 70719-70723

Endvalue

Parameter NameBeginvalue (if different)

----------------------------- --------------------------------- --------------

_compression_compatibility 11.2.0

_kghdsidx_count 4

_ksmg_granule_size 67108864

_shared_pool_reserved_min_all 4100

archive_lag_target 900

audit_file_dest /u01/app/oracle/admin/MAC/adum

audit_trail OS

cluster_database TRUE

compatible 11.2.0.2.0

control_files +DATA/MAC/control01.ctl, +RECO

db_16k_cache_size 268435456

db_block_size 8192

db_cache_size 19327352832

db_create_file_dest +DATA

Parameter Name參數名

Beginvalue 開始快照時的參數值

Endvalue 結束快照時的參數值 (僅在發生變化時打印)

18 GlobalMessagingStatistics

GlobalMessagingStatisticsDB/Inst: MAC/MAC2 Snaps: 70719-70723

Statistic Total per Secondper Trans

--------------------------------- ---------------- ------------ ------------

acks forcommitbroadcast(actual) 53,705 14.9 0.2

acks forcommitbroadcast(logical 311,182 86.1 1.3

broadcast msgs oncommit(actual) 317,082 87.7 1.3

broadcast msgs oncommit(logical) 317,082 87.7 1.3

broadcast msgs oncommit(wasted) 263,332 72.9 1.1

dynamically allocated gcs resourc 0 0.0 0.0

dynamically allocated gcs shadows 0 0.0 0.0

flow control messages received 267 0.1 0.0

flow control messages sent 127 0.0 0.0

gcs apply delta 0 0.0 0.0

gcs assume cvt 55,541 15.4 0.2

全局通信統計信息，數據來源WRH$_DLM_MISC;

20 GlobalCR Served Stats

GlobalCR Served Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723

Statistic Total

------------------------------ ------------------

CR Block Requests 403,703

CURRENTBlock Requests 444,896

Data Block Requests 403,705

Undo Block Requests 94,336

TX Block Requests 307,896

CurrentResults 652,746

Private results 21,057

Zero Results 104,720

Disk ReadResults 69,418

Fail Results 508

Fairness Down Converts 102,844

Fairness Clears 15,207

FreeGC Elements 0

Flushes 105,052

Flushes Queued 0

Flush Queue Full0

Flush MaxTime(us) 0

Light Works 71,793

Errors 117

LMS傳輸CR BLOCK的統計信息，數據來源WRH$_CR_BLOCK_SERVER

21 GlobalCURRENTServed Stats

GlobalCURRENTServed Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Pins = CURRENTBlock Pin Operations

-> Flushes = Redo Flush before CURRENTBlock Served Operations

-> Writes = CURRENTBlock Fusion Write Operations

Statistic Total % <1ms % <10ms % <100ms % <1s % <10s

---------- ------------ -------- -------- -------- -------- --------

Pins 73,018 12.27 75.96 8.49 2.21 1.08

Flushes 79,336 5.98 50.17 14.45 19.45 9.95

Writes 102,189 3.14 35.23 19.34 33.26 9.03

數據來源dba_hist_current_block_server

Timetoprocesscurrentblock request = (pintime+ flushtime+ sendtime)

Pins CURRENTBlock Pin Operations ， PIN的內涵是處理一個BAST 不包含對globalcurrentblock的flush和實際傳輸

The pin timerepresents how muchtimeisrequiredtoprocess a BAST. It doesnotinclude the flushtimeand

the send time. The average pintimeper block served should be very low because the processing consists

mainly ofcode pathandshould never be blocked.

Flush 指臟塊被LMS進程傳輸出去之前，其相關的redo必須由LGWR已經flush 到磁盤上

Write 指fusion write number ofwrites which were mediated；節點之間寫臟塊需求相互促成的行為 KJBL.KJBLREQWRITE gcs write request msgs 、gcs writes refused

% <1ms % <10ms % <100ms % <1s % <10s 分別對應為pin、flush、write行為耗時的比例

例如在上例中flush和 write 在1s 到10s之間的有9%，在100ms 和1s之間的有19%和33%，因為flush和write都是IO操作所以這里可以預見IO存在問題，延遲較高

22 GlobalCache Transfer Stats

GlobalCache Transfer Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723

-> Immediate (Immed) - Block Transfer NOTimpactedbyRemote Processing Delays

-> Busy (Busy) - Block Transfer impacted byRemote Contention

-> Congested (Congst) - Block Transfer impacted byRemote SystemLoad

-> ordered byCR +CurrentBlocks Receiveddesc

CR Current

----------------------------- -----------------------------

Inst Block Blocks % % % Blocks % % %

NoClass Received Immed Busy Congst Received Immed Busy Congst

---- ----------- -------- ------ ------ ------ -------- ------ ------ ------

1 data block 133,187 76.3 22.6 1.1 233,138 75.2 23.0 1.7

4 data block 143,165 74.1 24.9 1.0 213,204 76.6 21.8 1.6

3 data block 122,761 75.9 23.0 1.1 220,023 77.7 21.0 1.3

1 undo header 104,219 95.7 3.2 1.1 941 93.4 5.8 .7

4 undo header 95,823 95.2 3.7 1.1 809 93.4 5.3 1.2

3 undo header 95,592 95.6 3.3 1.1 912 94.6 4.5 .9

1 undo block 25,002 95.8 3.4 .9 0 N/A N/A N/A

4 undo block 23,303 96.0 3.1 .9 0 N/A N/A N/A

3 undo block 21,672 95.4 3.7 .9 0 N/A N/A N/A

1 Others 1,909 92.0 6.8 1.2 6,057 89.6 8.9 1.5

4 Others 1,736 92.4 6.1 1.5 5,841 88.8 9.9 1.3

3 Others 1,500 92.4 5.9 1.7 4,405 87.7 10.8 1.6

數據來源DBA_HIST_INST_CACHE_TRANSFER

Inst No節點號

Block Class 塊的類型

CR Blocks Received 該節點上該類型CR 塊的接收數量

CR Immed %: CR塊請求立即接收到的比例

CR Busy%：CR塊請求由於遠端爭用而沒有立即接收到的比例

CR Congst%: CR塊請求由於遠端負載高而沒有立即接收到的比例

CurrentBlocks Received 該節點上該類型Current塊的接收數量

CurrentImmed %:Current塊請求立即接收到的比例

CurrentBusy%：Current塊請求由於遠端爭用而沒有立即接收到的比例

CurrentCongst%:Current塊請求由於遠端負載高而沒有立即接收到的比例

Congst%的比例應當非常低不高於2%， Busy%很大程度受到IO的影響，如果超過10% 一般會有嚴重的gc buffer busy acquire/release

參考文檔

StatisticsDescriptions http://docs.oracle.com/cd/B19306_01/server.102/b14237/stats002.htm

Memory Configuration andUse http://docs.oracle.com/cd/B19306_01/server.102/b14211/memory.htm

Library Cache Hit (%) http://docs.oracle.com/cd/B16240_01/doc/doc.102/e16282/oracle_database_help/oracle_database_instance_efficiency_libcache_hit_pct.html

Oracle® DatabasePerformance Tuning Guide 12c Release 1 (12.1)

How toInterpret the “SQL orderedbyPhysical Reads (UnOptimized)”SectioninAWR Reports (11.2 onwards) [ID 1466035.1]