啥是AWR?
=====================================================================================================
AWR (Automatic Workload Repository)
一堆歷史性能數(shù)據(jù)，放在SYSAUX表空間上， AWR和SYSAUX都是10g出現(xiàn)的，是Oracle調(diào)優(yōu)的關(guān)鍵特性； 大約1999年左右開(kāi)始開(kāi)發(fā)，已經(jīng)有15年歷史
默認(rèn)快照間隔1小時(shí)，10g保存7天、11g保存8天; 可以通過(guò)DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS修改
DBA_HIST_WR_CONTROL
AWR程序核心是dbms_workload_repository包
@?/rdbms/admin/awrrpt 本實(shí)例
@?/rdbms/admin/awrrpti RAC中選擇實(shí)例號(hào)
誰(shuí)維護(hù)AWR?
主要是MMON(Manageability Monitor Process)和它的小工進(jìn)程(m00x)
MMON的功能包括:
1.啟動(dòng)slave進(jìn)程m00x去做AWR快照
2.當(dāng)某個(gè)度量閥值被超過(guò)時(shí)發(fā)出alert告警
3.為最近改變過(guò)的SQL對(duì)象捕獲指標(biāo)信息
AWR小技巧
1. 手動(dòng)執(zhí)行一個(gè)快照：
Exec dbms_workload_repository.create_snapshot;
2. 創(chuàng)建一個(gè)AWR基線
Exec DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id，end_snap_id ,baseline_name);
3. AWR比對(duì)報(bào)告
@?/rdbms/admin/awrddrpt
4. RAC 全局AWR
@?/rdbms/admin/awrgrpt
5. 自動(dòng)生成AWR HTML報(bào)告：
http://www.oracle-base.com/dba/10g/generate_multiple_awr_reports.sql
1、報(bào)告總結(jié)
Elapsed 為該AWR性能報(bào)告的時(shí)間跨度(自然時(shí)間的跨度，例如前一個(gè)快照snapshot是4點(diǎn)生成的，后一個(gè)快照snapshot是6點(diǎn)生成的，則若使用@?/rdbms/admin/awrrpt 腳本中指定這2個(gè)快照的話，那么其elapsed = (6-4)=2 個(gè)小時(shí))，一個(gè)AWR性能報(bào)告 至少需要2個(gè)AWR snapshot性能快照才能生成 ( 注意這2個(gè)快照時(shí)間 實(shí)例不能重啟過(guò)，否則指定這2個(gè)快照生成AWR性能報(bào)告 會(huì)報(bào)錯(cuò))，AWR性能報(bào)告中的 指標(biāo)往往是 后一個(gè)快照和前一個(gè)快照的 指標(biāo)的delta，這是因?yàn)?累計(jì)值并不能反映某段時(shí)間內(nèi)的系統(tǒng)workload。
DB TIME= 所有前臺(tái)session花費(fèi)在database調(diào)用上的總和時(shí)間：
注意是前臺(tái)進(jìn)程foreground sessions
包括CPU時(shí)間、IO Time、和其他一系列非空閑等待時(shí)間，別忘了cpu on queue time
DB TIME 不等于 響應(yīng)時(shí)間，DB TIME高了未必響應(yīng)慢，DB TIME低了未必響應(yīng)快
DB Time描繪了數(shù)據(jù)庫(kù)總體負(fù)載，但要和elapsed time逝去時(shí)間結(jié)合其他來(lái)。
Average Active Session ：AAS= DB time/Elapsed Time
DB Time =60 min ， Elapsed Time =60 min AAS=60/60=1 負(fù)載一般
DB Time= 1min , Elapsed Time= 60 min AAS= 1/60 負(fù)載很輕
DB Time= 60000 min，Elapsed Time= 60 min AAS=1000 系統(tǒng)hang了吧？
DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue
如果僅有2個(gè)邏輯CPU，而2個(gè)session在60分鐘都沒(méi)等待事件，一直跑在CPU上，那么：
DB CPU= 2 * 60 mins ， DB Time = 2* 60 + 0 + 0 =120
AAS = 120/60=2 正好等于OS load 2。
如果有3個(gè)session都100%僅消耗CPU，那么總有一個(gè)要wait on queue
DB CPU = 2* 60 mins ，wait on CPU queue= 60 mins
AAS= (120+ 60)/60=3 主機(jī)load 亦為3，此時(shí)vmstat 看waiting for run time
真實(shí)世界中？ DB Cpu = xx mins ， Non-Idle Wait= enq:TX + cursor pin S on X + latch : xxx + db file sequential read + ……….. 阿貓阿狗
1-1 內(nèi)存參數(shù)大小
內(nèi)存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)
Buffer cache和shared pool size的 begin/end值在ASMM、AMM和11gR2 MSMM下可是會(huì)動(dòng)的哦！
這里說(shuō) shared pool一直收縮，則在shrink過(guò)程中一些row cache 對(duì)象被lock住可能導(dǎo)致前臺(tái)row cache lock等解析等待，最好別讓shared pool shrink。如果這里shared pool一直在grow，那說(shuō)明shared pool原有大小不足以滿足需求(可能是大量硬解析)，結(jié)合下文的解析信息和SGA breakdown來(lái)一起診斷問(wèn)題。
1-2 Load Profile
指標(biāo)指標(biāo)含義
redo size單位 bytes，redo size可以用來(lái)估量update/insert/delete的頻率，大的redo size往往對(duì)lgwr寫日志，和arch歸檔造成I/O壓力， Per Transaction可以用來(lái)分辨是 大量小事務(wù)， 還是少量大事務(wù)。如上例每秒redo 約1MB ，每個(gè)事務(wù)800 字節(jié)，符合OLTP特征
Logical Read單位 次數(shù)*塊數(shù)， 相當(dāng)于 “人*次”， 如 196,888 * db_block_size=1538MB/s ， 邏輯讀耗CPU，主頻和CPU核數(shù)都很重要，邏輯讀高則DB CPU往往高，也往往可以看到latch: cache buffer chains等待。 大量OLTP系統(tǒng)(例如siebel)可以高達(dá)幾十乃至上百Gbytes。
Block changes單位 次數(shù)*塊數(shù) ， 描繪數(shù)據(jù)變化頻率
Physical Read單位次數(shù)*塊數(shù)， 如 5076 * 8k = 39MB/s， 物理讀消耗IO讀，體現(xiàn)在IOPS和吞吐量等不同緯度上；但減少物理讀可能意味著消耗更多CPU。好的存儲(chǔ) 每秒物理讀能力達(dá)到幾GB，例如Exadata。 這個(gè)physical read包含了physical reads cache和physical reads direct
Physical writes單位 次數(shù)*塊數(shù)，主要是DBWR寫datafile，也有direct path write。 dbwr長(zhǎng)期寫出慢會(huì)導(dǎo)致定期log file switch(checkpoint no complete) 檢查點(diǎn)無(wú)法完成的前臺(tái)等待。 這個(gè)physical write 包含了physical writes direct +physical writes from cache
User Calls單位次數(shù)，用戶調(diào)用數(shù)，more details from internal
Parses解析次數(shù)，包括軟解析+硬解析，軟解析優(yōu)化得不好，則夸張地說(shuō)幾乎等于每秒SQL執(zhí)行次數(shù)。 即執(zhí)行解析比1:1，而我們希望的是 解析一次 到處運(yùn)行哦！
Hard Parses萬(wàn)惡之源． Cursor pin s on X， library cache: mutex X ， latch: row cache objects /shared pool……………..。 硬解析最好少于每秒20次
W/A MB processed單位MB W/A workarea workarea中處理的數(shù)據(jù)數(shù)量
結(jié)合 In-memory Sort%， sorts (disk) PGA Aggr一起看
Logons登陸次數(shù)， logon storm 登陸風(fēng)暴，結(jié)合AUDIT審計(jì)數(shù)據(jù)一起看。短連接的附帶效應(yīng)是游標(biāo)緩存無(wú)用
Executes執(zhí)行次數(shù)，反應(yīng)執(zhí)行頻率
Rollback回滾次數(shù)， 反應(yīng)回滾頻率， 但是這個(gè)指標(biāo)不太精確，參考而已，別太當(dāng)真
Transactions每秒事務(wù)數(shù)，是數(shù)據(jù)庫(kù)層的TPS，可以看做壓力測(cè)試或比對(duì)性能時(shí)的一個(gè)指標(biāo)，孤立看無(wú)意義
% Blocks changed per Read每次邏輯讀導(dǎo)致數(shù)據(jù)塊變化的比率；如果’redo size’, ‘block changes’ ‘pct of blocks changed per read’三個(gè)指標(biāo)都很高，則說(shuō)明系統(tǒng)正執(zhí)行大量insert/update/delete;
pct of blocks changed per read = (block changes ) /( logical reads)
Recursive Call %遞歸調(diào)用的比率;Recursive Call % = (recursive calls)/(user calls)
Rollback per transaction %事務(wù)回滾比率。 Rollback per transaction %= (rollback)/(transactions)
Rows per Sort平均每次排序涉及到的行數(shù) ; Rows per Sort= ( sorts(rows) ) / ( sorts(disk) + sorts(memory))
注意這些Load Profile 負(fù)載指標(biāo) 在本環(huán)節(jié)提供了 2個(gè)維度 per second 和 per transaction。
per Second: 主要是把 快照內(nèi)的delta值除以 快站時(shí)間的秒數(shù) ， 例如 在 A快照中V$SYSSTAT視圖反應(yīng) table scans (long tables) 這個(gè)指標(biāo)是 100 ，在B快照中V$SYSSTAT視圖反應(yīng) table scans (long tables) 這個(gè)指標(biāo)是 3700, 而A快照和B快照 之間 間隔了一個(gè)小時(shí)3600秒， 則 對(duì)于 table scans (long tables) per second 就是 ( 3700- 100) /3600=1。
pert Second：是我們審視數(shù)據(jù)的主要維度 ，任何性能數(shù)據(jù)脫離了 時(shí)間模型則毫無(wú)意義。
在statspack/AWR出現(xiàn)之前 的調(diào)優(yōu) 洪荒時(shí)代， 有很多DBA 依賴 V$SYSSTAT等視圖中的累計(jì) 統(tǒng)計(jì)信息來(lái)調(diào)優(yōu)，以當(dāng)前的調(diào)優(yōu)眼光來(lái)看，那無(wú)異于刀耕火種。
per transaction : 基于事務(wù)的維度， 與per second相比 是把除數(shù)從時(shí)間的秒數(shù)改為了該段時(shí)間內(nèi)的事務(wù)數(shù)。 這個(gè)維度的很大用戶是用來(lái) 識(shí)別應(yīng)用特性的變化 ，若2個(gè)AWR性能報(bào)告中該維度指標(biāo) 出現(xiàn)了大幅變化，例如 redo size從本來(lái)per transaction 1k變化為 10k per transaction，則說(shuō)明SQL業(yè)務(wù)邏輯肯定發(fā)生了某些變化。
注意AWR中的這些指標(biāo) 并不僅僅用來(lái)孤立地了解 Oracle數(shù)據(jù)庫(kù)負(fù)載情況， 實(shí)施調(diào)優(yōu)工作。 對(duì)于 故障診斷 例如HANG、Crash等， 完全可以通過(guò)對(duì)比問(wèn)題時(shí)段的性能報(bào)告和常規(guī)時(shí)間來(lái)對(duì)比，通過(guò)各項(xiàng)指標(biāo)的對(duì)比往往可以找出 病灶所在。
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 Execute to Parse %: 94.82 Latch Hit %: 99.95Parse CPU to Parse Elapsd %: 1.75 % Non-Parse CPU: 99.85
上述所有指標(biāo) 的目標(biāo)均為100%，即越大越好，在少數(shù)bug情況下可能超過(guò)100%或者為負(fù)值。
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申請(qǐng)一個(gè)buffer(兼容模式)不等待的次數(shù)比例。 需要訪問(wèn)buffer時(shí)立即可以訪問(wèn)的比率， 不兼容的情況 在9i中是 buffer busy waits，從10g以后 buffer busy waits 分離為 buffer busy wait 和 read by other session2個(gè)等待事件 :
9i 中 waitstat的總次數(shù)基本等于buffer busy waits等待事件的次數(shù)SQL> select sum(TOTAL_WAITS) from v$system_event where event='buffer busy waits';SUM(TOTAL_WAITS)—————-33070394SQL> select sum(count) from v$waitstat;SUM(COUNT)———-3306933510g waitstat的總次數(shù)基本等于 buffer busy waits 和 read by other session 等待的次數(shù)總和SQL> select sum(TOTAL_WAITS) from v$system_event where event='buffer busy waits' or event='read by other session';SUM(TOTAL_WAITS)—————-60675815SQL> select sum(count) from v$waitstat;SUM(COUNT)———-60423739
Buffer Nowait %的計(jì)算公式是 sum(v$waitstat.wait_count) / (v$sysstat statistic session logical reads)，例如在AWR中：
ClassWaitsTotal Wait Time (s)Avg Time (ms)
data block24,5432,26792
undo header74323
undo block1,11600
1st level bmb3500
session logical reads40,769,80022,544.84204.71
Buffer Nowait %:99.94
Buffer Nowait= ( 40,769,800 – (24543+743+1116+35))/ ( 40,769,800) = 0.99935= 99.94%
SELECT SUM(WAIT_COUNT) FROM DBA_HIST_WAITSTAT WHERE SNAP_ID = :B3 AND DBID = :B2 AND INSTANCE_NUMBER = :B1
2、buffer HIT%: 經(jīng)典的經(jīng)典，高速緩存命中率，反應(yīng)物理讀和緩存命中間的糾結(jié)，但這個(gè)指標(biāo)即便99% 也不能說(shuō)明物理讀等待少了
不合理的db_cache_size，或者是SGA自動(dòng)管理ASMM /Memory 自動(dòng)管理AMM下都可能因?yàn)閐b_cache_size過(guò)小引起大量的db file sequential /scattered read等待事件； maclean曾經(jīng)遇到過(guò)因?yàn)榇罅坑步馕鰧?dǎo)致ASMM 下shared pool共享池大幅度膨脹，而db cache相應(yīng)縮小shrink的例子，最終db cache收縮到只有幾百兆，本來(lái)沒(méi)有的物理讀等待事件都大幅涌現(xiàn)出來(lái) 。
此外與 buffer HIT%相關(guān)的指標(biāo)值得關(guān)注的還有 table scans(long tables) 大表掃描這個(gè)統(tǒng)計(jì)項(xiàng)目、此外相關(guān)的欄目還有Buffer Pool Statistics 、Buffer Pool Advisory等（如果不知道在哪里，直接找一個(gè)AWR 去搜索這些關(guān)鍵詞即可)。
buffer HIT%在 不同版本有多個(gè)計(jì)算公式：
在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 from cache’ + ‘db block gets from cache’)
注意：但是實(shí)際AWR中 似乎還是按照9i中的算法，雖然算法的區(qū)別對(duì)最后算得的比率影響不大。
對(duì)于buffer hit % 看它的命中率有多高沒(méi)有意義，主要是關(guān)注 未命中的次數(shù)有多少。通過(guò)上述公式很容易反推出未命中的物理讀的次數(shù)。
db block gets 、consistent gets 以及 session logical reads的關(guān)系如下：
db block gets＝db block gets direct＋ db block gets from cache
consistent gets?。健onsistent gets from cache＋ consistent gets direct
consistent gets from cache＝ consistent gets – examination + else
consistent gets – examination==>指的是不需要pin buffer直接可以執(zhí)行consistent get的次數(shù)，常用于索引，只需要一次latch get
session logical reads = db block gets +consistent gets
其中physical reads 、physical reads cache、physical reads direct、physical reads direct (lob)幾者的關(guān)系為：
physical reads = physical reads cache + physical reads direct
這個(gè)公式其實(shí)說(shuō)明了 物理讀有2種 ：
物理讀進(jìn)入buffer cache中 ，是常見(jiàn)的模式 physical reads cache
物理讀直接進(jìn)入PGA 直接路徑讀， 即physical reads direct
physical reads8Total number of data blocks read from disk. This value can be greater than the value of “physical reads direct” plus “physical reads cache” as reads into process private buffers also included in this statistic.
physical reads cache8Total number of data blocks read from disk into the buffer cache. This is a subset of “physical reads” statistic.
physical reads direct8Number of reads directly from disk, bypassing the buffer cache. For example, in high bandwidth, data-intensive operations such as parallel query, reads of disk blocks bypass the buffer cache to maximize transfer rates and to prevent the premature aging of shared data blocks resident in the buffer cache.
physical reads direct = physical reads direct (lob) + physical reads direct temporary tablespace + physical reads direct(普通)
這個(gè)公式也說(shuō)明了 直接路徑讀 分成三個(gè)部分：
physical reads direct (lob) 直接路徑讀LOB對(duì)象
physical reads direct temporary tablespace 直接路徑讀臨時(shí)表空間
physical read direct(普通) 普通的直接路徑讀， 一般是11g開(kāi)始的自動(dòng)的大表direct path read和并行引起的direct path read
physical writes direct= physical writes direct (lob)+ physical writes direct temporary tablespace
DBWR checkpoint buffers written = DBWR thread checkpoint buffers written+ DBWR tablespace checkpoint buffers written+ DBWR PQ tablespace checkpoint buffers written+….
3、Redo nowait%: session在生成redo entry時(shí)不用等待的比例，redo相關(guān)的資源爭(zhēng)用例如redo space request爭(zhēng)用可能造成生成redo時(shí)需求等待。此項(xiàng)數(shù)據(jù)來(lái)源于v$sysstat中的(redo log space requests/redo entries)。 一般來(lái)說(shuō)10g以后不太用關(guān)注log_buffer參數(shù)的大小，需要關(guān)注是否有十分頻繁的 log switch ； 過(guò)小的redo logfile size 如果配合較大的SGA和頻繁的commit提交都可能造成該問(wèn)題。 考慮增到redo logfile 的尺寸 : 1~4G 每個(gè)，7~10組都是合適的。同時(shí)考慮優(yōu)化redo logfile和datafile 的I/O。
4、In-memory Sort%:這個(gè)指標(biāo)因?yàn)樗挥?jì)算workarea中所有的操作類型，所以現(xiàn)在越來(lái)越雞肋了。 純粹在內(nèi)存中完成的排序比例。數(shù)據(jù)來(lái)源于v$sysstat statistics sorts (disk) 和 sorts (memory)， In-memory Sort% = sort(memory) / ( sort(disk)+ sort(memory) )
5、Library Hit%: library cache命中率，申請(qǐng)一個(gè)library cache object例如一個(gè)SQL cursor時(shí)，其已經(jīng)在library cache中的比例。 數(shù)據(jù)來(lái)源 V$librarycache的pins和pinhits。 合理值：>95% ，該比例來(lái)源于1- ( Σ(pin Requests * Pct Miss) / Sum(Pin Requests) )
維護(hù)這個(gè)指標(biāo)的重點(diǎn)是 保持shared pool共享池有足夠的Free Memory，且沒(méi)有過(guò)多的內(nèi)存碎片，具體可以參考這里。 顯然過(guò)小的shared pool可用空間會(huì)導(dǎo)致library cache object被aged out換出共享池。此外保證SQL語(yǔ)句綁定變量和游標(biāo)可以共享也是很重要的因素。
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 0CLUSTER 10 0.0 26 0.0 0 0SQL AREA 601,357 99.8 902,828 99.7 47 2TABLE/PROCEDURE 83 9.6 601,443 0.0 48 0GETSNUMBERNumber of times a lock was requested for objects of this namespace
GETHITSNUMBERNumber of times an object’s handle was found in memory
GETHITRATIONUMBERRatio of GETHITS to GETS
PINSNUMBERNumber of times a PIN was requested for objects of this namespace
PINHITSNUMBERNumber of times all of the metadata pieces of the library object were found in memory
PINHITRATIONUMBERRatio of PINHITS to PINS
RELOADSNUMBERAny PIN of an object that is not the first PIN performed since the object handle was created, and which requires loading the object from disk
INVALIDATIONSNUMBERTotal number of times objects in this namespace were marked invalid because a dependent object was modified
SELECT SUM(PINS), SUM(PINHITS) FROM DBA_HIST_LIBRARYCACHE WHERE SNAP_ID = :B3 AND DBID = :B2 AND INSTANCE_NUMBER = :B1
6、Soft Parse: 軟解析比例，無(wú)需多說(shuō)的經(jīng)典指標(biāo)，數(shù)據(jù)來(lái)源v$sysstat statistics的parse count(total)和parse count(hard)。 合理值>95%
Soft Parse %是AWR中另一個(gè)重要的解析指標(biāo)，該指標(biāo)反應(yīng)了快照時(shí)間內(nèi) 軟解析次數(shù) 和 總解析次數(shù) (soft+hard 軟解析次數(shù)+硬解析次數(shù))的比值，若該指標(biāo)很低，那么說(shuō)明了可能存在劇烈的hard parse硬解析，大量的硬解析會(huì)消耗更多的CPU時(shí)間片并產(chǎn)生解析爭(zhēng)用(此時(shí)可以考慮使用cursor_sharing=FORCE)； 理論上我們總是希望 Soft Parse % 接近于100%， 但并不是說(shuō)100%的軟解析就是最理想的解析狀態(tài)，
通過(guò)設(shè)置 session_cached_cursors參數(shù)和反復(fù)重用游標(biāo)我們可以讓解析來(lái)的更輕量級(jí)，即通俗所說(shuō)的利用會(huì)話緩存游標(biāo)實(shí)現(xiàn)的軟軟解析(soft soft parse)。
7、Execute to Parse% 指標(biāo)反映了執(zhí)行解析比 其公式為 1-(parse/execute) , 目標(biāo)為100% 及接近于只 執(zhí)行而不解析。 數(shù)據(jù)來(lái)源v$sysstat statistics parse count (total) 和execute count
在oracle中解析往往是執(zhí)行的先提工作，但是通過(guò)游標(biāo)共享 可以解析一次 執(zhí)行多次， 執(zhí)行解析可能分成多種場(chǎng)景：
hard coding => 硬編碼代碼 硬解析一次 ，執(zhí)行一次， 則理論上其執(zhí)行解析比 為 1:1 ，則理論上Execute to Parse =0 極差，且soft parse比例也為0%
綁定變量但是仍軟解析=》 軟解析一次，執(zhí)行一次 ， 這種情況雖然比前一種好 但是執(zhí)行解析比(這里的parse，包含了軟解析和硬解析)仍是1:1， 理論上Execute to Parse =0 極差， 但是soft parse比例可能很高
使用 靜態(tài)SQL、動(dòng)態(tài)綁定、session_cached_cursor、open cursors等技術(shù)實(shí)現(xiàn)的 解析一次，執(zhí)行多次， 執(zhí)行解析比為N:1， 則 Execute to Parse= 1- (1/N) 執(zhí)行次數(shù)越多 Execute to Parse越接近100% ，這種是我們?cè)贠LTP環(huán)境中喜聞樂(lè)見(jiàn)的！
通俗地說(shuō) soft parse% 反映了軟解析率， 而軟解析在oracle中仍是較昂貴的操作， 我們希望的是解析1次執(zhí)行N次，如果每次執(zhí)行均需要軟解析，那么雖然soft parse%=100% 但是parse time仍可能是消耗DB TIME的大頭。
Execute to Parse反映了 執(zhí)行解析比，Execute to Parse和soft parse% 都很低 那么說(shuō)明確實(shí)沒(méi)有綁定變量 ， 而如果 soft parse% 接近99% 而Execute to Parse 不足90% 則說(shuō)明沒(méi)有執(zhí)行解析比低， 需要通過(guò) 靜態(tài)SQL、動(dòng)態(tài)綁定、session_cached_cursor、open cursors等技術(shù)減少軟解析。
8、Latch Hit%: willing-to-wait latch閂申請(qǐng)不要等待的比例。 數(shù)據(jù)來(lái)源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 0library cache 6,753,468 152 6 146 0 0 0Memory Management Latch 369 1 1 0 0 0 0qmn task queue latch 24 1 1 0 0 0 0
Latch Hit%:= (1 – (Sum(misses) / Sum(gets)))
關(guān)于Latch的更多信息內(nèi)容可以參考 AWR后面的專欄Latch Statistics， 注意對(duì)于一個(gè)并發(fā)設(shè)計(jì)良好的OLTP應(yīng)用來(lái)說(shuō)，Latch、Enqueue等并發(fā)控制不應(yīng)當(dāng)成為系統(tǒng)的主要瓶頸， 同時(shí)對(duì)于這些并發(fā)爭(zhēng)用而言 堆積硬件CPU和內(nèi)存 很難有效改善性能。
SELECT SUM(GETS), SUM(MISSES) FROM DBA_HIST_LATCH WHERE SNAP_ID = :B3 AND DBID = :B2 AND INSTANCE_NUMBER = :B1
9、Parse CPU To Parse Elapsd:該指標(biāo)反映了 快照內(nèi)解析CPU時(shí)間和總的解析時(shí)間的比值(Parse CPU Time/ Parse Elapsed Time)； 若該指標(biāo)水平很低，那么說(shuō)明在整個(gè)解析過(guò)程中 實(shí)際在CPU上運(yùn)算的時(shí)間是很短的，而主要的解析時(shí)間都耗費(fèi)在各種其他非空閑的等待事件上了(如latch:shared pool,row cache lock之類等) 數(shù)據(jù)來(lái)源 V$sysstat 的 parse time cpu和parse time elapsed
10、%Non-Parse CPU ：非解析cpu比例，公式為 (DB CPU – Parse CPU)/DB CPU， 若大多數(shù)CPU都用在解析上了，則可能好鋼沒(méi)用在刃上了。 數(shù)據(jù)來(lái)源 v$sysstat 的 parse time cpu和 cpu used by this session
1-4 Shared Pool Statistics
該環(huán)節(jié)提供一個(gè)大致的SQL重用及shared pool內(nèi)存使用的評(píng)估。 應(yīng)用是否共享SQL? 有多少內(nèi)存是給只運(yùn)行一次的SQL占掉的，對(duì)比共享SQL呢？
如果該環(huán)節(jié)中% SQL with executions>1的 比例 小于%90 ， 考慮用下面鏈接的SQL去抓 硬編碼的非綁定變量SQL語(yǔ)句。
Memory Usage %: (shared pool 的實(shí)時(shí)大小- shared pool free memory)/ shared pool 的實(shí)時(shí)大小， 代表shared pool的空間使用率，雖然有使用率但沒(méi)有標(biāo)明碎片程度
% SQL with executions>1 ：復(fù)用的SQL占總的SQL語(yǔ)句的比率,數(shù)據(jù)來(lái)源 DBA_HIST_SQL_SUMMARY 的 SINGLE_USE_SQL和TOTAL_SQL：1 – SINGLE_USE_SQL / TOTAL_SQL
% Memory for SQL w/exec>1 ： 執(zhí)行2次以上的SQL所占內(nèi)存占總的SQL內(nèi)存的比率，數(shù)據(jù)來(lái)源DBA_HIST_SQL_SUMMARY 的SINGLE_USE_SQL_MEM和TOTAL_SQL_MEM：1 – SINGLE_USE_SQL_MEM / TOTAL_SQL_MEM
==》上面2個(gè)指標(biāo)也可以用來(lái)大致了解shared pool中的內(nèi)存碎片程序，因?yàn)镾INGLE_USE_SQL 單次執(zhí)行的SQL多的話，那么顯然可能有較多的共享池內(nèi)存碎片
SQL復(fù)用率低的原因一般來(lái)說(shuō)就是硬綁定變量(hard Coding)未合理使用綁定變量(bind variable)，對(duì)于這種現(xiàn)象短期無(wú)法修改代表使用綁定變量的可以ALTER SYSTEM SET CURSOR_SHARING=FORCE; 來(lái)繞過(guò)問(wèn)題，對(duì)于長(zhǎng)期來(lái)看還是要修改代碼綁定變量。 Oracle 從11g開(kāi)始宣稱今后將廢棄CURSOR_SHARING的SIMILAR選項(xiàng)，同時(shí)SIMILAR選項(xiàng)本身也造成了很多問(wèn)題，所以一律不推薦用CURSOR_SHARING=SIMILAR。
如果memory usage%比率一直很高，則可以關(guān)注下后面sga breakdown中的shared pool free memory大小，一般推薦至少讓free memroy有個(gè)300~500MB 以避免隱患。
1-5 Top 10 Foreground Events by Total Wait Time
基于Wait Interface的調(diào)優(yōu)是目前的主流！每個(gè)指標(biāo)都重要！
基于命中比例的調(diào)優(yōu)，好比是統(tǒng)計(jì)局的報(bào)告， 張財(cái)主家財(cái)產(chǎn)100萬(wàn)，李木匠家財(cái)產(chǎn)1萬(wàn)， 平均財(cái)產(chǎn)50.5萬(wàn)。
基于等待事件的調(diào)優(yōu)，好比馬路上100輛汽車的行駛記錄表，上車用了幾分鐘， 紅燈等了幾分鐘，擁堵塞了幾分鐘。。。
豐富的等待事件以足夠的細(xì)節(jié)來(lái)描繪系統(tǒng)運(yùn)行的性能瓶頸，這是Mysql夢(mèng)寐以求的東西……
Waits : 該等待事件發(fā)生的次數(shù)， 對(duì)于DB CPU此項(xiàng)不可用
Times : 該等待事件消耗的總計(jì)時(shí)間，單位為秒， 對(duì)于DB CPU 而言是前臺(tái)進(jìn)程所消耗CPU時(shí)間片的總和，但不包括Wait on CPU QUEUE
Avg Wait(ms) : 該等待事件平均等待的時(shí)間， 實(shí)際就是 Times/Waits，單位ms， 對(duì)于DB CPU此項(xiàng)不可用
% Total Call Time， 該等待事件占總的call time的比率
total call time = total CPU time + total wait time for non-idle events
% Total Call Time = time for each timed event / total call time
Wait Class: 等待類型：Concurrency,System I/O,User I/O,Administrative,Other,Configuration,Scheduler,Cluster,Application,Idle,Network,Commit
幾種常見(jiàn)的等待事件
=========================>
enq:XX 隊(duì)列鎖等待，視乎不同的隊(duì)列鎖有不同的情況：
你有多了解Oracle Enqueue lock隊(duì)列鎖機(jī)制？Oracle隊(duì)列鎖: Enqueue HWOracle隊(duì)列鎖enq:US,Undo Segmentenq: TX – row lock/index contention、allocate ITL等待事件enq: TT – contention等待事件Oracle隊(duì)列鎖enq:TS,Temporary Segment (also TableSpace)enq: JI – contention等待事件enq: US – contention等待事件enq: TM – contention等待事件enq: RO fast object reuse等待事件enq: HW – contention等待事件free buffer waits：是由于無(wú)法找到可用的buffer cache 空閑區(qū)域，需要等待DBWR 寫入完成引起
一般是由于
低效的sql
過(guò)小的buffer cache
DBWR 工作負(fù)荷過(guò)量
buffer busy wait/ read by other session 一般以上2個(gè)等待事件可以歸為一起處理，建議客戶都進(jìn)行監(jiān)控 。 以上等待時(shí)間可以由如下操作引起
select/select —- read by other session: 由于需要從 數(shù)據(jù)文件中將數(shù)據(jù)塊讀入 buffer cache 中引起，有可能是 大量的 邏輯/物理讀 ;或者過(guò)小的 buffer cache 引起
select/update —- buffer busy waits/ read by other session 是由于更新某數(shù)據(jù)塊后 需要在undo 中 重建構(gòu)建 過(guò)去時(shí)間的塊，有可能伴生 enq:cr-contention 是由于大量的物理讀/邏輯讀造成。
update/update —- buffer busy waits 由于更新同一個(gè)數(shù)據(jù)塊（非同一行，同一行是enq:TX-contention） 此類問(wèn)題是熱點(diǎn)塊造成
insert/insert —- buffer busy waits 是由于freelist 爭(zhēng)用造成，可以將表空間更改為ASSM 管理 或者加大freelist 。
write complete waits :一般此類等待事件是由于 DBWR 將臟數(shù)據(jù)寫入 數(shù)據(jù)文件，其他進(jìn)程如果需要修改 buffer cache會(huì)引起此等待事件，一般是 I/O 性能問(wèn)題或者是DBWR 工作負(fù)荷過(guò)量引起
Wait time 1 Seconds.
control file parallel write：頻繁的更新控制文件會(huì)造成大量此類等待事件，如日志頻繁切換，檢查點(diǎn)經(jīng)常發(fā)生，nologging 引起頻繁的數(shù)據(jù)文件更改，I/O 系統(tǒng)性能緩慢。
log file sync：一般此類等待時(shí)間是由于 LGWR 進(jìn)程講redo log buffer 寫入redo log 中發(fā)生。如果此類事件頻繁發(fā)生，可以判斷為：
commit 次數(shù)是否過(guò)多
I/O 系統(tǒng)問(wèn)題
重做日志是否不必要被創(chuàng)建
redo log buffer 是否過(guò)大
2-1 Time Model Statistics
Time Model Statistics DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> Total time in database user-calls (DB Time): 883542.2s-> Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic-> Ordered by % or DB time desc, Statistic nameStatistic Name Time (s) % of DB Time------------------------------------------ ------------------ ------------sql execute elapsed time 805,159.7 91.1sequence load elapsed time 41,159.2 4.7DB CPU 20,649.1 2.3parse time elapsed 1,112.8 .1hard parse elapsed time 995.2 .1hard parse (sharing criteria) elapsed time 237.3 .0hard parse (bind mismatch) elapsed time 227.6 .0connection management call elapsed time 29.7 .0PL/SQL execution elapsed time 9.2 .0PL/SQL compilation elapsed time 6.6 .0failed parse elapsed time 2.0 .0repeated bind elapsed time 0.4 .0DB time 883,542.2background elapsed time 25,439.0background cpu time 1,980.9 -------------------------------------------------------------
Time Model Statistics幾個(gè)特別有用的時(shí)間指標(biāo)：
parse time elapsed、hard parse elapsed time 結(jié)合起來(lái)看解析是否是主要矛盾，若是則重點(diǎn)是軟解析還是硬解析
sequence load elapsed time sequence序列爭(zhēng)用是否是問(wèn)題焦點(diǎn)
PL/SQL compilation elapsed time PL/SQL對(duì)象編譯的耗時(shí)
注意PL/SQL execution elapsed time 純耗費(fèi)在PL/SQL解釋器上的時(shí)間。不包括花在執(zhí)行和解析其包含SQL上的時(shí)間
connection management call elapsed time 建立數(shù)據(jù)庫(kù)session連接和斷開(kāi)的耗時(shí)
failed parse elapsed time 解析失敗，例如由于ORA-4031
hard parse (sharing criteria) elapsed time 由于無(wú)法共享游標(biāo)造成的硬解析
hard parse (bind mismatch) elapsed time 由于bind type or bind size 不一致造成的硬解析
注意該時(shí)間模型中的指標(biāo)存在包含關(guān)系所以Time Model Statistics加起來(lái)超過(guò)100%再正常不過(guò)
1) background elapsed time 2) background cpu time 3) RMAN cpu time (backup/restore)1) DB time 2) DB CPU 2) connection management call elapsed time 2) sequence load elapsed time 2) sql execute elapsed time 2) parse time elapsed 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 (out of shared memory) elapsed time 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 time2-2 Foreground Wait Class
Foreground Wait Class -> s - second, ms - millisecond - 1000th of a second-> ordered by wait time desc, waits desc-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0 -> Captured Time accounts for 102.7% of Total DB time 883,542.21 (s)-> Total FG Wait Time: 886,957.73 (s) DB CPU time: 20,649.06 (s) Avg %Time Total Wait waitWait Class Waits -outs Time (s) (ms) %DB time-------------------- ---------------- ----- ---------------- -------- ---------Cluster 9,825,884 1 525,134 53 59.4Concurrency 688,375 0 113,782 165 12.9User I/O 34,405,042 0 76,695 2 8.7Commit 172,193 0 62,776 365 7.1Application 11,422 0 57,760 5057 6.5Configuration 19,418 1 48,889 2518 5.5DB CPU 20,649 2.3Other 1,757,896 94 924 1 0.1System I/O 30,165 0 598 20 0.1Network 171,955,673 0 400 0 0.0Administrative 2 100 0 101 0.0 -------------------------------------------------------------select distinct wait_class from v$event_name;WAIT_CLASS----------------------------------------------------------------ConcurrencyUser I/OSystem I/OAdministrativeOtherConfigurationSchedulerClusterApplicationQueueingIdleNetworkCommitWait Class: 等待事件的類型，如上查詢所示，被分作12個(gè)類型。 10.2.0.5有916個(gè)等待事件，其中Other類型占622個(gè)。
Waits: 該類型所屬等待事件在快照時(shí)間內(nèi)的等待次數(shù)
%Time Out 等待超時(shí)的比率， 未 超時(shí)次數(shù)/waits * 100 (%)
Total Wait Time: 該類型所屬等待事件總的耗時(shí)，單位為秒
Avg Wait(ms) : 該類型所屬等待事件的平均單次等待時(shí)間，單位為ms ，實(shí)際這個(gè)指標(biāo)對(duì)commit 和 user i/o 以及system i/o類型有點(diǎn)意義，其他等待類型由于等待事件差異較大所以看平均值的意義較小
waits / txn: 該類型所屬等待事件的等待次數(shù)和事務(wù)比
Other 類型，遇到該類型等待事件 的話 常見(jiàn)的原因是Oracle Bug或者 網(wǎng)絡(luò)、I/O存在問(wèn)題， 一般推薦聯(lián)系Maclean。
Concurrency 類型 并行爭(zhēng)用類型的等待事件， 典型的如 latch: shared pool、latch: library cache、row cache lock、library cache pin/lock
Cluster 類型 為Real Application Cluster RAC環(huán)境中的等待事件， 需要注意的是 如果啟用了RAC option，那么即使你的集群中只啟動(dòng)了一個(gè)實(shí)例，那么該實(shí)例也可能遇到 Cluster類型的等待事件, 例如gc buffer busy
System I/O 主要是后臺(tái)進(jìn)程維護(hù)數(shù)據(jù)庫(kù)所產(chǎn)生的I/O，例如control file parallel write 、log file parallel write、db file parallel write。
User I/O 主要是前臺(tái)進(jìn)程做了一些I/O操作，并不是說(shuō)后臺(tái)進(jìn)程不會(huì)有這些等待事件。 典型的如db file sequential/scattered read、direct path read
Configuration 由于配置引起的等待事件， 例如 日志切換的log file switch completion (日志文件 大小/數(shù)目 不夠)，sequence的enq: SQ – contention (Sequence 使用nocache) ； Oracle認(rèn)為它們是由于配置不當(dāng)引起的，但實(shí)際未必真是這樣的配置引起的。
Application 應(yīng)用造成的等待事件， 例如enq: TM – contention和enq: TX – row lock contention； Oracle認(rèn)為這是由于應(yīng)用設(shè)計(jì)不當(dāng)造成的等待事件， 但實(shí)際這些Application class 等待可能受到 Concurrency、Cluster、System I/O 、User I/O等多種類型等待的影響，例如本來(lái)commit只要1ms ，則某一行數(shù)據(jù)僅被鎖定1ms， 但由于commit變慢 從而釋放行鎖變慢，引發(fā)大量的enq: TX – row lock contention等待事件。
Commit 僅log file sync ，log file sync的影響十分廣泛，值得我們深入討論。
Network : 網(wǎng)絡(luò)類型的等待事件 例如 SQL*Net more data to client 、SQL*Net more data to dblink
Idle 空閑等待事件 ，最為常見(jiàn)的是rdbms ipc message (等待實(shí)例內(nèi)部的ipc通信才干活，即別人告知我有活干，我才干，否則我休息==》Idle)， SQL*Net message from client(等待SQL*NET傳來(lái)信息，否則目前沒(méi)事干)
2-3 前臺(tái)等待事件
Foreground Wait Events Snaps: 70719-70723-> s - second, ms - millisecond - 1000th of a second-> Only events with Total Wait Time (s) >= .001 are shown-> ordered by wait time desc, waits desc (idle events last)-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0 Avg %Time Total Wait wait Waits % DBEvent Waits -outs Time (s) (ms) /txn time-------------------------- ------------ ----- ---------- ------- -------- ------gc buffer busy acquire 3,274,352 3 303,088 93 13.3 34.3gc buffer busy release 387,673 2 128,114 330 1.6 14.5enq: TX - index contention 193,918 0 97,375 502 0.8 11.0cell single block physical 30,738,730 0 63,606 2 124.8 7.2log file sync 172,193 0 62,776 365 0.7 7.1gc current block busy 146,154 0 53,027 363 0.6 6.0enq: TM - contention 1,060 0 47,228 44555 0.0 5.3enq: SQ - contention 17,431 0 35,683 2047 0.1 4.0gc cr block busy 105,204 0 33,746 321 0.4 3.8buffer busy waits 279,721 0 12,646 45 1.1 1.4enq: HW - contention 1,201 3 12,192 10151 0.0 1.4enq: TX - row lock content 9,231 0 10,482 1135 0.0 1.2cell multiblock physical r 247,903 0 6,547 26 1.0 .7
Foreground Wait Events 前臺(tái)等待事件，數(shù)據(jù)主要來(lái)源于DBA_HIST_SYSTEM_EVENT
Event 等待事件名字
Waits 該等待事件在快照時(shí)間內(nèi)等待的次數(shù)
%Timeouts : 每一個(gè)等待事件有其超時(shí)的設(shè)置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件 單次等待達(dá)到timeout的時(shí)間，則會(huì)進(jìn)入下一次該等待事件
Total Wait Time 該等待事件 總的消耗的時(shí)間 ，單位為秒
Avg wait(ms): 該等待事件的單次平均等待時(shí)間，單位為毫秒
Waits/Txn: 該等待事件的等待次數(shù)和事務(wù)比
2-4 后臺(tái)等待事件
Background Wait Events Snaps: 70719-70723-> ordered by wait time desc, waits desc (idle events last)-> Only events with Total Wait Time (s) >= .001 are shown-> %Timeouts: value of 0 indicates value was < .5%. Value of null is truly 0 Avg %Time Total Wait wait Waits % bgEvent Waits -outs Time (s) (ms) /txn time-------------------------- ------------ ----- ---------- ------- -------- ------db file parallel write 90,979 0 7,831 86 0.4 30.8gcs log flush sync 4,756,076 6 4,714 1 19.3 18.5enq: CF - contention 2,123 40 4,038 1902 0.0 15.9control file sequential re 90,227 0 2,380 26 0.4 9.4log file parallel write 108,383 0 1,723 16 0.4 6.8control file parallel writ 4,812 0 988 205 0.0 3.9Disk file operations I/O 26,216 0 731 28 0.1 2.9flashback log file write 9,870 0 720 73 0.0 2.8LNS wait on SENDREQ 202,747 0 600 3 0.8 2.4ASM file metadata operatio 15,801 0 344 22 0.1 1.4cell single block physical 39,283 0 341 9 0.2 1.3LGWR-LNS wait on channel 183,443 18 203 1 0.7 .8gc current block busy 122 0 132 1082 0.0 .5gc buffer busy release 60 12 127 2113 0.0 .5Parameter File I/O 592 0 116 195 0.0 .5log file sequential read 1,804 0 104 58 0.0 .4
Background Wait Events 后臺(tái)等待事件， 數(shù)據(jù)主要來(lái)源于DBA_HIST_BG_EVENT_SUMMARY
Event 等待事件名字
Waits 該等待事件在快照時(shí)間內(nèi)等待的次數(shù)
%Timeouts : 每一個(gè)等待事件有其超時(shí)的設(shè)置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件 單次等待達(dá)到timeout的時(shí)間，則會(huì)進(jìn)入下一次該等待事件
Total Wait Time 該等待事件 總的消耗的時(shí)間 ，單位為秒
Avg wait(ms): 該等待事件的單次平均等待時(shí)間，單位為毫秒
Waits/Txn: 該等待事件的等待次數(shù)和事務(wù)比
2-5 Operating System Statistics
Operating System Statistics Snaps: 70719-70723TIME statistic values are diffed. All others display actual values. End Value is displayed if different-> ordered by statistic type (CPU Use, Virtual Memory, Hardware Config), NameStatistic Value End Value------------------------- ---------------------- ----------------BUSY_TIME 2,894,855IDLE_TIME 5,568,240IOWAIT_TIME 18,973SYS_TIME 602,532USER_TIME 2,090,082LOAD 8 13VM_IN_BYTES 0VM_OUT_BYTES 0PHYSICAL_MEMORY_BYTES 101,221,343,232NUM_CPUS 24NUM_CPU_CORES 12NUM_CPU_SOCKETS 2GLOBAL_RECEIVE_SIZE_MAX 4,194,304GLOBAL_SEND_SIZE_MAX 2,097,152TCP_RECEIVE_SIZE_DEFAULT 87,380TCP_RECEIVE_SIZE_MAX 4,194,304TCP_RECEIVE_SIZE_MIN 4,096TCP_SEND_SIZE_DEFAULT 16,384TCP_SEND_SIZE_MAX 4,194,304TCP_SEND_SIZE_MIN 4,096 -------------------------------------------------------------
Operating System Statistics 操作系統(tǒng)統(tǒng)計(jì)信息
數(shù)據(jù)來(lái)源于V$OSSTAT / DBA_HIST_OSSTAT，, TIME相關(guān)的指標(biāo)單位均為百分之一秒
統(tǒng)計(jì)項(xiàng)描述
NUM_CPU_SOCKETS物理CPU的數(shù)目
NUM_CPU_CORESCPU的核數(shù)
NUM_CPUS邏輯CPU的數(shù)目
SYS_TIME在內(nèi)核態(tài)被消耗掉的CPU時(shí)間片，單位為百分之一秒
USER_TIME在用戶態(tài)被消耗掉的CPU時(shí)間片，單位為百分之一秒
BUSY_TIMEBusy_Time=SYS_TIME+USER_TIME 消耗的CPU時(shí)間片，單位為百分之一秒
AVG_BUSY_TIMEAVG_BUSY_TIME= BUSY_TIME/NUM_CPUS
IDLE_TIME空閑的CPU時(shí)間片，單位為百分之一秒
所有CPU所能提供總的時(shí)間片BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
OS_CPU_WAIT_TIME進(jìn)程等OS調(diào)度的時(shí)間，cpu queuing
VM_IN_BYTES換入頁(yè)的字節(jié)數(shù)
VM_OUT_BYTES換出頁(yè)的字節(jié)數(shù)，部分版本下并不準(zhǔn)確，例如Bug 11712010 Abstract: VIRTUAL MEMORY PAGING ON 11.2.0.2 DATABASES，僅供參考
IOWAIT_TIME所有CPU花費(fèi)在等待I/O完成上的時(shí)間 單位為百分之一秒
RSRC_MGR_CPU_WAIT_TIME是指當(dāng)resource manager控制CPU調(diào)度時(shí)，需要控制對(duì)應(yīng)進(jìn)程暫時(shí)不使用CPU而進(jìn)程到內(nèi)部運(yùn)行隊(duì)列中，以保證該進(jìn)程對(duì)應(yīng)的consumer group(消費(fèi)組)沒(méi)有消耗比指定resource manager指令更多的CPU。RSRC_MGR_CPU_WAIT_TIME指等在內(nèi)部運(yùn)行隊(duì)列上的時(shí)間，在等待時(shí)不消耗CPU
2-6 Service Statistcs
Service Statistics Snaps: 70719-70723-> ordered by DB Time Physical LogicalService Name DB Time (s) DB CPU (s) Reads (K) Reads (K)---------------------------- ------------ ------------ ------------ ------------itms-contentmasterdb-prod 897,099 20,618 35,668 1,958,580SYS$USERS 4,312 189 5,957 13,333itmscmp 1,941 121 14,949 18,187itscmp 331 20 114 218itscmp_dgmgrl 121 1 0 0SYS$BACKGROUND 0 0 142 30,022ITSCMP1_PR 0 0 0 0its-reference-prod 0 0 0 0itscmpXDB 0 0 0 0
按照Service Name來(lái)分組時(shí)間模型和 物理、邏輯讀取， 部分?jǐn)?shù)據(jù)來(lái)源于 WRH$_SERVICE_NAME;
Service Name 對(duì)應(yīng)的服務(wù)名 (v$services)， SYS$BACKGROUND代表后臺(tái)進(jìn)程， SYS$USERS一般是系統(tǒng)用戶登錄
DB TIME (s): 本服務(wù)名所消耗的DB TIME時(shí)間，單位為秒
DB CPU(s): 本服務(wù)名所消耗的DB CPU 時(shí)間，單位為秒
Physical Reads : 本服務(wù)名所消耗的物理讀
Logical Reads : 本服務(wù)所消耗的邏輯讀
2-7 Service Wait Class Stats
Service Wait Class Stats Snaps: 70719-70723-> Wait Class info for services in the Service Statistics section.-> Total Waits and Time Waited displayed for the following wait classes: User I/O, Concurrency, Administrative, Network-> Time Waited (Wt Time) in secondsService Name---------------------------------------------------------------- User I/O User I/O Concurcy Concurcy Admin Admin Network NetworkTotal Wts Wt Time Total Wts Wt Time Total Wts Wt Time Total Wts Wt Time--------- --------- --------- --------- --------- --------- --------- ---------itms-contentmasterdb-prod 33321670 71443 678373 113759 0 0 1.718E+08 127SYS$USERS 173233 3656 6738 30 2 0 72674 3itmscmp 676773 1319 1831 0 0 0 2216 0itscmp 219577 236 1093 0 0 0 18112 0itscmp_dgmgrl 34 0 8 0 0 0 9 0SYS$BACKGROUND 71940 1300 320677 56 0 0 442252 872 -------------------------------------------------------------User I/O Total Wts : 對(duì)應(yīng)該服務(wù)名下 用戶I/O類等待的總的次數(shù)
User I/O Wt Time : 對(duì)應(yīng)該服務(wù)名下 用戶I/O累等待的總時(shí)間，單位為 1/100秒
Concurcy Total Wts: 對(duì)應(yīng)該服務(wù)名下 Concurrency 類型等待的總次數(shù)
Concurcy Wt Time :對(duì)應(yīng)該服務(wù)名下 Concurrency 類型等待的總時(shí)間， 單位為 1/100秒
Admin Total Wts: 對(duì)應(yīng)該服務(wù)名下Admin 類等待的總次數(shù)
Admin Wt Time: 對(duì)應(yīng)該服務(wù)名下Admin類等待的總時(shí)間，單位為 1/100秒
Network Total Wts : 對(duì)應(yīng)服務(wù)名下Network類等待的總次數(shù)
Network Wt Time： 對(duì)應(yīng)服務(wù)名下Network類等待的總事件， 單位為 1/100秒
2-8 Host CPU
Host CPU (CPUs: 24 Cores: 12 Sockets: 2)~~~~~~~~ Load Average Begin End %User %System %WIO %Idle --------- --------- --------- --------- --------- --------- 8.41 12.84 24.7 7.1 0.2 65.8
“Load Average” begin/end值代表每個(gè)CPU的大致運(yùn)行隊(duì)列大小。上例中快照開(kāi)始到結(jié)束，平均 CPU負(fù)載增加了；與《2-5 Operating System Statistics》中的LOAD相呼應(yīng)。
%User+%System=> 總的CPU使用率，在這里是31.8%
Elapsed Time * NUM_CPUS * CPU utilization= 60.23 (mins) * 24 * 31.8% = 459.67536 mins=Busy Time
2-8 Instance CPU
Instance CPU~~~~~~~~~~~~ % of total CPU for Instance: 26.7 % of busy CPU for Instance: 78.2 %DB time waiting for CPU - Resource Mgr: 0.0
%Total CPU,該實(shí)例所使用的CPU占總CPU的比例 % of total CPU for Instance
%Busy CPU，該實(shí)例所使用的Cpu占總的被使用CPU的比例 % of busy CPU for Instance
例如共4個(gè)邏輯CPU，其中3個(gè)被完全使用，3個(gè)中的1個(gè)完全被該實(shí)例使用，則%Total CPU= ? =25%，而%Busy CPU= 1/3= 33%
當(dāng)CPU高時(shí)一般看%Busy CPU可以確定CPU到底是否是本實(shí)例消耗的，還是主機(jī)上其他程序
% of busy CPU for Instance= （DB CPU+ background cpu time) / (BUSY_TIME /100)= (20,649.1 + 1,980.9)/ (2,894,855 /100)= 78.17%
% of Total CPU for Instance = ( DB CPU+ background cpu time)/( BUSY_TIME+IDLE_TIME/100) = (20,649.1 + 1,980.9)/ ((2,894,855+5,568,240) /100) = 26.73%
%DB time waiting for CPU (Resource Manager)= (RSRC_MGR_CPU_WAIT_TIME/100)/DB TIME
3 TOP SQL
TOP SQL 的數(shù)據(jù)部分來(lái)源于 dba_hist_sqlstat
3-1 SQL ordered by Elapsed Time ，按照SQL消耗的時(shí)間來(lái)排列TOP SQL
SQL ordered by Elapsed Time Snaps: 70719-70723-> Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.-> % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100-> %Total - Elapsed Time as a percentage of Total DB time-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Captured SQL account for 53.9% of Total DB Time (s): 883,542-> Captured PL/SQL account for 0.5% of Total DB Time (s): 883,542 Elapsed Elapsed Time Time (s) Executions per Exec (s) %Total %CPU %IO SQL Id---------------- -------------- ------------- ------ ------ ------ ------------- 181,411.3 38,848 4.67 20.5 .0 .1 g0yc9szpuu068
注意對(duì)于PL/SQL，SQL Statistics不僅會(huì)體現(xiàn)該P(yáng)L/SQL的執(zhí)行情況，還會(huì)包括該P(yáng)L/SQL包含的SQL語(yǔ)句的情況。如上例一個(gè)TOP PL/SQL執(zhí)行了448s，而這448s中絕大多數(shù)是這個(gè)PL/SQL下的一個(gè)SQL執(zhí)行500次耗費(fèi)的。
則該TOP PL/SQL和TOP SQL都上榜，一個(gè)執(zhí)行一次耗時(shí)448s，一個(gè)執(zhí)行500次耗時(shí)448s。 如此情況則Elapsed Time加起來(lái)可能超過(guò)100%的Elapsed Time，這是正常的。
對(duì)于鶴立雞群的SQL很有必要一探究竟，跑個(gè)@?/rdbms/admin/awrsqrpt看看吧！
Elapsed Time (s): 該SQL累計(jì)運(yùn)行所消耗的時(shí)間，
Executions : 該SQL在快照時(shí)間內(nèi) 總計(jì)運(yùn)行的次數(shù) ； 注意， 對(duì)于在快照時(shí)間內(nèi)還沒(méi)有執(zhí)行完的SQL 不計(jì)為1一次，所以如果看到executions=0而 又是TOP SQL，則很有可能是因?yàn)樵揝QL 運(yùn)行較舊還沒(méi)執(zhí)行完，需要特別關(guān)注一下。
Elapsed Time per Exec (s)：平均每次執(zhí)行該SQL耗費(fèi)的時(shí)間 ， 對(duì)于OLTP類型的SELECT/INSERT/UPDATE/DELETE而言平均單次執(zhí)行時(shí)間應(yīng)當(dāng)非常短，如0.1秒 或者更短才能滿足其業(yè)務(wù)需求，如果這類輕微的OLTP操作單次也要幾秒鐘的話，是無(wú)法滿足對(duì)外業(yè)務(wù)的需求的； 例如你在ATM上提款，并不僅僅是對(duì)你的賬務(wù)庫(kù)的簡(jiǎn)單UPDATE，而需要在類似風(fēng)險(xiǎn)控制的前置系統(tǒng)中記錄你本次的流水操作記錄，實(shí)際取一次錢可能要有幾十乃至上百個(gè)OLTP類型的語(yǔ)句被執(zhí)行，但它們應(yīng)當(dāng)都是十分快速的操作； 如果這些操作也變得很慢，則會(huì)出現(xiàn)大量事務(wù)阻塞，系統(tǒng)負(fù)載升高，DB TIME急劇上升的現(xiàn)象。 對(duì)于OLTP數(shù)據(jù)庫(kù)而言 如果執(zhí)行計(jì)劃穩(wěn)定，那么這些OLTP操作的性能應(yīng)當(dāng)是鐵板釘釘?shù)?，但是一旦某個(gè)因素 發(fā)生變化，例如存儲(chǔ)的明顯變慢、內(nèi)存換頁(yè)的大量出現(xiàn)時(shí) 則上述的這些transaction操作很可能成數(shù)倍到幾十倍的變慢，這將讓此事務(wù)系統(tǒng)短期內(nèi)不可用。
對(duì)于維護(hù)操作，例如加載或清除數(shù)據(jù)，大的跑批次、報(bào)表而言 Elapsed Time per Exec (s)高一些是正常的。
%Total 該SQL所消耗的時(shí)間占總的DB Time的百分比， 即 (SQL Elapsed Time / Total DB TIME)
% CPU 該SQL 所消耗的CPU 時(shí)間 占 該SQL消耗的時(shí)間里的比例， 即 (SQL CPU Time / SQL Elapsed Time) ，該指標(biāo)說(shuō)明了該語(yǔ)句是否是CPU敏感的
%IO 該SQL 所消耗的I/O 時(shí)間 占 該SQL消耗的時(shí)間里的比例， 即(SQL I/O Time/SQL Elapsed Time) ，該指標(biāo)說(shuō)明了該語(yǔ)句是否是I/O敏感的
SQL Id : 通過(guò)計(jì)算SQL 文本獲得的SQL_ID ，不同的SQL文本必然有不同的SQL_ID， 對(duì)于10g~11g而言 只要SQL文本不變那么在數(shù)據(jù)庫(kù)之間 該SQL 對(duì)應(yīng)的SQL_ID應(yīng)當(dāng)不不變的， 12c中修改了SQL_ID的計(jì)算方法
Captured SQL account for 53.9% of Total DB Time (s) 對(duì)于不綁定變量的應(yīng)用來(lái)說(shuō)Top SQL有可能失準(zhǔn)，所以要參考本項(xiàng)
3-2 SQL ordered by CPU Time
SQL ordered by CPU Time Snaps: 70719-70723-> Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.-> %Total - CPU Time as a percentage of Total DB CPU-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Captured SQL account for 34.9% of Total CPU Time (s): 20,649-> Captured PL/SQL account for 0.5% of Total CPU Time (s): 20,649 CPU CPU per Elapsed Time (s) Executions Exec (s) %Total Time (s) %CPU %IO SQL Id---------- ------------ ---------- ------ ---------- ------ ------ ------------- 1,545.0 1,864,424 0.00 7.5 4,687.8 33.0 65.7 8g6a701j83c8qModule: MZIndexerSELECT t0.BOOLEAN_VALUE, t0.CLASS_CODE, t0.CREATED, t0.END_DATE, t0.PRODUCT_ATTRIBUTE_ID, t0.LAST_MODIFIED, t0.OVERRIDE_FLAG, t0.PRICE, t0.PRODUCT_ATTRIBUTE_TYPE_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 FROM mz_product_attribute t0 WHER
CPU TIME : 該SQL 在快照時(shí)間內(nèi)累計(jì)執(zhí)行所消耗的CPU 時(shí)間片，單位為s
Executions : 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行的次數(shù)
CPU per Exec (s) ：該SQL 平均單次執(zhí)行所消耗的CPU時(shí)間 ， 即 ( SQL CPU TIME / SQL Executions )
%Total : 該SQL 累計(jì)消耗的CPU時(shí)間 占 該時(shí)段總的 DB CPU的比例， 即 ( SQL CPU TIME / Total DB CPU)
% CPU 該SQL 所消耗的CPU 時(shí)間 占 該SQL消耗的時(shí)間里的比例， 即 (SQL CPU Time / SQL Elapsed Time) ，該指標(biāo)說(shuō)明了該語(yǔ)句是否是CPU敏感的
%IO 該SQL 所消耗的I/O 時(shí)間 占 該SQL消耗的時(shí)間里的比例， 即(SQL I/O Time/SQL Elapsed Time) ，該指標(biāo)說(shuō)明了該語(yǔ)句是否是I/O敏感的
3-3 Buffer Gets SQL ordered by Gets
SQL ordered by Gets DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.-> %Total - Buffer Gets as a percentage of Total Buffer Gets-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Total Buffer Gets: 2,021,476,421-> Captured SQL account for 68.2% of Total Buffer Gets Elapsed Gets Executions per Exec %Total Time (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的重要源泉， 但并不是說(shuō)消耗CPU TIME的只有buffer gets。 大多數(shù)情況下 SQL order by CPU TIME 和 SQL order by buffers gets 2個(gè)部分的TOP SQL 及其排列順序都是一樣的，此種情況說(shuō)明消耗最多buffer gets的 就是消耗最多CPU 的SQL ，如果我們希望降低系統(tǒng)的CPU使用率，那么只需要調(diào)優(yōu)SQL 降低buffer gets 即可。
但也并不是100%的情況都是如此， CPU TIME的消耗者 還包括 函數(shù)運(yùn)算、PL/SQL 控制、Latch /Mutex 的Spin等等， 所以SQL order by CPU TIME 和 SQL order by buffers gets 2個(gè)部分的TOP SQL 完全不一樣也是有可能的， 需要因地制宜來(lái)探究到底是什么問(wèn)題導(dǎo)致的High CPU，進(jìn)而裁度解決之道。
Buffer Gets : 該SQL在快照時(shí)間內(nèi)累計(jì)運(yùn)行所消耗的buffer gets，包括了consistent read 和 current read
Executions : 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行的次數(shù)
Gets per Exec : 該SQL平均單次的buffer gets ， 對(duì)于事務(wù)型transaction操作而言 一般該單次buffer gets小于2000
% Total 該SQL 累計(jì)運(yùn)行所消耗的buffer gets占 總的db buffer gets的比率， (SQL buffer gets / DB total buffer gets)
3-4 Physical Reads SQL ordered by Reads
SQL ordered by Reads DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> %Total - Physical Reads as a percentage of Total Disk Reads-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Total Disk Reads: 56,839,035-> Captured SQL account for 34.0% of Total Physical Reads Elapsed Reads Executions per Exec %Total Time (s) %CPU %IO SQL Id----------- ----------- ---------- ------ ---------- ------ ------ ------------- 9,006,163 1 9.0062E+06 15.8 720.9 5.9 80.9 4g36tmp70h185
Physical reads : 該SQL累計(jì)運(yùn)行所消耗的物理讀
Executions : 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行的次數(shù)
Reads per Exec : 該SQL 單次運(yùn)行所消耗的物理讀， (SQL Physical reads/Executions) ， 對(duì)于OLTP transaction 類型的操作而言單次一般不超過(guò)100
%Total : 該SQL 累計(jì)消耗的物理讀 占 該時(shí)段總的 物理讀的比例， 即 ( SQL physical read / Total DB physical read )
3-5 Executions SQL ordered by Executions
SQL ordered by Executions Snaps: 70719-70723-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Total Executions: 48,078,147-> Captured SQL account for 50.4% of Total Elapsed Executions Rows Processed Rows per Exec Time (s) %CPU %IO SQL Id------------ --------------- -------------- ---------- ------ ------ ----------- 6,327,963 11,249,645 1.8 590.5 47.8 52.7 1avv7759j8r
按照 執(zhí)行次數(shù)來(lái)排序的話，也是性能報(bào)告對(duì)比時(shí)一個(gè)重要的參考因素，因?yàn)槿绻鸗OP SQL的執(zhí)行次數(shù)有明顯的增長(zhǎng)，那么 性能問(wèn)題的出現(xiàn)也是意料之中的事情了。 當(dāng)然執(zhí)行次數(shù)最多的，未必便是對(duì)性能影響最大的TOP SQL
Executions : 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行的次數(shù)
Rows Processed： 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行所處理的總行數(shù)
Rows per Exec： SQL平均單次執(zhí)行所處理的行數(shù)， 這個(gè)指標(biāo)在診斷一些 數(shù)據(jù)問(wèn)題造成的SQL性能問(wèn)題時(shí)很有用
3-6 Parse Calls SQL ordered by Parse Calls
SQL ordered by Parse Calls Snaps: 70719-70723-> Total Parse Calls: 2,160,124-> Captured SQL account for 58.3% of Total % Total Parse Calls Executions Parses SQL Id------------ ------------ --------- ------------- 496,475 577,357 22.98 d07gaa3wntdff
Parse Calls : 解析調(diào)用次數(shù)， 與上文的 Load Profile中的Parse 數(shù)一樣 包括 軟解析soft parse和硬解析hard parse
Executions : 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行的次數(shù)
%Total Parses : 本SQL 解析調(diào)用次數(shù) 占 該時(shí)段數(shù)據(jù)庫(kù)總解析次數(shù)的比率， 為 (SQL Parse Calls / Total DB Parse Calls)
3-7 SQL ordered by Sharable Memory
SQL ordered by Sharable Memory Snaps: 70719-70723-> Only Statements with Sharable Memory greater than 1048576 are displayedSharable Mem (b) Executions % Total SQL Id---------------- ------------ -------- ------------- 8,468,359 39 0.08 au89sasqfb2ynModule: MZContentBridgeSELECT t0.ASPECT_RATIO, t0.CREATED, t0.FILE_EXTENSION, t0.HEIGHT, t0.VIDEO_FILE_DIMENSIONS_ID, t0.LAST_MODIFIED, t0.NAME, t0.WIDTH FROM MZ_VIDEO_FILE_DIMENSIONS t0 WHERE (t0.HEIGHT = :1 AND t0.WIDTH = :2 )
SQL ordered by Sharable Memory , 一般該部分僅列出Sharable Mem (b)為1 MB以上的SQL 對(duì)象 (Only Statements with Sharable Memory greater than 1048576 are displayed) 數(shù)據(jù)來(lái)源是 DBA_HIST_SQLSTAT.SHARABLE_MEM
Shareable Mem(b): SQL 對(duì)象所占用的共享內(nèi)存使用量
Executions : 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行的次數(shù)
%Total : 該SQL 對(duì)象鎖占共享內(nèi)存 占總的共享內(nèi)存的比率
3-8 SQL ordered by Version Count
Version Count Oracle中的執(zhí)行計(jì)劃可以是多版本的，即對(duì)于同一個(gè)SQL語(yǔ)句有多個(gè)不同版本的執(zhí)行計(jì)劃，這些執(zhí)行計(jì)劃又稱作子游標(biāo)， 而一個(gè)SQL語(yǔ)句的文本可以稱作一個(gè)父游標(biāo)。 一個(gè)父游標(biāo)對(duì)應(yīng)多個(gè)子游標(biāo)，產(chǎn)生不同子游標(biāo)的原因是 SQL在被執(zhí)行時(shí)無(wú)法共享之前已經(jīng)生成的子游標(biāo)， 原因是多種多樣的，例如 在本session中做了一個(gè)優(yōu)化器參數(shù)的修改 例如optimizer_index_cost_adj 從100 修改到99，則本session的優(yōu)化環(huán)境optimizer env將不同于之前的子游標(biāo)生成環(huán)境，這樣就需要生成一個(gè)新的子游標(biāo)，例如：
SQL> create table emp as select * from scott.emp;Table created.SQL> select * from emp where empno=1;no rows selectedSQL> select /*+ MACLEAN */ * from emp where empno=1;no rows selectedSQL> select SQL_ID,version_count from V$SQLAREA WHERE SQL_TEXT like '%MACLEAN%' and SQL_TEXT not like '%like%';SQL_ID VERSION_COUNT------------- -------------bxnnm7z1qmg26 1SQL> select count(*) from v$SQL where SQL_ID='bxnnm7z1qmg26'; COUNT(*)---------- 1SQL> alter session set optimizer_index_cost_adj=99;Session altered.SQL> select /*+ MACLEAN */ * from emp where empno=1;no rows selectedSQL> select SQL_ID,version_count from V$SQLAREA WHERE SQL_TEXT like '%MACLEAN%' and SQL_TEXT not like '%like%';SQL_ID VERSION_COUNT------------- -------------bxnnm7z1qmg26 2SQL> select count(*) from v$SQL where SQL_ID='bxnnm7z1qmg26'; COUNT(*)---------- 2SQL> select child_number ,OPTIMIZER_ENV_HASH_VALUE,PLAN_HASH_VALUE from v$SQL where SQL_ID='bxnnm7z1qmg26';CHILD_NUMBER OPTIMIZER_ENV_HASH_VALUE PLAN_HASH_VALUE------------ ------------------------ --------------- 0 3704128740 3956160932 1 3636478958 3956160932
可以看到上述 演示中修改optimizer_index_cost_adj=99 導(dǎo)致CBO 優(yōu)化器的優(yōu)化環(huán)境發(fā)生變化， 表現(xiàn)為不同的OPTIMIZER_ENV_HASH_VALUE，之后生成了2個(gè)子游標(biāo)，但是這2個(gè)子游標(biāo)的PLAN_HASH_VALUE同為3956160932，則說(shuō)明了雖然是不同的子游標(biāo)但實(shí)際子游標(biāo)里包含了的執(zhí)行計(jì)劃是一樣的； 所以請(qǐng)注意 任何一個(gè)優(yōu)化環(huán)境的變化 (V$SQL_SHARED_CURSOR)以及相關(guān)衍生的BUG 都可能導(dǎo)致子游標(biāo)無(wú)法共享，雖然子游標(biāo)無(wú)法共享但這些子游標(biāo)扔可能包含完全一樣的執(zhí)行計(jì)劃，這往往是一種浪費(fèi)。
注意V$SQLAREA.VERSION_COUNT 未必等于select count(*) FROM V$SQL WHERE SQL_ID=” ，即 V$SQLAREA.VERSION_COUNT 顯示的子游標(biāo)數(shù)目 未必等于當(dāng)前實(shí)例中還存有的子游標(biāo)數(shù)目， 由于shared pool aged out算法和其他一些可能導(dǎo)致游標(biāo)失效的原因存在，所以子游標(biāo)被清理掉是很常見(jiàn)的事情。 V$SQLAREA.VERSION_COUNT只是一個(gè)計(jì)數(shù)器，它告訴我們?cè)?jīng)生成了多少個(gè)child cursor，但不保證這些child 都還在shared pool里面。
此外可以通過(guò)v$SQL的child_number字段來(lái)分析該問(wèn)題，如果child_number存在跳號(hào)則也說(shuō)明了部分child被清理了。
子游標(biāo)過(guò)多的影響， 當(dāng)子游標(biāo)過(guò)多(例如超過(guò)3000個(gè)時(shí)),進(jìn)程需要去掃描長(zhǎng)長(zhǎng)的子游標(biāo)列表child cursor list以找到一個(gè)合適的子游標(biāo)child cursor，進(jìn)而導(dǎo)致cursor sharing 性能問(wèn)題 現(xiàn)大量的Cursor: Mutex S 和 library cache lock等待事件。
關(guān)于子游標(biāo)的數(shù)量控制，可以參考
《11gR2游標(biāo)共享新特性帶來(lái)的一些問(wèn)題以及_cursor_features_enabled、_cursor_obsolete_threshold和106001 event》。
Executions : 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行的次數(shù)
Hash Value : 共享SQL 的哈希值
Only Statements with Version Count greater than 20 are displayed 注意該環(huán)節(jié)僅列出version count > 20的語(yǔ)句
3-9 Cluster Wait Time SQL ordered by Cluster Wait Time
SQL ordered by Cluster Wait Time DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> %Total - Cluster Time as a percentage of Total Cluster Wait Time-> %Clu - Cluster Time as a percentage of Elapsed Time-> %CPU - CPU Time as a percentage of Elapsed Time-> %IO - User I/O Time as a percentage of Elapsed Time-> Only SQL with Cluster Wait Time > .005 seconds is reported-> Total Cluster Wait Time (s): 525,480-> Captured SQL account for 57.2% of Total Cluster Elapsed Wait Time (s) Executions %Total Time(s) %Clu %CPU %IO SQL Id-------------- ------------ ------ ---------- ------ ------ ------ ------------- 132,639.3 38,848 25.2 181,411.3 73.1 .0 .1 g0yc9szpuu068
Only SQL with Cluster Wait Time > .005 seconds is reported 這個(gè)環(huán)節(jié)僅僅列出Cluster Wait Time > 0.005 s的SQL
該環(huán)節(jié)的數(shù)據(jù)主要來(lái)源 于 DBA_HIST_SQLSTAT.CLWAIT_DELTA Delta value of cluster wait time
Cluster Wait Time : 該SQL語(yǔ)句累計(jì)執(zhí)行過(guò)程中等待在集群等待上的時(shí)間，單位為秒， 你可以理解為 當(dāng)一個(gè)SQL 執(zhí)行過(guò)程中遇到了gc buffer busy、gc cr multi block request 之類的Cluster等待，則這些等待消耗的時(shí)間全部算在 Cluster Wait Time里。
Executions : 該SQL在快照時(shí)間內(nèi)累計(jì)執(zhí)行的次數(shù)
%Total: 該SQL所消耗的Cluster Wait time 占 總的Cluster Wait time的比率， 為(SQL cluster wait time / DB total cluster Wait Time)
%Clu: 該SQL所消耗的Cluster Wait time 占該SQL 總的耗時(shí)的比率，為(SQL cluster wait time / SQL elapsed Time),該指標(biāo)說(shuō)明了該語(yǔ)句是否是集群等待敏感的
% CPU 該SQL 所消耗的CPU 時(shí)間 占 該SQL消耗的時(shí)間里的比例， 即 (SQL CPU Time / SQL Elapsed Time) ，該指標(biāo)說(shuō)明了該語(yǔ)句是否是CPU敏感的
%IO 該SQL 所消耗的I/O 時(shí)間 占 該SQL消耗的時(shí)間里的比例， 即(SQL I/O Time/SQL Elapsed Time) ，該指標(biāo)說(shuō)明了該語(yǔ)句是否是I/O敏感的
4 Instance Activity Stats
Instance Activity Stats DB/Inst: ITSCMP/itscmp2 Snaps: 70719-70723-> Ordered by statistic nameStatistic Total per Second per Trans-------------------------------- ------------------ -------------- -------------Batched IO (bound) vector count 450,449 124.6 1.8Batched IO (full) vector count 5,485 1.5 0.0Batched IO (space) vector count 1,467 0.4 0.0Batched IO block miss count 4,119,070 1,139.7 16.7Batched IO buffer defrag count 39,710 11.0 0.2Batched IO double miss count 297,357 82.3 1.2Batched IO same unit count 1,710,492 473.3 7.0Batched IO single block count 329,521 91.2 1.3Batched IO slow jump count 47,104 13.0 0.2Batched IO vector block count 2,069,852 572.7 8.4Batched IO vector read count 262,161 72.5 1.1Block Cleanout Optim referenced 37,574 10.4 0.2CCursor + sql area evicted 1,457 0.4 0.0...............
Instance Activity Stats 的數(shù)據(jù)來(lái)自于 DBA_HIST_SYSSTAT，DBA_HIST_SYSSTAT來(lái)自于V$SYSSTAT。
這里每一個(gè)指標(biāo)都代表一種數(shù)據(jù)庫(kù)行為的活躍度，例如redo size 是指生成redo的量，sorts (disk) 是指磁盤排序的次數(shù)，table scans (direct read) 是指直接路徑掃描表的次數(shù)。
雖然這些指標(biāo)均只有Total、per Second每秒、 per Trans每事務(wù) 三個(gè)維度，但對(duì)診斷問(wèn)題十分有用。
我們來(lái)舉幾個(gè)例子：
1、 例如當(dāng) Top Event 中存在direct path read為Top 等待事件， 則需要分清楚是對(duì)普通堆表的direct read還是由于大量LOB讀造成的direct path read， 這個(gè)問(wèn)題可以借助 table scans (direct read)、table scans (long tables)、physical reads direct 、physical reads direct (lob) 、physical reads direct temporary幾個(gè)指標(biāo)來(lái)分析， 假設(shè) physical reads direct >> 遠(yuǎn)大于 physical reads direct (lob)+physical reads direct temporary ， 且有較大的table scans (direct read)、table scans (long tables) (注意這2個(gè)指標(biāo)代表的是 掃描表的次數(shù) 不同于上面的phsical reads 的單位為 塊數(shù)*次數(shù))， 則說(shuō)明了是 大表掃描引起的direct path read。
2、 例如當(dāng) Top Event中存在enq Tx:index contention等待事件， 則需要分析root node splits 、branch node splits 、leaf node 90-10 splits 、leaf node splits 、failed probes on index block rec 幾個(gè)指標(biāo)，
具體可以見(jiàn)文檔《Oracle索引塊分裂split信息匯總》3、系統(tǒng)出現(xiàn)IO類型的等待事件為TOp Five 例如 db file sequential/scattered read ，我們需要通過(guò)AWR來(lái)獲得系統(tǒng)IO吞吐量和IOPS:
physical read bytes 主要是應(yīng)用造成的物理讀取(Total size in bytes of all disk reads by application activity (and not other instance activity) only.) 而physical read total bytes則包括了 rman備份恢復(fù) 和后臺(tái)維護(hù)任務(wù)所涉及的物理讀字節(jié)數(shù)，所以我們?cè)谘芯縄O負(fù)載時(shí)一般參考 physical read total bytes；以下4對(duì)指標(biāo)均存在上述的關(guān)系
physical read bytesphysical read total bytes物理讀的吞吐量/秒
physical read IO requestsphysical read total IO requests物理讀的IOPS
physical write bytesphysical write total bytes物理寫的吞吐量/秒
physical write IO requestsphysical write total IO requests物理寫的IOPS
總的物理吞吐量/秒=physical read total bytes+physical write total bytes
總的物理IOPS= physical read total IO requests+ physical write total IO requests
IO的主要指標(biāo) 吞吐量、IOPS和延遲 均可以從AWR中獲得了， IO延遲的信息可以從 User I/O的Wait Class Avg Wait time獲得，也可以參考11g出現(xiàn)的IOStat by Function summary
Instance Activity Stats有大量的指標(biāo)，但是對(duì)于這些指標(biāo)的介紹 沒(méi)有那一份文檔有完整詳盡的描述，即便在Oracle原廠內(nèi)部要沒(méi)有(或者是Maclean沒(méi)找到)，實(shí)際是開(kāi)發(fā)人員要引入某一個(gè)Activity Stats是比較容易的，并不像申請(qǐng)引入一個(gè)新后臺(tái)進(jìn)程那樣麻煩，Oracle對(duì)于新版本中新后臺(tái)進(jìn)程的引入有嚴(yán)格的要求，但Activity Stats卻很容易，往往一個(gè)one-off patch中就可以引入了，實(shí)際上Activity Stats在源代碼層僅僅是一些計(jì)數(shù)器。’
較為基礎(chǔ)的statistics，大家可以參考官方文檔的Statistics Descriptions描述，地址在這里。對(duì)于深入的指標(biāo) 例如 “Batched IO (space) vector count”這種由于某些新特性被引入的，一般沒(méi)有很詳細(xì)的材料，需要到源代碼中去閱讀相關(guān)模塊才能總結(jié)其用途，對(duì)于這個(gè)工作一般原廠是很延遲去完成的，所以沒(méi)有一個(gè)完整的列表。 如果大家有對(duì)此的疑問(wèn)，請(qǐng)去t.askmaclean.com 發(fā)一個(gè)帖子提問(wèn)。
Instance Activity Stats - Absolute Values Snaps: 7071-> Statistics with absolute values (should not be diffed)Statistic Begin Value End Value-------------------------------- --------------- ---------------session pga memory max 1.157882826E+12 1.154290304E+12session cursor cache count 157,042,373 157,083,136session uga memory 5.496429019E+14 5.496775467E+14opened cursors current 268,916 265,694workarea memory allocated 827,704 837,487logons current 2,609 2,613session uga memory max 1.749481584E+13 1.749737418E+13session pga memory 4.150306913E+11 4.150008177E+11
Instance Activity Stats – Absolute Values是顯示快照 起點(diǎn) 和終點(diǎn)的一些指標(biāo)的絕對(duì)值
logon current 當(dāng)前時(shí)間點(diǎn)的登錄數(shù)
opened cursors current 當(dāng)前打開(kāi)的游標(biāo)數(shù)
session cursor cache count 當(dāng)前存在的session緩存游標(biāo)數(shù)
Instance Activity Stats - Thread ActivityDB/Inst: G10R25/G10R25 Snaps: 3663-3-> Statistics identified by '(derived)' come from sources other than SYSSTAT Statistic Total per Hour -------------------------------- ------------------ --------- log switches (derived) 17 2,326.47
log switches (derived) 日志切換次數(shù) ，
見(jiàn) 《理想的在線重做日志切換時(shí)間是多長(zhǎng)？》5 IO 統(tǒng)計(jì)
5-1 Tablespace IO Stats 基于表空間分組的IO信息
reads : 指 該表空間上發(fā)生的物理讀的次數(shù)(單位不是塊，而是次數(shù))
Av Reads/s : 指該表空間上平均每秒的物理讀次數(shù) (單位不是塊，而是次數(shù))
Av Rd(ms): 指該表空間上每次讀的平均讀取延遲
Av Blks/Rd: 指該表空間上平均每次讀取的塊數(shù)目，因?yàn)橐淮挝锢碜x可以讀多個(gè)數(shù)據(jù)塊；如果Av Blks/Rd>>1 則可能系統(tǒng)有較多db file scattered read 可能是診斷FULL TABLE SCAN或FAST FULL INDEX SCAN，需要關(guān)注table scans (long tables) 和index fast full scans (full) 2個(gè)指標(biāo)
Writes : 該表空間上發(fā)生的物理寫的次數(shù) ; 對(duì)于那些Writes總是等于0的表空間 不妨了解下是否數(shù)據(jù)為只讀，如果是可以通過(guò)read only tablespace來(lái)解決 RAC中的一些性能問(wèn)題。
Av Writes/s : 指該表空間上平均每秒的物理寫次數(shù)
buffer Waits: 該表空間上發(fā)生buffer busy waits和read by other session的次數(shù)( 9i中buffer busy waits包含了read by other session)。
Av Buf Wt(ms): 該表空間上發(fā)生buffer Waits的平均等待時(shí)間，單位為ms
5-2 File I/O
Tablespace 表空間名
FileName 數(shù)據(jù)文件的路徑
Reads: 該數(shù)據(jù)文件上累計(jì)發(fā)生過(guò)的物理讀次數(shù)，不是塊數(shù)
Av Reads/s: 該數(shù)據(jù)文件上平均每秒發(fā)生過(guò)的物理讀次數(shù)，不是塊數(shù)
Av Rd(ms): 該數(shù)據(jù)文件上平均每次物理讀取的延遲，單位為ms
Av Blks/Rd: 該數(shù)據(jù)文件上平均每次讀取涉及到的塊數(shù)，OLTP環(huán)境該值接近 1
Writes : 該數(shù)據(jù)文件上累計(jì)發(fā)生過(guò)的物理寫次數(shù)，不是塊數(shù)
Av Writes/s: 該數(shù)據(jù)文件上平均每秒發(fā)生過(guò)的物理寫次數(shù)，不是塊數(shù)
buffer Waits: 該數(shù)據(jù)文件上發(fā)生buffer busy waits和read by other session的次數(shù)( 9i中buffer busy waits包含了read by other session)。
Av Buf Wt(ms): 該數(shù)據(jù)文件上發(fā)生buffer Waits的平均等待時(shí)間，單位為ms
若某個(gè)表空間上有較高的IO負(fù)載，則有必要分析一下 是否其所屬的數(shù)據(jù)文件上的IO 較為均勻 還是存在傾斜， 是否需要結(jié)合存儲(chǔ)特征來(lái) 將數(shù)據(jù)均衡分布到不同磁盤上的數(shù)據(jù)文件上，以優(yōu)化 I/O
6 緩沖池統(tǒng)計(jì) Buffer Pool Statistics
該環(huán)節(jié)的數(shù)據(jù)主要來(lái)源于WRH$_BUFFER_POOL_STATISTICS， 而WRH$_BUFFER_POOL_STATISTICS是定期匯總v$SYSSTAT中的數(shù)據(jù)
P pool池的名字 D: 默認(rèn)的緩沖池 default buffer pool , K : Keep Pool , R: Recycle Pool ; 2k 4k 8k 16k 32k: 代表各種非標(biāo)準(zhǔn)塊大小的緩沖池
Number of buffers: 實(shí)際的 緩沖塊數(shù)目， 約等于 池的大小 / 池的塊大小
Pool Hit % : 該緩沖池的命中率
Buffer Gets: 對(duì)該緩沖池的中塊的訪問(wèn)次數(shù) 包括 consistent gets 和 db block gets
Physical Reads: 該緩沖池Buffer Cache引起了多少物理讀， 其實(shí)是physical reads cache ，單位為 塊數(shù)*次數(shù)
Physical Writes ：該緩沖池中Buffer cache被寫的物理寫， 其實(shí)是physical writes from cache， 單位為 塊數(shù)*次數(shù)
Free Buffer Waits: 等待空閑緩沖的次數(shù)， 可以看做該buffer pool 發(fā)生free buffer waits 等待的次數(shù)
Write Comp Wait: 等待DBWR寫入臟buffer到磁盤的次數(shù)， 可以看做該buffer pool發(fā)生write complete waits等待的次數(shù)
Buffer Busy Waits: 該緩沖池發(fā)生buffer busy wait 等待的次數(shù)
7-1 Checkpoint Activity 檢查點(diǎn)與 Instance Recovery Stats 實(shí)例恢復(fù)
Checkpoint Activity Snaps: 70719-70723-> Total Physical Writes: 590,563 Other Autotune Thread MTTR Log Size Log Ckpt Settings Ckpt Ckpt Writes Writes Writes Writes Writes Writes----------- ----------- ----------- ----------- ----------- ----------- 0 0 0 0 12,899 0 -------------------------------------------------------------Instance Recovery Stats Snaps: 70719-70723-> B: Begin Snapshot, E: End Snapshot 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 3E 0 7 16990 586071 2314207 5096034 2314207 N/A N/A 3 -------------------------------------------------------------
該環(huán)節(jié)的數(shù)據(jù)來(lái)源于WRH$_INSTANCE_RECOVERY
MTTR Writes : 為了滿足FAST_START_MTTR_TARGET 指定的MTTR值 而做出的物理寫 WRITES_MTTR
Log Size Writes ：由于最小的redo log file而做出的物理寫 WRITES_LOGFILE_SIZE
Log Ckpt writes: 由于 LOG_CHECKPOINT_INTERVAL 和 LOG_CHECKPOINT_TIMEOUT 驅(qū)動(dòng)的增量檢查點(diǎn)而做出的物理寫 WRITES_LOG_CHECKPOINT_SETTINGS
Other Settings Writes ：由于其他設(shè)置(例如FAST_START_IO_TARGET）而引起的物理寫， WRITES_OTHER_SETTINGS
Autotune Ckpt Writes : 由于自動(dòng)調(diào)優(yōu)檢查點(diǎn)而引起的物理寫， WRITES_AUTOTUNE
Thread Ckpt Writes ：由于thread checkpoint而引起的物理寫，WRITES_FULL_THREAD_CKPT
B 代表 開(kāi)始點(diǎn)， E 代表結(jié)尾
Targt MTTR (s) : 目標(biāo)MTTR (mean time to recover)意為有效恢復(fù)時(shí)間，單位為秒。 TARGET_MTTR 的計(jì)算基于 給定的參數(shù)FAST_START_MTTR_TARGET，而 TARGET_MTTR作為內(nèi)部使用。 實(shí)際在使用中 Target MTTR未必能和FAST_START_MTTR_TARGET一樣。 如果FAST_START_MTTR_TARGET過(guò)小，那么 TARGET_MTTR 將是系統(tǒng)條件所允許的最小估算值； 如果FAST_START_MTTR_TARGET過(guò)大，則TARGET_MTTR以保守算法計(jì)算以獲得完成恢復(fù)的最長(zhǎng)估算時(shí)間。
estimated_mttr (s): 當(dāng)前基于 臟buffer和重做日志塊的數(shù)量，而評(píng)估出的有效恢復(fù)時(shí)間 。 它的估算告訴用戶 以當(dāng)下系統(tǒng)的負(fù)載若發(fā)生實(shí)例crash，則需要多久時(shí)間來(lái)做crash recovery的前滾操作，之后才能打開(kāi)數(shù)據(jù)庫(kù)。
Recovery Estd IOs ：實(shí)際是當(dāng)前buffer cache中的臟塊數(shù)量，一旦實(shí)例崩潰 這些臟塊要被前滾
Actual RedoBlks ： 當(dāng)前實(shí)際需要恢復(fù)的redo重做塊數(shù)量
Target RedoBlks ：是 Log Sz RedoBlks 、Log Ckpt Timeout RedoBlks、 Log Ckpt Interval RedoBlks 三者的最小值
Log Sz RedoBlks : 代表 必須在log file switch日志切換之前完成的 checkpoint 中涉及到的redo block，也叫max log lag； 數(shù)據(jù)來(lái)源select LOGFILESZ from X$targetrba; select LOG_FILE_SIZE_REDO_BLKS from v$instance_recovery;
Log Ckpt Timeout RedoBlks ： 為了滿足LOG_CHECKPOINT_TIMEOUT 所需要處理的redo block數(shù)，lag for checkpoint timeout ； 數(shù)據(jù)來(lái)源select CT_LAG from x$targetrba;
Log Ckpt Interval RedoBlks ：為了滿足LOG_CHECKPOINT_INTERVAL 所需要處理的redo block數(shù)， lag for checkpoint interval； 數(shù)據(jù)來(lái)源select CI_LAG from x$targetrba;
Opt Log Sz(M) : 基于FAST_START_MTTR_TARGET 而估算出來(lái)的redo logfile 的大小，單位為MB 。 Oracle官方推薦創(chuàng)建的重做日志大小至少大于這個(gè)估算值
Estd RAC Avail Time ：指評(píng)估的 RAC中節(jié)點(diǎn)失敗后 集群從凍結(jié)到部分可用的時(shí)間， 這個(gè)指標(biāo)僅在RAC中可用，單位為秒。 ESTD_CLUSTER_AVAILABLE_TIME
7-2 Buffer Pool Advisory 緩沖池建議
緩沖池的顆粒大小 可以參考 SELECT * FROM V$SGAINFO where name like(‘Granule%’);
P 指 緩沖池的名字 可能包括 有 D default buffer pool , K Keep Pool , R recycle Pool
Size For Est(M): 指以該尺寸的buffer pool作為評(píng)估的對(duì)象，一般是 目前current size的 10% ~ 200%，以便了解 buffer pool 增大 ~減小 對(duì)物理讀的影響
Size Factor : 尺寸因子， 只 對(duì)應(yīng)buffer pool 大小 對(duì) 當(dāng)前設(shè)置的比例因子， 例如current_size是 100M ， 則如果評(píng)估值是110M 那么 size Factor 就是 1.1
Buffers (thousands) ：指這個(gè)buffer pool 尺寸下的buffer 數(shù)量， 要乘以1000才是實(shí)際值
Est Phys Read Factor ：評(píng)估的物理讀因子， 例如當(dāng)前尺寸的buffer pool 會(huì)引起100個(gè)物理讀， 則別的尺寸的buffer pool如果引起 120個(gè)物理讀， 那么 對(duì)應(yīng)尺寸的Est Phys Read Factor就是1.2
Estimated Phys Reads (thousands)：評(píng)估的物理讀數(shù)目， 要乘以 1000才是實(shí)際值， 顯然不同尺寸的buffer pool對(duì)應(yīng)不同的評(píng)估的物理讀數(shù)目
Est Phys Read Time ： 評(píng)估的物理讀時(shí)間
Est %DBtime for Rds：評(píng)估的物理讀占DB TIME的比率
我們 看buffer pool advisory 一般有2個(gè)目的：
在物理讀較多的情況下，希望通過(guò)增加buffer pool 大小來(lái)緩解物理讀等待，這是我們關(guān)注Size Factor > 1的buffer pool尺寸是否能共有效減少Est Phys Read Factor， 如果Est Phys Read Factor隨著Size Factor 增大 而顯著減少，那么說(shuō)明增大buffer cache 是可以有效減少物理讀的。
在內(nèi)存緊張的情況下 ，希望從buffer pool中勻出部分內(nèi)存來(lái)移作他用， 但是又不希望 buffer cache變小導(dǎo)致 物理讀增多 性能下降， 則此時(shí) 觀察Est Phys Read Factor 是否隨著Size Factor 減小而 顯著增大， 如果不是 則說(shuō)明減少部分buffer cache 不會(huì)導(dǎo)致 物理讀大幅增加，也就可以安心 減少 buffer cache
注意 Size Factor 和 Est Phys Read Factor之間不是簡(jiǎn)單的 線性關(guān)系，所以需要人為介入評(píng)估得失
7-3 PGA Aggr Summary
PGA Cache Hit % : 指 W/A WorkArea工作區(qū)的數(shù)據(jù)僅在內(nèi)存中處理的比率， PGA緩存命中率
workarea是PGA中負(fù)責(zé)處理 排序、哈希連接和位圖合并操作的區(qū)域; workarea 也叫做 SQL 作業(yè)區(qū)域
W/A MB processes: 指 在Workarea中處理過(guò)的數(shù)據(jù)的量，單位為MB
Extra W/A MB Read/Written : 指額外從磁盤上 讀寫的 工作區(qū)數(shù)據(jù)， 單位為 MB
7-4 PGA Aggr Target Stats
此環(huán)節(jié)的數(shù)據(jù)來(lái)源主要是 WRH$_PGASTAT
PGA Aggr Target(M) ：本質(zhì)上就是pga_aggregate_target ， 當(dāng)然在AMM(memory_target)環(huán)境下 這個(gè)值可能會(huì)自動(dòng)變化
Auto PGA Target(M) : 在自動(dòng)PGA 管理模式下 實(shí)際可用的工作區(qū)內(nèi)存 “aggregate PGA auto target “， 因?yàn)镻GA還有其他用途 ，不能全部作為workarea memory
PGA Mem Alloc(M) ：目前已分配的PGA內(nèi)存， alloc 不等于 inuse 即分配的內(nèi)存不等于在使用的內(nèi)存，理論上PGA會(huì)將確實(shí)不使用的內(nèi)存返回給OS(PGA memory freed back to OS) ，但是存在PGA占用大量?jī)?nèi)存而不釋放的場(chǎng)景
在上例中 pga_aggregate_target 僅為8192M ，而實(shí)際processes 在 2,615~ 8000之間，如果一個(gè)進(jìn)程耗費(fèi)5MB的PGA 也需要 10000M的PGA ，而實(shí)際這里 PGA Mem Alloc(M)是23,690 M ，這說(shuō)明 存在PGA 的過(guò)載， 需要調(diào)整pga_aggregate_target
W/A PGA Used(M) ：所有的工作區(qū)workarea(包括manual和 auto)使用的內(nèi)存總和量， 單位為MB
%PGA W/A Mem: 分配給workarea的內(nèi)存量占總的PGA的比例， (W/A PGA Used)/PGA Mem Alloc
%Auto W/A Mem : AUTO 自動(dòng)工作區(qū)管理所控制的內(nèi)存(workarea_size_policy=AUTO) 占總的workarea內(nèi)存的比例
%Man W/A Mem : MANUAL 手動(dòng)工作區(qū)管理所控制的內(nèi)存(workarea_size_policy=MANUAL)占總的workarea內(nèi)存的比例
Global Mem Bound(K) : 指 在自動(dòng)PGA管理模式下一個(gè)工作區(qū)所能分配的最大內(nèi)存(注意 一個(gè)SQL執(zhí)行過(guò)程中可能有多個(gè)工作區(qū)workarea)。 Global Mem Bound(K)這個(gè)指標(biāo)在實(shí)例運(yùn)行過(guò)程中將被持續(xù)性的修正，以反應(yīng)數(shù)據(jù)庫(kù)當(dāng)時(shí)工作區(qū)的負(fù)載情況。顯然在有眾多活躍工作區(qū)的系統(tǒng)負(fù)載下相應(yīng)地Global Mem Bound將會(huì)下降。 但應(yīng)當(dāng)保持global bound值不要小于1 MB ， 否則建議 調(diào)高pga_aggregate_target
7-5 PGA Aggr Target Histogram
數(shù)據(jù)來(lái)源：WRH$_SQL_WORKAREA_HISTOGRAM
Low Optimal： 此行所包含工作區(qū)workarea最適合內(nèi)存要求的下限
High Optimal： 此行所包含工作區(qū)workarea最適合內(nèi)存要求的上限
Total Execs: 在 Low Optimal~High Optimal 范圍工作區(qū)內(nèi)完成的總執(zhí)行數(shù)
Optimal execs: optimal 執(zhí)行是指完全在PGA內(nèi)存中完成的執(zhí)行次數(shù)
1-pass Execs : 指操作過(guò)程中僅發(fā)生1次磁盤讀取的執(zhí)行次數(shù)
M-pass Execs: 指操作過(guò)程中發(fā)生了1次以上的磁盤讀取， 頻發(fā)磁盤讀取的執(zhí)行次數(shù)
7-6 PGA Memory Advisory
PGA Target Est (MB) 用以評(píng)估的 PGA_AGGREGATE _TARGET值
Size Factr ， 當(dāng)前用以評(píng)估的PGA_AGGREGATE _TARGET 和 當(dāng)前實(shí)際設(shè)置的PGA_AGGREGATE _TARGET 之間的 比例因子 PGA Target Est / PGA_AGGREGATE_TARGE
W/A MB Processed ：workarea中要處理的數(shù)據(jù)量， 單位為MB
Estd Extra W/A MB Read/ Written to Disk : 以 one-pass 、M-Pass方式處理的數(shù)據(jù)量預(yù)估值， 單位為MB
Estd P Cache Hit % : 預(yù)估的PGA緩存命中率
Estd PGA Overalloc Count: 預(yù)估的PGA過(guò)載量， 如上文所述PGA_AGGREGATE _TARGET僅是一個(gè)目標(biāo)值，無(wú)法真正限制PGA內(nèi)存的使用，當(dāng)出現(xiàn) PGA內(nèi)存硬性需求時(shí)會(huì)產(chǎn)生PGA overallocate 過(guò)載(When using Auto Memory Mgmt, minimally choose a pga_aggregate_target value where Estd PGA Overalloc Count is 0)
7-7 Shared Pool Advisory
Shared Pool Size(M) : 用以評(píng)估的shared pool共享池大小，在AMM /ASMM環(huán)境下 shared_pool 大小都可能浮動(dòng)
SP Size Factr ：共享池大小的比例因子， （Shared Pool Size for Estim / SHARED_POOL_SIZE）
Estd LC Size(M) : 評(píng)估的 library cache 大小 ，單位為MB ， 因?yàn)槭莝hared pool中包含 library cache 當(dāng)然還有其他例如row cache
Est LC Mem Obj 指評(píng)估的指定大小的共享池內(nèi)的library cache memory object的數(shù)量 ESTD_LC_MEMORY_OBJECTS
Est LC Time Saved(s): 指在 指定的共享池大小情況下可找到需要的library cache memory objects，從而節(jié)約的解析時(shí)間 。 這些節(jié)約的解析時(shí)間也是 花費(fèi)在共享池內(nèi)重復(fù)加載需要的對(duì)象(reload)，這些對(duì)象可能因?yàn)楣蚕沓貨](méi)有足夠的free memory而被aged out. ESTD_LC_TIME_SAVED
Est LC Time Saved Factr : Est LC Time Saved(s)的比例因子，( Est LC Time Saved(s)/ Current LC Time Saved(s) ) ESTD_LC_TIME_SAVED_FACTOR
Est LC Load Time (s): 在指定的共享池大小情況下解析的耗時(shí)
Est LC Load Time Factr：Est LC Load Time (s)的比例因子， (Est LC Load Time (s)/ Current LC Load Time (s)) ESTD_LC_LOAD_TIME_FACTOR
Est LC Mem Obj Hits (K) : 在指定的共享池大小情況下需要的library cache memory object正好在共享池中被找到的次數(shù) ESTD_LC_MEMORY_OBJECT_HITS；
對(duì)于想縮小 shared_pool_size 共享池大小的需求，可以關(guān)注Est LC Mem Obj Hits (K) ，如上例中共享池為352M時(shí)Est LC Mem Obj Hits (K) 就為334且之后不動(dòng)，則可以考慮縮小shared_pool_size到該值，但要注意每個(gè)版本/平臺(tái)上對(duì)共享池的最低需求，包括RAC中g(shù)cs resource 、gcs shadow等資源均駐留在shared pool中，增大db_cache_size時(shí)要對(duì)應(yīng)關(guān)注。
7-8 SGA Target Advisory
該環(huán)節(jié)數(shù)據(jù)來(lái)源于WRH$_SGA_TARGET_ADVICE
SGA target Size : 用以評(píng)估的sga target大小 (sga_target)
SGA Size Factor: SGA Size的比例因子， (est SGA target Size / Current SGA target Size )
Est DB Time (s): 評(píng)估對(duì)應(yīng)于該指定sga target size會(huì)產(chǎn)生多少量的DB TIME，單位為秒
Est Physical Reads：評(píng)估對(duì)應(yīng)該指定的sga target size 會(huì)產(chǎn)生多少的物理讀
7-9 Streams Pool Advisory
Streams Pool Advisory DB/Inst: ITSCMP/itscmp2 Snap: 70723 Size for Size Est Spill Est Spill Est Unspill Est Unspill Est (MB) Factor Count Time (s) Count Time (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
該環(huán)節(jié)只有當(dāng)使用了Streams 流復(fù)制時(shí)才會(huì)有必要數(shù)據(jù)， 數(shù)據(jù)來(lái)源 WRH$_STREAMS_POOL_ADVICE
Size for Est (MB) : 用以評(píng)估的 streams pool大小
Size Factor ：streams pool大小的比例因子
Est Spill Count ：評(píng)估出的 當(dāng)使用該大小的流池時(shí) message溢出到磁盤的數(shù)量 ESTD_SPILL_COUNT
Est Spill Time (s)： 評(píng)估出的 當(dāng)使用該大小的流池時(shí) message溢出到磁盤的耗時(shí)，單位為秒 ESTD_SPILL_TIME
Est Unspill Count：評(píng)估的 當(dāng)使用該大小的流池時(shí) message unspill 即從磁盤上讀取的數(shù)量 ESTD_UNSPILL_COUNT
Est Unspill Time (s) ： 評(píng)估的 當(dāng)使用該大小的流池時(shí) message unspill 即從磁盤上讀取的耗時(shí)，單位為秒 ESTD_UNSPILL_TIME
7-10 Java Pool Advisory
java pool的相關(guān)指標(biāo)與shared pool相似，不再鏖述
8 Wait Statistics
8-1 Buffer Wait Statistics
數(shù)據(jù)來(lái)源 ： WRH$_WAITSTAT
該環(huán)節(jié)是對(duì) 緩沖池中各類型(class) 塊 等待的匯總信息， wait的原因一般是 buffer busy waits 和 read by other session
class 數(shù)據(jù)塊的class， 一個(gè)oracle數(shù)據(jù)塊即有class 屬性 還有type 屬性，數(shù)據(jù)塊中記錄type屬性(KCBH)， 而在buffer header里存有class屬性(X$BH.class)
Waits: 該類型數(shù)據(jù)塊的等待次數(shù)
Total Wait Time (s) : 該類型數(shù)據(jù)塊的合計(jì)等待時(shí)間 單位為秒
Avg Time (ms) : 該類型數(shù)據(jù)塊 平均每次等待的耗時(shí)， 單位 ms
如果用戶正使用 undo_management=AUTO 的SMU 則一般不會(huì)因?yàn)閞ollback segment過(guò)少而引起undo header block類塊的等待
對(duì)于INSERT 而引起的 buffer爭(zhēng)用等待：
1、 對(duì)于手動(dòng)segment 管理MSSM 考慮增加Freelists、Freelist Groups
2、 使用ASSM ，當(dāng)然ASSM本身沒(méi)什么參數(shù)可調(diào)
對(duì)于INSERT ON INDEX 引起的爭(zhēng)用：
使用反向索引key
使用HASH分區(qū)和本地索引
可能的情況下 減少index的density
8-2 Enqueue Activity
Enqueue Type (Request Reason) enqueue 隊(duì)列的類型，大家在研究 enqueue 問(wèn)題前 至少搞清楚enqueue type 和enqueue mode ， enqueue type是隊(duì)列鎖所要保護(hù)的資源 如 TM 表鎖 CF 控制文件鎖， enqueue mode 是持有隊(duì)列鎖的模式 (SS、SX 、S、SSX、X)
Requests : 申請(qǐng)對(duì)應(yīng)的enqueue type資源或者隊(duì)列轉(zhuǎn)換(enqueue conversion 例如 S 轉(zhuǎn) SSX ) 的次數(shù)
Succ Gets ：對(duì)應(yīng)的enqueue被成功 申請(qǐng)或轉(zhuǎn)換的次數(shù)
Failed Gets ：對(duì)應(yīng)的enqueue的申請(qǐng) 或者轉(zhuǎn)換失敗的次數(shù)
Waits?。河蓪?duì)應(yīng)的enqueue的申請(qǐng)或者轉(zhuǎn)換而造成等待的次數(shù)
Wt Time (s) ： 由對(duì)應(yīng)的enqueue的申請(qǐng)或者轉(zhuǎn)換而造成等待的等待時(shí)間
Av Wt Time(ms) ：由對(duì)應(yīng)的enqueue的申請(qǐng)或者轉(zhuǎn)換而造成等待的平均等待時(shí)間 ， Wt Time (s) / Waits ,單位為ms
主要的enqueue 等待事件：
enq: TX – row lock/index contention、allocate ITL等待事件enq: TM – contention等待事件Oracle隊(duì)列鎖enq:TS,Temporary Segment (also TableSpace)9-1 Undo Segment Summary
Undo Segment Summary Snaps: 70719-70723-> Min/Max TR (mins) - Min and Max Tuned Retention (minutes)-> STO - Snapshot Too Old count, OOS - Out of Space count-> Undo segment block stats:-> uS - unexpired Stolen, uR - unexpired Released, uU - unexpired reUsed-> eS - expired Stolen, eR - expired Released, eU - expired reUsedUndo Num Undo Number of Max Qry Max Tx Min/Max STO/ 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, ordered by Time desc Num Undo Number of Max Qry Max Tx Tun Ret STO/ uS/uR/uU/End Time Blocks 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/029-Aug 05:42 12,203 24,677 54,844 284 1,065 0/0 0/0/0/0/0/029-Aug 05:32 14,132 37,826 54,241 237 1,060 0/0 0/0/0/0/0/029-Aug 05:22 14,379 32,315 53,637 317 1,050 0/0 0/0/0/0/0/029-Aug 05:12 15,693 34,157 53,033 299 1,045 0/0 0/0/0/0/0/029-Aug 05:02 16,878 36,054 52,428 250 1,040 0/0 0/0/0/0/0/0
數(shù)據(jù)來(lái)源： WRH$_UNDOSTAT ， undo相關(guān)的使用信息每10分鐘刷新到v$undostat中
Undo Extent有三種狀態(tài) active 、unexpired 、expired
active => extent中 包括了活動(dòng)的事務(wù) ，active的undo extent 一般不允許被其他事務(wù)重用覆蓋
unexpired => extent中沒(méi)有活動(dòng)的事務(wù)，但相關(guān)undo 記錄從inactive到目前還未經(jīng)過(guò)undo retention(注意 auto undo retention的問(wèn)題 因?yàn)檫@個(gè)特性 可能在觀察dba_undo_extents時(shí)看到大部分block都是unexpired，這是正常的) 指定的時(shí)間，所以為unexpired。 對(duì)于沒(méi)有g(shù)uarantee retention的undo tablespace而言，unexpired extent可能被 steal 為其他事物重用
expired => extent中沒(méi)有活動(dòng)事務(wù)，且超過(guò)了undo retention的時(shí)間
Undo TS# 在使用的這個(gè)undo 表空間的表空間號(hào)， 一個(gè)實(shí)例 同一時(shí)間只能用1個(gè)undo tablespace ， RAC不同節(jié)點(diǎn)可以用不同的undo tablespace
Num Undo Blocks (K) 指被消費(fèi)的 undo 數(shù)據(jù)塊的數(shù)量, (K)代表要乘以1000才是實(shí)際值； 可以用該指標(biāo)來(lái)評(píng)估系統(tǒng)對(duì)undo block的消費(fèi)量， 以便基于實(shí)際負(fù)載情況來(lái)評(píng)估UNDO表空間的大小
Number of Transactions 指該段時(shí)間內(nèi)該undo表空間上執(zhí)行過(guò)的事務(wù)transaction總量
Max Qry Len (s) 該時(shí)段內(nèi) 持續(xù)最久的查詢 時(shí)間， 單位為秒
Max Tx Concy 該時(shí)段內(nèi) 最大的事務(wù)并發(fā)量
Min/Max TR (mins) 最小和最大的tuned undo retention ，單位為分鐘；
tuned undo retention 是自動(dòng)undo調(diào)優(yōu)特性，見(jiàn)undo自動(dòng)調(diào)優(yōu)介紹。STO/ OOS STO 指 ORA-01555 Snapshot Too Old錯(cuò)誤出現(xiàn)的次數(shù)； OOS – 指Out of Space count 錯(cuò)誤出現(xiàn)的次數(shù)
uS – unexpired Stolen 嘗試從未過(guò)期的undo extent中偷取undo space的次數(shù)
uR – unexpired Released 從未過(guò)期的undo extent中釋放的塊數(shù)目
uU – unexpired reUsed 未過(guò)期的undo extent中的block被其他事務(wù)重用的 塊數(shù)目
eS – expired Stolen 嘗試從過(guò)期的undo extent中偷取undo space的次數(shù)
eR – expired Released 從過(guò)期的undo extent中釋放的塊數(shù)目
eU – expired reUsed 過(guò)期的undo extent中的block被其他事務(wù)重用的 塊數(shù)目
UNXPSTEALCNTNUMBERNumber of attempts to obtain undo space by stealing unexpired extents from other transactions
UNXPBLKRELCNTNUMBERNumber of unexpired blocks removed from certain undo segments so they can be used by other transactions
UNXPBLKREUCNTNUMBERNumber of unexpired undo blocks reused by transactions
EXPSTEALCNTNUMBERNumber of attempts to steal expired undo blocks from other undo segments
EXPBLKRELCNTNUMBERNumber of expired undo blocks stolen from other undo segments
EXPBLKREUCNTNUMBERNumber of expired undo blocks reused within the same undo segments
SSOLDERRCNTNUMBERIdentifies the number of times the error ORA-01555 occurred. You can use this statistic to decide whether or not the UNDO_RETENTION initialization parameter is set properly given the size of the undo tablespace. Increasing the value of UNDO_RETENTION can reduce the occurrence of this error.
10-1 Latch Activity
Latch Activity Snaps: 70719-70723-> "Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for willing-to-wait latch get requests-> "NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests-> "Pct Misses" for both should be very close to 0.0 Pct Avg Wait Pct Get Get Slps Time NoWait NoWaitLatch Name Requests Miss /Miss (s) Requests Miss------------------------ -------------- ------ ------ ------ ------------ ------AQ deq hash table latch 4 0.0 0 0 N/AASM Keyed state latch 9,048 0.1 0.2 0 0 N/AASM allocation 15,017 0.2 0.8 1 0 N/AASM db client latch 72,745 0.0 0 0 N/AASM map headers 5,860 0.6 0.6 1 0 N/AASM map load waiting lis 1,462 0.0 0 0 N/AASM map operation freeli 63,539 0.1 0.4 1 0 N/AASM map operation hash t 76,484,447 0.1 1.0 66 0 N/A
latch name Latch閂的名字
Get Requests latch被以willing-to-wait模式申請(qǐng)并獲得的次數(shù)
Pct Get Miss miss是指latch被以willing-to-wait 模式申請(qǐng)但是申請(qǐng)者必須等待的次數(shù)， Pct Get Miss = Miss/Get Requests ; miss可以從后面的Latch Sleep Breakdown 獲得
Avg Slps /Miss Sleep 是指latch被以willing-to-wait模式申請(qǐng)最終導(dǎo)致session需要sleep以等待該latch的次數(shù) ； Avg Slps /Miss = Sleeps/ Misses ; Sleeps可以從后面的Latch Sleep Breakdown 獲得
Wait Time (s) 指花費(fèi)在等待latch上的時(shí)間，單位為秒
NoWait Requests 指latch被以no-wait模式來(lái)申請(qǐng)的次數(shù)
Pct NoWait Miss 以no-wait模式來(lái)申請(qǐng)latch但直接失敗的次數(shù)
對(duì)于高并發(fā)的latch例如cache buffers chains，其Pct Misses應(yīng)當(dāng)十分接近于0
一般的調(diào)優(yōu)原則：
如果latch : cache buffers chains是 Top 5 事件，則需要考慮優(yōu)化SQL減少 全表掃描 并減少Top buffer gets SQL語(yǔ)句的邏輯讀
如果latch : redo copy 、redo allocation 等待較多，則可以考慮增大LOG_BUFFER
如果latch:library cache 發(fā)生較多，則考慮增大shared_pool_size
10-2 Latch Sleep Breakdown
latch name Latch閂的名字
Get Requests latch被以willing-to-wait模式申請(qǐng)并獲得的次數(shù)
misses 是指latch被以willing-to-wait 模式申請(qǐng)但是申請(qǐng)者必須等待的次數(shù)
9i以后miss之后一般有2種情況 spin gets了 或者sleep一睡不醒直到 被post，
具體見(jiàn)全面解析9i以后Oracle Latch閂鎖原理；8i以前的latch算法可以參考：Oracle Latch:一段描繪Latch運(yùn)作的偽代碼所以一般來(lái)說(shuō)9i以后的 misses= Sleeps+ Spin Gets ，雖然不是絕對(duì)如此
Sleeps 是指latch被以willing-to-wait模式申請(qǐng)最終導(dǎo)致session需要sleep以等待該latch的次數(shù)
Spin Gets 以willing-to-wait模式去申請(qǐng)latch，在miss之后以spin方式獲得了latch的次數(shù)
10-3 Latch Miss Sources
數(shù)據(jù)來(lái)源為DBA_HIST_LATCH_MISSES_SUMMARY
latch name Latch閂的名字
where : 指哪些代碼路徑內(nèi)核函數(shù)持有過(guò)這些該latch ，而不是哪些代碼路徑要申請(qǐng)這些latch； 例如kcbgtcr函數(shù)的作用是Get a block for Consistent read，其持有l(wèi)atch :cache buffers chain是很正常的事情
NoWait Misses: 以no-wait模式來(lái)申請(qǐng)latch但直接失敗的次數(shù)
Sleeps: 指latch被以willing-to-wait模式申請(qǐng)最終導(dǎo)致session需要sleep以等待該latch的次數(shù) time of sleeps resulted in making the latch request
Waiter Sleeps：等待者休眠的次數(shù) times of sleeps that waiters did for each where; Sleep 是阻塞者等待的次數(shù) ， Waiter Sleeps是被阻塞者等待的次數(shù)
10-4 Mutex Sleep Summary
Mutex是10.2.0.2以后引入的新的內(nèi)存鎖機(jī)制，具體對(duì)Mutex的描述見(jiàn) 《深入理解Oracle中的Mutex》：
http://www.askmaclean.com/archives/understanding-oracle-mutex.htmlMutex Type
Mutex的類型其實(shí)就是 mutex對(duì)應(yīng)的客戶的名字， 在版本10.2中基本只有KKS使用Mutex，所以僅有3種:
Cursor Stat (kgx_kks1)
Cursor Parent (kgx_kks2)
Cursor Pin (kgx_kks3)
11g中增加了Library Cache
Location 發(fā)起對(duì)該Mutex申請(qǐng)的代碼路徑code location，而不是還持有該Mutex的代碼路徑或曰內(nèi)核函數(shù)
10.2中最常見(jiàn)的下面的幾個(gè)函數(shù)
kkspsc0 -負(fù)責(zé)解析游標(biāo) – 檢測(cè)我們正在解析的游標(biāo)是否有對(duì)象的parent cursor heap 0存在
kksfbc – 負(fù)責(zé)找到合適的子游標(biāo) 或者創(chuàng)建一個(gè)新的子游標(biāo)
kksFindCursorstat
Sleeps:
Mutex的Get和Sleep
當(dāng)一個(gè)Mutex被申請(qǐng)時(shí)， 一般稱為一個(gè)get request。 若初始的申請(qǐng)未能得到授權(quán)， 則該進(jìn)程會(huì)因?yàn)榇舜紊暾?qǐng)而進(jìn)入到255次SPIN中(_mutex_spin_count Mutex spin count)，每次SPIN循環(huán)迭代過(guò)程中該進(jìn)程都會(huì)去看看Mutex被釋放了嗎。
若該Mutex在SPIN之后仍未被釋放，則該進(jìn)程針對(duì)申請(qǐng)的mutex進(jìn)入對(duì)應(yīng)的mutex wait等待事件中。 實(shí)際進(jìn)程的等待事件和等待方式由mutex的類型鎖決定，例如 Cursor pin、Cursor Parent。 舉例來(lái)說(shuō)，這種等待可能是阻塞等待，也可以是sleep。
但是請(qǐng)注意在V$MUTEX_SLEEP_*視圖上的sleep列意味著等待的次數(shù)。相關(guān)代碼函數(shù)在開(kāi)始進(jìn)入等待時(shí)自加這個(gè)sleep字段。
等待計(jì)時(shí)從進(jìn)程進(jìn)入等待前開(kāi)始計(jì)算等待時(shí)間， 當(dāng)一個(gè)進(jìn)程結(jié)束其等待，則等待的時(shí)間加入都總和total中。 該進(jìn)程再次嘗試申請(qǐng)之前的Mutex，若該Mutex仍不可用，則它再次進(jìn)入spin/wait的循環(huán)。
V$MUTEX_SLEEP_HISTORY視圖的GETS列僅在成功申請(qǐng)到一個(gè)Mutex時(shí)才增加。
Wait Time (ms) 類似于latch，spin time 不算做mutex的消耗時(shí)間，它只包含等待消耗的時(shí)間。
11 segment statistics 段級(jí)統(tǒng)計(jì)
11-1 Segments by Logical Reads
owner : 數(shù)據(jù)段的所有者
Tablespace Name: 數(shù)據(jù)段所在表空間名
Object Name : 對(duì)象名
Subobject Name：子對(duì)象名，例如一個(gè)分區(qū)表的某個(gè)分區(qū)
obj Type: 對(duì)象類型 一般為TABLE /INDEX 或者分區(qū)或子分區(qū)
Logical Reads ：該數(shù)據(jù)段上發(fā)生過(guò)的邏輯讀 ， 單位為 塊數(shù)*次數(shù)
%Total : 占總的邏輯讀的百分比 ， (當(dāng)前對(duì)象上發(fā)生過(guò)的邏輯讀/ Total DB 邏輯讀)
11-2 Segments by Physical Reads
Physical Reads: 該數(shù)據(jù)段上發(fā)生過(guò)的物理讀 ， 單位為 塊數(shù)*次數(shù)
%Total : 占總的物理讀的百分比 ， (當(dāng)前對(duì)象上發(fā)生過(guò)的邏輯讀/ Total DB 邏輯讀)
11-3 Segments by Physical Read Requests
Phys Read Requests ： 物理讀的申請(qǐng)次數(shù)
%Total ： (該段上發(fā)生的物理讀的申請(qǐng)次數(shù)/ physical read IO requests)
11-4 Segments by UnOptimized Reads
UnOptimized Reads UnOptimized Read Reqs = Physical Read Reqts – Optimized Read Reqs
Optimized Read Requests是指 哪些滿足Exadata Smart Flash Cache ( or the Smart Flash Cache in OracleExadata V2 (Note that despite same name, concept and use of
‘Smart Flash Cache’ in Exadata V2 is different from ‘Smart Flash Cache’ in Database Smart Flash Cache)).的物理讀 次數(shù) 。 滿足從smart flash cache走的讀取申請(qǐng)唄認(rèn)為是optimized ，因?yàn)檫@些讀取要比普通從磁盤走快得多。
此外通過(guò)smart scan 讀取storage index的情況也被認(rèn)為是’optimized read requests’ ，源于可以避免讀取不相關(guān)的數(shù)據(jù)。
當(dāng)用戶不在使用Exadata時(shí)，則UnOptimized Read Reqs總是等于 Physical Read Reqts
%Total : (該段上發(fā)生的物理讀的UnOptimized Read Reqs / ( physical read IO requests – physical read requests optimized ))
11-5 Segments by Optimized Reads
Segments by Optimized Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723-> Total Optimized Read Requests: 33,124,894-> Captured Segments account for 45.2% of Total Tablespace Subobject Obj. OptimizedOwner Name Object Name Name Type Reads %Total---------- ---------- -------------------- ---------- ----- ------------ -------CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 2,995,766 9.04CONTENT_OW DATA_TS MZ_PRODUCT_ATTRIBUTE TABLE 1,489,000 4.50CONTENT_OW DATA_TS MZ_PRODUCT TABLE 1,276,350 3.85CONTENT_OW DATA_TS MZ_AUDIO_FILE TABLE 890,775 2.69CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 816,067 2.46
關(guān)于optimizerd read 上面已經(jīng)解釋過(guò)了，這里的單位是 request 次數(shù)
%Total : (該段上發(fā)生的物理讀的 Optimized Read Reqs/ physical read requests optimized )
11-6 Segments by Direct Physical Reads
Segments by Direct Physical Reads DB/Inst: MAC/MAC2 Snaps: 70719-70723-> Total Direct Physical Reads: 14,118,552-> Captured Segments account for 94.2% of Total Tablespace Subobject Obj. DirectOwner Name Object Name Name Type Reads %Total---------- ---------- -------------------- ---------- ----- ------------ -------CONTENT_OW SONG_TS MZ_SONG TABLE 7,084,416 50.18CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 4,839,984 34.28CONTENT_OW DATA_TS MZ_PUBLICATION TABLE 1,361,133 9.64CONTENT_OW DATA_TS SYS_LOB0000203660C00 LOB 5,904 .04CONTENT_OW DATA_TS SYS_LOB0000203733C00 LOB 1,656 .01
Direct reads 直接路徑物理讀，單位為 塊數(shù)*次數(shù)
%Total (該段上發(fā)生的direct path reads /Total physical reads direct )
11-7 Segments by Physical Writes
Physical Writes ，物理寫 單位為 塊數(shù)*次數(shù)
Total % (該段上發(fā)生的物理寫 /Total physical writes )
11-9 Segments by Physical Write Requests
Phys Write Requests 物理寫的請(qǐng)求次數(shù) ，單位為次數(shù)
%Total (該段上發(fā)生的物理寫請(qǐng)求次數(shù) /physical write IO requests )
11-10 Segments by Direct Physical Writes
Segments by Direct Physical Writes DB/Inst: MAC/MAC2 Snaps: 70719-70723-> Total Direct Physical Writes: 29,660-> Captured Segments account for 18.3% of Total Tablespace Subobject Obj. DirectOwner Name Object Name Name Type Writes %Total---------- ---------- -------------------- ---------- ----- ------------ -------SYS SYSAUX WRH$_ACTIVE_SESSION_ 1367_70520 TABLE 4,601 15.51CONTENT_OW DATA_TS SYS_LOB0000203733C00 LOB 620 2.09CONTENT_OW DATA_TS SYS_LOB0000203660C00 LOB 134 .45CONTENT_OW DATA_TS SYS_LOB0000203779C00 LOB 46 .16CONTENT_OW DATA_TS SYS_LOB0000203796C00 LOB 41 .14
Direct Writes 直接路徑寫， 單位額為塊數(shù)*次數(shù)
%Total 為(該段上發(fā)生的直接路徑寫 /physical writes direct )
11-11 Segments by Table Scans
Segments by Table Scans DB/Inst: MAC/MAC2 Snaps: 70719-70723-> Total Table Scans: 10,713-> Captured Segments account for 1.0% of Total Tablespace Subobject Obj. TableOwner Name Object Name Name Type Scans %Total---------- ---------- -------------------- ---------- ----- ------------ -------CONTENT_OW DATA_TS MZ_PUBLICATION TABLE 92 .86CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 14 .13CONTENT_OW SONG_TS MZ_SONG TABLE 3 .03CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 1 .01
Table Scans 來(lái)源為dba_hist_seg_stat.table_scans_delta 不過(guò)這個(gè)指標(biāo)并不十分精確
11-12 Segments by DB Blocks Changes
DB Block Changes ，單位為塊數(shù)*次數(shù)
%Total : (該段上發(fā)生block changes / db block changes )
11-13 Segments by Row Lock Waits
Row Lock Waits 是指行鎖的等待次數(shù) 數(shù)據(jù)來(lái)源于 dba_hist_seg_stat.ROW_LOCK_WAITS_DELTA
11-14 Segments by ITL WAITS
關(guān)于 ITL的介紹詳見(jiàn)：
http://www.askmaclean.com/archives/enqueue-tx-row-lock-index-itl-wait-event.htmlITL Waits 等待 ITL 的次數(shù)，數(shù)據(jù)來(lái)源為 dba_hist_seg_stat.itl_waits_delta
11-14 Segments by Buffer Busy Waits
Buffer Busy Waits 該數(shù)據(jù)段上發(fā)生 buffer busy wait的次數(shù) 數(shù)據(jù)來(lái)源 dba_hist_seg_stat.buffer_busy_waits_delta
11-15 Segments by Global Cache Buffer
Segments by Global Cache Buffer BusyDB/Inst: MAC/MAC2 Snaps: 70719-7072-> % of Capture shows % of GC Buffer Busy for each top segment compared-> with GC Buffer Busy for all segments captured by the Snapshot GC Tablespace Subobject Obj. Buffer % ofOwner Name Object Name Name Type Busy Capture---------- ---------- -------------------- ---------- ----- ------------ -------CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 2,135,528 50.07CONTENT_OW DATA_TS MZ_CONTENT_PROVIDER_ TABLE 652,900 15.31CONTENT_OW LOB_8K_TS MZ_ASSET_WORK_EVENT_ INDEX 552,161 12.95CONTENT_OW LOB_8K_TS MZ_CS_WORK_NOTE_RE_I _2013_1_36 INDEX 113,042 2.65CONTENT_OW LOB_8K_TS MZ_CS_WORK_INFO_PART _2013_5_35 INDEX 98,134 2.30
GC Buffer Busy 數(shù)據(jù)段上發(fā)揮僧gc buffer busy的次數(shù)， 數(shù)據(jù)源 dba_hist_seg_stat.gc_buffer_busy_delta
11-15 Segments by CR Blocks Received
Segments by CR Blocks Received DB/Inst: MAC/MAC2 Snaps: 70719-70723-> Total CR Blocks Received: 763,037-> Captured Segments account for 40.9% of Total CR Tablespace Subobject Obj. BlocksOwner Name Object Name Name Type Received %Total---------- ---------- -------------------- ---------- ----- ------------ -------CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 69,100 9.06CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 44,491 5.83CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 36,830 4.83CONTENT_OW DATA_TS MZ_PODCAST TABLE 36,632 4.80CONTENT_OW INDEX_TS MZ_AM_REQUEST_PK INDEX 19,646 2.57
CR Blocks Received ：是指RAC中本地節(jié)點(diǎn)接收到global cache CR blocks 的數(shù)量； 數(shù)據(jù)來(lái)源為 dba_hist_seg_stat.gc_cu_blocks_received_delta
%Total : (該段上在本節(jié)點(diǎn)接收的Global CR blocks / gc cr blocks received )
11-16 Segments by Current Blocks Received
Segments by Current Blocks ReceivedDB/Inst: MAC/MAC2 Snaps: 70719-70723-> Total Current Blocks Received: 704,731-> Captured Segments account for 61.8% of Total Current Tablespace Subobject Obj. BlocksOwner Name Object Name Name Type Received %Total---------- ---------- -------------------- ---------- ----- ------------ -------CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3 INDEX 56,287 7.99CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX3A INDEX 45,139 6.41CONTENT_OW DATA_TS MZ_AM_REQUEST TABLE 40,350 5.73CONTENT_OW DATA_TS MZ_CS_WORK_PENDING_R TABLE 22,808 3.24CONTENT_OW INDEX_TS MZ_AM_REQUEST_IX8 INDEX 13,343 1.89
Current Blocks Received :是指RAC中本地節(jié)點(diǎn)接收到global cache Current blocks 的數(shù)量 ，數(shù)據(jù)來(lái)源DBA_HIST_SEG_STAT.gc_cu_blocks_received_delta
%Total : (該段上在本節(jié)點(diǎn)接收的 global cache current blocks / gc current blocks received)
12 Dictionary Cache Stats
Dictionary Cache Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723-> "Pct Misses" should be very low (< 2% in most cases) -> "Final Usage" is the number of cache entries being used Get Pct Scan Pct Mod FinalCache Requests Miss Reqs Miss Reqs Usage------------------------- ------------ ------ ------- ----- -------- ----------dc_awr_control 87 2.3 0 N/A 6 1dc_global_oids 1,134 7.8 0 N/A 0 13dc_histogram_data 6,119,027 0.9 0 N/A 0 11,784dc_histogram_defs 1,898,714 2.3 0 N/A 0 5,462dc_object_grants 175 26.9 0 N/A 0 4dc_objects 10,254,514 0.2 0 N/A 0 3,807dc_profiles 8,452 0.0 0 N/A 0 2dc_rollback_segments 3,031,044 0.0 0 N/A 0 1,947dc_segments 1,812,243 1.4 0 N/A 10 3,595dc_sequences 15,783 69.6 0 N/A 15,782 20dc_table_scns 70 2.9 0 N/A 0 1dc_tablespaces 1,628,112 0.0 0 N/A 0 37dc_users 2,037,138 0.0 0 N/A 0 52global database name 7,698 0.0 0 N/A 0 1outstanding_alerts 264 99.6 0 N/A 8 1sch_lj_oids 51 7.8 0 N/A 0 1
Dictionary Cache 字典緩存也叫row cache
數(shù)據(jù)來(lái)源為dba_hist_rowcache_summary
Cache 字典緩存類名kqrstcid <=> kqrsttxt cid=3(dc_rollback_segments)
Get Requests 申請(qǐng)獲取該數(shù)據(jù)字典緩存對(duì)象的次數(shù) gets
Miss : GETMISSES 申請(qǐng)獲取該數(shù)據(jù)字典緩存對(duì)象但 miss的次數(shù)
Pct Miss ： GETMISSES /Gets ， Miss的比例 ，這個(gè)pct miss應(yīng)當(dāng)非常低 小于2%，否則有出現(xiàn)大量row cache lock的可能
Scan Reqs：掃描申請(qǐng)的次數(shù) ，kqrssc 、kqrpScan 、kqrpsiv時(shí)發(fā)生scan 會(huì)導(dǎo)致掃描數(shù)增加 kqrstsrq++(scan requests) ，例如migrate tablespace 時(shí)調(diào)用 kttm2b函數(shù) 為了安全刪除uet$中的記錄會(huì)callback kqrpsiv (used extent cache)，實(shí)際很少見(jiàn)
Pct Miss：SCANMISSES/SCANS
Mod Reqs: 申請(qǐng)修改字典緩存對(duì)象的次數(shù)，從上面的數(shù)據(jù)可以看到dc_sequences的mod reqs很高，這是因?yàn)閟equence是變化較多的字典對(duì)象
Final Usage ：包含有有效數(shù)據(jù)的字典緩存記錄的總數(shù) 也就是正在被使用的row cache記錄 USAGE Number of cache entries that contain valid data
Dictionary Cache Stats (RAC) DB/Inst: MAC/MAC2 Snaps: 70719-70723 GES GES GESCache Requests Conflicts Releases------------------------- ------------ ------------ ------------dc_awr_control 14 2 0dc_global_oids 88 0 102dc_histogram_defs 43,518 0 43,521dc_objects 21,608 17 21,176dc_profiles 1 0 1dc_segments 24,974 14 24,428dc_sequences 25,178 10,644 347dc_table_scns 2 0 2dc_tablespaces 165 0 166dc_users 119 0 119outstanding_alerts 478 8 250sch_lj_oids 4 0 4
GES Request kqrstilr total instance lock requests ，通過(guò)全局隊(duì)列服務(wù)GES 來(lái)申請(qǐng)instance lock的次數(shù)
GES request 申請(qǐng)的原因可能是 dump cache object、kqrbfr LCK進(jìn)程要background free some parent objects釋放一些parent objects 等
GES Conflicts kqrstifr instance lock forced-releases ， LCK進(jìn)程以AST方式 釋放鎖的次數(shù) ，僅出現(xiàn)在kqrbrl中
GES Releases kqrstisr instance lock self-releases ，LCK進(jìn)程要background free some parent objects釋放一些parent objects 時(shí)可能自增
上述數(shù)據(jù)中可以看到僅有dc_sequences 對(duì)應(yīng)的GES Conflicts較多， 對(duì)于sequence 使用ordered和non-cache選項(xiàng)會(huì)導(dǎo)致RAC中的一個(gè)邊際效應(yīng)，即”row cache lock”等待源于DC_SEQUENCES ROW CACHE。 DC_SEQUENCES 上的GETS request、modifications 、GES requests和GES conflict 與引發(fā)生成一個(gè)新的 sequence number的特定SQL執(zhí)行頻率相關(guān)。
在Oracle 10g中，ORDERED Sequence還可能在高并發(fā)下造成大量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 0BODY 8,697 0.7 15,537 0.7 49 0CLUSTER 317 4.7 321 4.7 0 0DBLINK 9,212 0.1 0 N/A 0 0EDITION 4,431 0.0 8,660 0.0 0 0HINTSET OBJECT 1,027 9.5 1,027 14.4 0 0INDEX 792 18.2 792 18.2 0 0QUEUE 10 0.0 1,733 0.0 0 0RULESET 0 N/A 8 87.5 7 0SCHEMA 8,169 0.0 0 N/A 0 0SQL AREA 533,409 4.8 -4,246,727,944 101.1 44,864 576SQL AREA BUILD 71,500 65.5 0 N/A 0 0SQL AREA STATS 41,008 90.3 41,008 90.3 1 0TABLE/PROCEDURE 320,310 0.6 1,033,991 3.6 25,378 0TRIGGER 847 0.0 38,442 0.3 110 0
NameSpace library cache 的命名空間
GETS Requests 該命名空間所包含對(duì)象的library cache lock被申請(qǐng)的次數(shù)
GETHITS 對(duì)象的 library cache handle 正好在內(nèi)存中被找到的次數(shù)
Pct Misses : ( 1- ( GETHITS /GETS Requests)) *100
Pin Requests 該命名空間所包含對(duì)象上pin被申請(qǐng)的次數(shù)
PINHITS 要pin的對(duì)象的heap metadata正好在shared pool中的次數(shù)
Pct Miss ( 1- ( PINHITS /Pin Requests)) *100
Reloads 指從object handle 被重建開(kāi)始不是第一次PIN該對(duì)象的PIN ，且該次PIN要求對(duì)象從磁盤上讀取加載的次數(shù) ;Reloads值較高的情況 建議增大shared_pool_size
INVALIDATIONS 由于以來(lái)對(duì)象被修改導(dǎo)致該命名空間所包含對(duì)象被標(biāo)記為無(wú)效的次數(shù)
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 0BODY 0 15,497 15,497 0 0CLUSTER 321 321 321 0 0DBLINK 9,212 0 0 0 0EDITION 4,431 4,431 4,431 0 0HINTSET OBJECT 1,027 1,027 1,027 0 0INDEX 792 792 792 0 0QUEUE 8 1,733 1,733 0 0RULESET 0 8 8 0 0SCHEMA 4,226 0 0 0 0TABLE/PROCEDURE 373,163 704,816 704,816 0 0TRIGGER 0 38,430 38,430 0 0
GES Lock Request: dlm_lock_requests Lock instance-lock ReQuests 申請(qǐng)獲得lock instance lock的次數(shù)
GES PIN request : DLM_PIN_REQUESTS Pin instance-lock ReQuests 申請(qǐng)獲得pin instance lock的次數(shù)
GES Pin Releases DLM_PIN_RELEASES release the pin instance lock 釋放pin instance lock的次數(shù)
GES Inval Requests DLM_INVALIDATION_REQUESTS get the invalidation instance lock 申請(qǐng)獲得invalidation instance lock的次數(shù)
GES Invali- dations DLM_INVALIDATIONS 接收到其他節(jié)點(diǎn)的invalidation pings次數(shù)
14 Process Memory Summary
Process Memory Summary DB/Inst: MAC/MAC2 Snaps: 70719-70723-> B: Begin Snap E: End Snap-> All rows below contain absolute values (i.e. not diffed over the interval)-> Max Alloc is Maximum PGA Allocation size at snapshot time-> Hist Max Alloc is the Historical Max Allocation for still-connected processes-> ordered by Begin/End snapshot, Alloc (MB) desc Hist Avg Std Dev Max Max 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,609E 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
數(shù)據(jù)來(lái)源為dba_hist_process_mem_summary， 這里是對(duì)PGA 使用的一個(gè)小結(jié)，幫助我們了解到底誰(shuí)用掉了PGA
B: 開(kāi)始快照 E: 結(jié)束快照
該環(huán)節(jié)列出 PGA中各分類的使用量
Category 分類名，包括”SQL”, “PL/SQL”, “OLAP” 和”JAVA”. 特殊分類是 “Freeable” 和”O(jiān)ther”. Free memory是指哪些 OS已經(jīng)分配給進(jìn)程，但沒(méi)有分配給任何分類的內(nèi)存。 “Other”是已經(jīng)分配給分類的內(nèi)存，但不是已命名的分類
Alloc (MB) allocated_total 該分類被分配的總內(nèi)存
Used (MB) used_total 該分類已使用的內(nèi)存
Avg Alloc (MB) allocated_avg 平均每個(gè)進(jìn)程中該分類分配的內(nèi)存量
Std Dev Alloc (MB) ：該分類分配的內(nèi)存在每個(gè)進(jìn)程之間的標(biāo)準(zhǔn)差
Max Alloc (MB) ALLOCATED_MAX ：在快照時(shí)間內(nèi)單個(gè)進(jìn)程該分類最大分配過(guò)的內(nèi)存量：Max Alloc is Maximum PGA Allocation size at snapshot time
Hist Max Alloc (MB) MAX_ALLOCATED_MAX: 目前仍鏈接著的進(jìn)程該分類最大分配過(guò)的內(nèi)存量：Hist Max Alloc is the Historical Max Allocation for still-connected processes
Num Proc num_processes 進(jìn)程數(shù)目
Num Alloc NON_ZERO_ALLOCS 分配了該類型 內(nèi)存的進(jìn)程數(shù)目
14 SGA信息
14 -1 SGA Memory Summary
SGA Memory Summary DB/Inst: MAC/MAC2 Snaps: 70719-70723 End Size (Bytes)SGA regions Begin Size (Bytes) (if different)------------------------------ ------------------- -------------------Database Buffers 20,669,530,112Fixed Size 2,241,880Redo Buffers 125,669,376Variable Size 10,536,094,376 -------------------sum 31,333,535,744
粗粒度的sga區(qū)域內(nèi)存使用信息， End Size僅在于begin size不同時(shí)打印
14-2 SGA breakdown difference
SGA breakdown difference DB/Inst: MAC/MAC2 Snaps: 70719-70723-> ordered by Pool, Name-> N/A value for Begin MB or End MB indicates the size of that Pool/Name was insignificant, or zero in that snapshotPool Name Begin MB End MB % Diff------ ------------------------------ -------------- -------------- -------java free memory 64.0 64.0 0.00large PX msg pool 7.8 7.8 0.00large free memory 247.8 247.8 0.00shared Checkpoint queue 140.6 140.6 0.00shared FileOpenBlock 2,459.2 2,459.2 0.00shared KGH: NO ACCESS 1,629.6 1,629.6 0.00shared KGLH0 997.7 990.5 -0.71shared KKSSP 312.2 308.9 -1.06shared SQLA 376.6 370.6 -1.61shared db_block_hash_buckets 178.0 178.0 0.00shared dbktb: trace buffer 156.3 156.3 0.00shared event statistics per sess 187.1 187.1 0.00shared free memory 1,208.9 1,220.6 0.97shared gcs resources 435.0 435.0 0.00shared gcs shadows 320.6 320.6 0.00shared ges enqueues 228.9 228.9 0.00shared ges resource 118.3 118.3 0.00shared init_heap_kfsg 1,063.6 1,068.1 0.43shared kglsim object batch 124.3 124.3 0.00shared ksunfy : SSO free list 174.7 174.7 0.00stream free memory 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 內(nèi)存池的名字
Name 內(nèi)存池中細(xì)分組件的名字 例如KGLH0 存放KEL Heap 0 、SQLA存放SQL執(zhí)行計(jì)劃等
Begin MB 快照開(kāi)始時(shí)該組件的內(nèi)存大小
End MB 快照結(jié)束時(shí)該組件的內(nèi)存大小
% Diff 差異百分比
特別注意 由于AMM /ASMM引起的shared pool收縮 一般在sga breakdown中可以提現(xiàn) 例如SQLA 、KQR等組件大幅縮小 ，可能導(dǎo)致一系列的解析等待 cursor: Pin S on X 、row cache lock等
此處的free memory信息也值得我們關(guān)注， 一般推薦shared pool應(yīng)當(dāng)有300~400 MB 的free memory為宜
15 Streams統(tǒng)計(jì)
Streams CPU/IO Usage DB/Inst: ORCL/orcl1 Snaps: 556-559-> Streams processes ordered by CPU usage-> CPU and I/O Time in micro secondsSession Type CPU Time User I/O Time Sys I/O Time------------------------- -------------- -------------- --------------QMON Coordinator 101,698 0 0QMON Slaves 63,856 0 0 -------------------------------------------------------------Streams Capture DB/Inst: CATGT/catgt Snaps: 911-912 -> Lag Change should be small or negative (in seconds) Captured Enqueued Pct Pct Pct Pct Per Per Lag RuleEval Enqueue RedoWait PauseCapture Name Second Second Change Time Time Time Time ------------ -------- -------- -------- -------- -------- -------- -------- CAPTURE_CAT 650 391 93 0 23 0 71 ------------------------------------------------------------- Streams Apply DB/Inst: CATGT/catgt Snaps: 911-912 -> Pct DB is the percentage of all DB transactions that this apply handled -> WDEP is the wait for dependency -> WCMT is the wait for commit -> RBK is rollbacks -> MPS is messages per second -> TPM is time per message in milli-seconds -> Lag Change should be small or negative (in seconds) Applied Pct Pct Pct Pct Applied Dequeue Apply Lag Apply Name TPS DB WDEP WCMT RBK MPS TPM TPM Change ------------ -------- ---- ---- ---- --- -------- -------- -------- -------- APPLY_CAT 0 0 0 0 0 0 0 0 0 -------------------------------------------------------------
Capture Name : Streams捕獲進(jìn)程名
Captured Per Second ：每秒挖掘出來(lái)的message 條數(shù)
Enqueued Per Second: 每秒入隊(duì)的message條數(shù)
lag change: 指日志生成的時(shí)間到挖掘到該日志生成 message的時(shí)間延遲
Pct Enqueue Time： 入隊(duì)時(shí)間的比例
Pct redoWait Time : 等待redo的時(shí)間比例
Pct Pause Time : Pause 時(shí)間的比例
Apply Name Streams 應(yīng)用Apply進(jìn)程的名字
Applied TPS : 每秒應(yīng)用的事務(wù)數(shù)
Pct DB: 所有的DB事務(wù)中 apply處理的比例
Pct WDEP: 由于等待依賴的數(shù)據(jù)而耗費(fèi)的時(shí)間比例
Pct WCMT: 由于等待commit而耗費(fèi)的時(shí)間比例
Pct RBK: 事務(wù)rollback 回滾的比例
Applied MPS: 每秒應(yīng)用的message 數(shù)
Dequeue TPM: 每毫秒出隊(duì)的message數(shù)
Lag Change:指最新message生成的時(shí)間到其被Apply收到的延遲
16 Resource Limit
Resource Limit Stats DB/Inst: MAC/MAC2 Snap: 70723-> only rows with Current or Maximum Utilization > 80% of Limit are shown-> ordered by resource name Current Maximum InitialResource Name Utilization Utilization Allocation Limit------------------------------ ------------ ------------ ---------- ----------ges_procs 2,612 8,007 10003 10003processes 2,615 8,011 10000 10000
數(shù)據(jù)源于dba_hist_resource_limit
注意這里僅列出當(dāng)前使用或最大使用量>80% *最大限制的資源名，如果沒(méi)有列在這里則說(shuō)明 資源使用量安全
Current Utilization 當(dāng)前對(duì)該資源(包括Enqueue Resource、Lock和processes)的使用量
Maximum Utilization 從最近一次實(shí)例啟動(dòng)到現(xiàn)在該資源的最大使用量
Initial Allocation 初始分配值，一般等于參數(shù)文件中指定的值
Limit 實(shí)際上限值
17 init.ora Parameters
init.ora Parameters DB/Inst: MAC/MAC2 Snaps: 70719-70723 End valueParameter Name Begin value (if different)----------------------------- --------------------------------- --------------_compression_compatibility 11.2.0_kghdsidx_count 4_ksmg_granule_size 67108864_shared_pool_reserved_min_all 4100archive_lag_target 900audit_file_dest /u01/app/oracle/admin/MAC/adumaudit_trail OScluster_database TRUEcompatible 11.2.0.2.0control_files +DATA/MAC/control01.ctl, +RECOdb_16k_cache_size 268435456db_block_size 8192db_cache_size 19327352832db_create_file_dest +DATA
Parameter Name 參數(shù)名
Begin value 開(kāi)始快照時(shí)的參數(shù)值
End value 結(jié)束快照時(shí)的參數(shù)值 (僅在發(fā)生變化時(shí)打印)
18 Global Messaging Statistics
Global Messaging Statistics DB/Inst: MAC/MAC2 Snaps: 70719-70723Statistic Total per Second per Trans--------------------------------- ---------------- ------------ ------------acks for commit broadcast(actual) 53,705 14.9 0.2acks for commit broadcast(logical 311,182 86.1 1.3broadcast msgs on commit(actual) 317,082 87.7 1.3broadcast msgs on commit(logical) 317,082 87.7 1.3broadcast msgs on commit(wasted) 263,332 72.9 1.1dynamically allocated gcs resourc 0 0.0 0.0dynamically allocated gcs shadows 0 0.0 0.0flow control messages received 267 0.1 0.0flow control messages sent 127 0.0 0.0gcs apply delta 0 0.0 0.0gcs assume cvt 55,541 15.4 0.2
全局通信統(tǒng)計(jì)信息，數(shù)據(jù)來(lái)源WRH$_DLM_MISC;
20 Global CR Served Stats
Global CR Served Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723Statistic Total------------------------------ ------------------CR Block Requests 403,703CURRENT Block Requests 444,896Data Block Requests 403,705Undo Block Requests 94,336TX Block Requests 307,896Current Results 652,746Private results 21,057Zero Results 104,720Disk Read Results 69,418Fail Results 508Fairness Down Converts 102,844Fairness Clears 15,207Free GC Elements 0Flushes 105,052Flushes Queued 0Flush Queue Full 0Flush Max Time (us) 0Light Works 71,793Errors 117
LMS傳輸CR BLOCK的統(tǒng)計(jì)信息，數(shù)據(jù)來(lái)源WRH$_CR_BLOCK_SERVER
21 Global CURRENT Served Stats
Global CURRENT Served Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723-> Pins = CURRENT Block Pin Operations-> Flushes = Redo Flush before CURRENT Block Served Operations-> Writes = CURRENT Block Fusion Write OperationsStatistic Total % <1ms % <10ms % <100ms % <1s % <10s---------- ------------ -------- -------- -------- -------- --------Pins 73,018 12.27 75.96 8.49 2.21 1.08Flushes 79,336 5.98 50.17 14.45 19.45 9.95Writes 102,189 3.14 35.23 19.34 33.26 9.03
數(shù)據(jù)來(lái)源dba_hist_current_block_server
Time to process current block request = (pin time + flush time + send time)
Pins CURRENT Block Pin Operations ， PIN的內(nèi)涵是處理一個(gè)BAST 不包含對(duì)global current block的flush和實(shí)際傳輸
The pin time represents how much time is required to process a BAST. It does not include the flush time and
the send time. The average pin time per block served should be very low because the processing consists
mainly of code path and should never be blocked.
Flush 指 臟塊被LMS進(jìn)程傳輸出去之前，其相關(guān)的redo必須由LGWR已經(jīng)flush 到磁盤上
Write 指fusion write number of writes which were mediated； 節(jié)點(diǎn)之間寫臟塊需求相互促成的行為 KJBL.KJBLREQWRITE gcs write request msgs 、gcs writes refused
% <1ms % <10ms % <100ms % <1s % <10s 分別對(duì)應(yīng)為pin、flush、write行為耗時(shí)的比例
例如在上例中flush和 write 在1s 到10s之間的有9%，在100ms 和1s之間的有19%和33%，因?yàn)閒lush和write都是IO操作 所以這里可以預(yù)見(jiàn)IO存在問(wèn)題，延遲較高
22 Global Cache Transfer Stats
Global Cache Transfer Stats DB/Inst: MAC/MAC2 Snaps: 70719-70723-> Immediate (Immed) - Block Transfer NOT impacted by Remote Processing Delays-> Busy (Busy) - Block Transfer impacted by Remote Contention-> Congested (Congst) - Block Transfer impacted by Remote System Load-> ordered by CR + Current Blocks Received desc CR Current ----------------------------- -----------------------------Inst Block Blocks % % % Blocks % % % No Class 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
數(shù)據(jù)來(lái)源DBA_HIST_INST_CACHE_TRANSFER
Inst No 節(jié)點(diǎn)號(hào)
Block Class 塊的類型
CR Blocks Received 該節(jié)點(diǎn)上 該類型CR 塊的接收數(shù)量
CR Immed %: CR塊請(qǐng)求立即接收到的比例
CR Busy%：CR塊請(qǐng)求由于遠(yuǎn)端爭(zhēng)用而沒(méi)有立即接收到的比例
CR Congst%: CR塊請(qǐng)求由于遠(yuǎn)端負(fù)載高而沒(méi)有立即接收到的比例
Current Blocks Received 該節(jié)點(diǎn)上 該類型Current 塊的接收數(shù)量
Current Immed %: Current塊請(qǐng)求立即接收到的比例
Current Busy%：Current塊請(qǐng)求由于遠(yuǎn)端爭(zhēng)用而沒(méi)有立即接收到的比例
Current Congst%: Current塊請(qǐng)求由于遠(yuǎn)端負(fù)載高而沒(méi)有立即接收到的比例
Congst%的比例應(yīng)當(dāng)非常低 不高于2%， Busy%很大程度受到IO的影響，如果超過(guò)10% 一般會(huì)有嚴(yán)重的gc buffer busy acquire/release
補(bǔ)充 RAC 相關(guān)指標(biāo) 內(nèi)容由 tong.wang@parnassusdata.com 整理
RAC相關(guān)指標(biāo)
Global Cache Load Profile
Per SecondPer Transaction
Global Cache blocks received:12.062.23
Global Cache blocks served:8.181.51
GCS/GES messages received:391.1972.37
GCS/GES messages sent:368.7668.22
DBWR Fusion writes:0.100.02
Estd Interconnect traffic (KB)310.31
指標(biāo)指標(biāo)說(shuō)明
Global Cache blocks received通過(guò)硬件連接收到遠(yuǎn)程實(shí)例的數(shù)據(jù)塊的數(shù)量。發(fā)生在一個(gè)進(jìn)程請(qǐng)求一致性讀一個(gè)數(shù)據(jù)塊不是在本地緩存中。Oracle發(fā)送一個(gè)請(qǐng)求到另外的實(shí)例。一旦緩沖區(qū)收到，這個(gè)統(tǒng)計(jì)值就會(huì)增加。這個(gè)統(tǒng)計(jì)值是另兩個(gè)統(tǒng)計(jì)值的和：Global Cache blocks received = gc current blocks received + gc cr blocks received
Global Cache blocks served通過(guò)硬件連接發(fā)送到遠(yuǎn)程實(shí)例的數(shù)據(jù)塊的數(shù)量。這個(gè)統(tǒng)計(jì)值是另外兩個(gè)統(tǒng)計(jì)值的和：Global Cache blocks served = gc current blocks served + gc cr blocks served
GCS/GES messages received通過(guò)硬件連接收到遠(yuǎn)程實(shí)例的消息的數(shù)量。這個(gè)統(tǒng)計(jì)值通常代表RAC服務(wù)引起的開(kāi)銷。這個(gè)統(tǒng)計(jì)值是另外兩個(gè)統(tǒng)計(jì)值的和：GCS/GES messages received = gcs msgs received + ges msgs received
GCS/GES messages sent通過(guò)硬件連接發(fā)送到遠(yuǎn)程實(shí)例的消息的數(shù)量。這個(gè)統(tǒng)計(jì)值通常代表RAC服務(wù)引起的開(kāi)銷。這個(gè)統(tǒng)計(jì)值是另外兩個(gè)統(tǒng)計(jì)值的和：GCS/GES messages sent = gcs messages sent + ges messages sent
DBWR Fusion writes這個(gè)統(tǒng)計(jì)值顯示融合寫入的次數(shù)。在RAC中，單實(shí)例Oracle數(shù)據(jù)庫(kù)，數(shù)據(jù)塊只被寫入磁盤因?yàn)閿?shù)據(jù)過(guò)期，緩沖替換或者發(fā)生檢查點(diǎn)。當(dāng)一個(gè)數(shù)據(jù)塊在緩存中被替換因?yàn)閿?shù)據(jù)過(guò)期或發(fā)生檢查點(diǎn)但在另外的實(shí)例沒(méi)有寫入磁盤，Global Cache Service會(huì)請(qǐng)求實(shí)例將數(shù)據(jù)塊寫入磁盤。因此融合寫入不包括在第一個(gè)實(shí)例中的額外寫入磁盤。大量的融合寫入表明一個(gè)持續(xù)的問(wèn)題。實(shí)例產(chǎn)生的融合寫入請(qǐng)求占總的寫入請(qǐng)求的比率用于性能分析。高比率表明DB cache大小不合適或者檢查點(diǎn)效率低。
Estd Interconnect traffic (KB)連接傳輸?shù)腒B大小。計(jì)算公式如下：Estd Interconnect traffic (KB) = ((‘gc cr blocks received’+ ‘gc current blocks received’ + ‘gc cr blocksserved’+ ‘gc current blocks served’) * Block size)
+ ((‘gcs messages sent’ + ‘ges messages sent’ + ‘gcs msgs received’+ ‘gcs msgs
received’)*200)/1024/Elapsed Time
Global Cache Efficiency Percentages (Target local+remote 100%)
Buffer access – local cache %:91.05
Buffer access – remote cache %:0.03
Buffer access – disk %:8.92
指標(biāo)指標(biāo)說(shuō)明
Buffer access – local cache %數(shù)據(jù)塊從本地緩存命中占會(huì)話總的數(shù)據(jù)庫(kù)請(qǐng)求次數(shù)的比例。在OLTP應(yīng)用中最希望的是盡可能維持這個(gè)比率較高，因?yàn)檫@是最低成本和最快速的獲得數(shù)據(jù)庫(kù)數(shù)據(jù)塊的方法。計(jì)算公式：Local Cache Buffer Access Ratio = 1 – ( physical reads cache + Global Cache blocks received ) / Logical Reads
Buffer access – remote cache %數(shù)據(jù)塊從遠(yuǎn)程實(shí)例緩存命中占會(huì)話總的數(shù)據(jù)塊請(qǐng)求的比例。在OLTP應(yīng)用中這個(gè)比率和Buffer access – local cache的和應(yīng)該盡可能的高因?yàn)檫@兩種方法訪問(wèn)數(shù)據(jù)庫(kù)數(shù)據(jù)塊是最快速最低成本的。這個(gè)比率的計(jì)算方法：Remote Cache Buffer Access Ratio = Global Cache blocks received / Logical Reads
Buffer access – disk %從磁盤上讀數(shù)據(jù)塊到緩存占會(huì)話總的數(shù)據(jù)塊請(qǐng)求次數(shù)的比例。在OLTP應(yīng)用中希望維持這個(gè)比例低因?yàn)槲锢碜x是最慢的訪問(wèn)數(shù)據(jù)庫(kù)數(shù)據(jù)塊的方式。這個(gè)比率計(jì)算方法：1 – physical reads cache / Logical Reads
Global Cache and Enqueue Services – Workload Characteristics
Avg global enqueue get time (ms):0.0
Avg global cache cr block receive time (ms):0.3
Avg global cache current block receive time (ms):0.2
Avg global cache cr block build time (ms):0.0
Avg global cache cr block send time (ms):0.0
Global cache log flushes for cr blocks served %:1.2
Avg global cache cr block flush time (ms):1.8
Avg global cache current block pin time (ms):1,021.7
Avg global cache current block send time (ms):0.0
Global cache log flushes for current blocks served %:6.9
Avg global cache current block flush time (ms):0.9
本文永久地址http://www.askmaclean.com/archives/rac-awr-statistics.html指標(biāo)指標(biāo)說(shuō)明
Avg global enqueue get time (ms)通過(guò)interconnect發(fā)送消息，為爭(zhēng)奪資源開(kāi)啟一個(gè)新的全局隊(duì)列或者對(duì)已經(jīng)開(kāi)啟的隊(duì)列轉(zhuǎn)換訪問(wèn)模式所花費(fèi)的時(shí)間。如果大于20ms，你的系統(tǒng)可能會(huì)出現(xiàn)超時(shí)。
Avg global cache cr block receive time (ms)從請(qǐng)求實(shí)例發(fā)送消息到mastering instance（2-way get）和一些到holding instance (3-way get)花費(fèi)的時(shí)間。這個(gè)時(shí)間包括在holding instance生成數(shù)據(jù)塊一致性讀映像的時(shí)間。CR數(shù)據(jù)塊獲取耗費(fèi)的時(shí)間不應(yīng)該大于15ms。
Avg global cache current block receive time (ms)從請(qǐng)求實(shí)例發(fā)送消息到mastering instance（2-way get）和一些到holding instance (3-way get)花費(fèi)的時(shí)間。這個(gè)時(shí)間包括holding instance日志刷新花費(fèi)的時(shí)間。Current Block獲取耗費(fèi)的時(shí)間不大于30ms
Avg global cache cr block build time (ms)CR數(shù)據(jù)塊創(chuàng)建耗費(fèi)的時(shí)間
Avg global cache cr block send time (ms)CR數(shù)據(jù)塊發(fā)送耗費(fèi)的時(shí)間
Global cache log flushes for cr blocks served %需要日志刷新的CR數(shù)據(jù)塊占總的需要服務(wù)的CR數(shù)據(jù)塊的比例。
Avg global cache cr block flush time (ms)CR數(shù)據(jù)塊刷新耗費(fèi)的時(shí)間
Avg global cache current block pin time (ms)Current數(shù)據(jù)塊pin耗費(fèi)的時(shí)間
Avg global cache current block send time (ms)Current數(shù)據(jù)塊發(fā)送耗費(fèi)的時(shí)間
Global cache log flushes for current blocks served %需要日志刷新的Current數(shù)據(jù)塊占總的需要服務(wù)的Current數(shù)據(jù)塊的比例
Avg global cache current block flush time (ms)Current數(shù)據(jù)塊刷新耗費(fèi)的時(shí)間
Global Cache and Enqueue Services – Messaging Statistics
Avg message sent queue time (ms):2,367.6
Avg message sent queue time on ksxp (ms):0.1
Avg message received queue time (ms):0.3
Avg GCS message process time (ms):0.0
Avg GES message process time (ms):0.0
% of direct sent messages:54.00
% of indirect sent messages:44.96
% of flow controlled messages:1.03
指標(biāo)指標(biāo)說(shuō)明
Avg message sent queue time (ms)一條信息進(jìn)入隊(duì)列到發(fā)送它的時(shí)間
Avg message sent queue time on ksxp (ms)對(duì)端收到該信息并返回ACK的時(shí)間，這個(gè)指標(biāo)很重要，直接反應(yīng)了網(wǎng)絡(luò)延遲，一般小于1ms
Avg message received queue time (ms)一條信息進(jìn)入隊(duì)列到收到它的時(shí)間
Avg GCS message process time (ms)
Avg GES message process time (ms)
% of direct sent messages直接發(fā)送信息占的比率
% of indirect sent messages間接發(fā)送信息占的比率，一般是排序或大的信息，流控制也可能引起
% of flow controlled messages流控制信息占的比率，流控制最常見(jiàn)的原因是網(wǎng)絡(luò)狀況不佳， % of flowcontrolled messages應(yīng)當(dāng)小于1%
Wait Event Histogram
% of Waits
EventTotal Waits<1ms<2ms<4ms<8ms<16ms<32ms<=1s>1s
ADR block file read20838.0 3.444.713.9
ADR block file write40100.0
ADR file lock48100.0
ARCH wait for archivelog lock3100.0
ASM file metadata operation12.8K99.7.1.0 .0.0.2.0
Backup: MML write backup piece310.5K7.6.1.11.310.430.250.2.0
CGS wait for IPC msg141.7K100.0
CSS initialization3450.0 47.12.9
CSS operation: action11048.220.928.22.7
CSS operation: query10288.23.97.8
DFS lock handle660793.9.5.2.0 .05.3.0
Disk file operations I/O1474100.0
IPC send completion sync21.9K99.5.1.1.1.0.2
KJC: Wait for msg sends to complete13100.0
LGWR wait for redo copy16.3K100.0.0
Log archive I/O333.366.7
PX Deq: Signal ACK EXT225699.8.1.1
PX Deq: Signal ACK RSG212499.9.1.0
PX Deq: Slave Session Stats799794.6.9.92.5.8.4
PX Deq: Table Q qref235599.9.1
PX Deq: reap credit1215.7K100.0.0.0
PX qref latch1366100.0
Parameter File I/O19494.81.0 1.01.0 1.5.5
Wait Event Histogram：等待時(shí)間直方圖
Event：等待事件名字
Total Waits：該等待事件在快照時(shí)間內(nèi)等待的次數(shù)
%of Waits < 1ms ：小于1ms的等待次數(shù)
%of Waits < 2ms ：小于2ms的等待次數(shù)
%of Waits < 4ms ：小于4ms的等待次數(shù)
%of Waits < 8ms ：小于8ms的等待次數(shù)
%of Waits < 16ms ：小于16ms的等待次數(shù)
%of Waits < 32ms ：小于32ms的等待次數(shù)
%of Waits < =1s ：小于等于1s的等待次數(shù)
%of Waits > 1s ：大于1s的等待次數(shù)
Parent Latch Statistics
only latches with sleeps are shown
ordered by name
Latch NameGet RequestsMissesSleepsSpin & Sleeps 1->3+
Real-time plan statistics latch77,84013620116/0/0/0
active checkpoint queue latch321,02320,5287720451/0/0/0
active service list339,641546132424/0/0/0
call allocation328,283550148440/0/0/0
enqueues1,503,52521714203/0/0/0
ksuosstats global area2,605110/0/0/0
messages2,608,863141,38029141351/0/0/0
name-service request queue155,047431528/0/0/0
qmn task queue latch2,368907812/0/0/0
query server process26830300/0/0/0
redo writing910,70311,6235011573/0/0/0
resmgr:free threads list14,4541904186/0/0/0
space background task latch11,2091578/0/0/0
Latch Name：閂名稱
Get Requests：申請(qǐng)獲得父閂的次數(shù)
本文永久地址http://www.askmaclean.com/archives/rac-awr-statistics.htmlChild Latch Statistics
only latches with sleeps/gets > 1/100000 are shown
ordered by name, gets desc
Latch NameChild NumGet RequestsMissesSleepsSpin & Sleeps 1->3+
KJC message pool free list196,136822062/0/0/0
Lsod array latch102,22215311858/0/0/0
Lsod array latch132,151431429/0/0/0
Lsod array latch42,06615412459/0/0/0
Lsod array latch51,9881054463/0/0/0
Lsod array latch91,734953264/0/0/0
Lsod array latch21,707883855/0/0/0
Lsod array latch111,695883257/0/0/0
Lsod array latch61,68015812664/0/0/0
Lsod array latch121,65715511165/0/0/0
Lsod array latch71,640903459/0/0/0
Lsod array latch11,62716915346/0/0/0
Lsod array latch31,555873654/0/0/0
Lsod array latch81,4871278857/0/0/0
cache buffers chains47418354,3133914387/0/0/0
cache buffers chains8031337,1352508242/0/0/0
cache buffers chains78358305,0225289519/0/0/0
cache buffers chains6927241,8081294125/0/0/0
Latch Name：閂名稱
Child Num：
Get Requests：
Misses：
Sleeps：
Spin&Sleeps 1->3+：
Dictionary Cache Stats (RAC)
CacheGES RequestsGES ConflictsGES Releases
dc_awr_control1150
dc_global_oids500
dc_histogram_defs2151707
dc_objects9090
dc_segments791073
dc_sequences35,738370
dc_table_scns600
dc_tablespace_quotas907770
dc_users1000
outstanding_alerts5762880
Cache：字典緩存類名
GES Requests：
GES Conflicts：
GES Releases：
Library Cache Activity (RAC)
NamespaceGES Lock RequestsGES Pin RequestsGES Pin ReleasesGES Inval RequestsGES Invali- dations
ACCOUNT_STATUS2420000
BODY01,530,0131,530,01300
CLUSTER74747400
DBLINK2460000
EDITION31131131100
HINTSET OBJECT18618618600
INDEX152,360152,360152,36000
QUEUE2239,7179,71700
SCHEMA2550000
SUBSCRIPTION0262600
TABLE/PROCEDURE275,2153,023,0833,023,08300
TRIGGER0384,493384,49300
Namespace：library cache 的命名空間
GES Lock Requests：
GES Pin Requests：
GES Inval Requests：
GES Invali-dations：
Interconnect Ping Latency Stats
Ping latency of the roundtrip of a message from this instance to
target instances.
The target instance is identified by an instance number.
Average and standard deviation of ping latency is given in miliseconds
for message sizes of 500 bytes and 8K.
Note that latency of a message from the instance to itself is used as
control, since message latency can include wait for CPU
Target Instance500B Ping CountAvg Latency 500B msgStddev 500B msg8K Ping CountAvg Latency 8K msgStddev 8K msg
11,1380.200.031,1380.200.03
21,1380.170.041,1380.200.05
31,1380.190.221,1380.230.22
41,1380.180.041,1380.210.04
Target Instance：目標(biāo)實(shí)例
500B Ping Count：
Avg Latency 500B msg：
Stddev 500B msg：
8K Ping Count：
Avg Latency 8K msg：
Stddev 8K msg：
Interconnect Throughput by Client
Throughput of interconnect usage by major consumers
All throughput numbers are megabytes per second
Used BySend Mbytes/secReceive Mbytes/sec
Global Cache0.100.20
Parallel Query0.020.06
DB Locks0.090.09
DB Streams0.000.00
Other0.020.01
Used By：主要消費(fèi)者
Send Mbytes/sec：發(fā)送Mb/每秒
Receive Mbytes/sec：接收Mb/每秒
Interconnect Device Statistics
Throughput and errors of interconnect devices (at OS level)
All throughput numbers are megabytes per second
Device NameIP AddressPublicSourceSend Mbytes/secSend ErrorsSend DroppedSend Buffer OverrunSend Carrier LostReceive Mbytes/secReceive ErrorsReceive DroppedReceive Buffer OverrunReceive Frame Errors
bondib0192.168.10.8NOcluster_interconnects parameter0.0000000.00000
Device Name：設(shè)備名稱
IP Address：IP地址
Public：是否為公用網(wǎng)絡(luò)
Source：來(lái)源
Send Mbytes/sec：發(fā)送MB/每秒
Send Errors：發(fā)送錯(cuò)誤
Send Dropped：
Send Buffer Overrun：
Send Carrier Lost：
Receive Mbytes/sec：
Receive Errors：
Receive Dropped：
Receive Buffer Overrun：
Receive Frame Errors：
Dynamic Remastering Stats
times are in seconds
Affinity objects – objects mastered due to affinity at begin/end snap
NameTotalper Remaster OpBegin SnapEnd Snap
remaster ops291.00
remastered objects401.38
replayed locks received1,99068.62
replayed locks sent87730.24
resources cleaned00.00
remaster time (s)5.00.17
quiesce time (s)1.70.06
freeze time (s)0.60.02
cleanup time (s)0.70.02
replay time (s)0.20.01
fixwrite time (s)1.30.04
sync time (s)0.50.02
affinity objects 365367
Name：
Total：
Per Remaster Op：
Begin Snap：
End Snap：
轉(zhuǎn)自：http://www.askmaclean.com/archives/performance-tuning-oracle-awr.html
