1-5 Top 5 Timed Events
Waits : 該等待事件發生的次數， 對於DB CPU此項不可用
Times : 該等待事件消耗的總計時間，單位為秒， 對於DB CPU 而言是前台進程所消耗CPU時間片的總和，但不包括Wait on CPU QUEUE
Avg Wait(ms) : 該等待事件平均等待的時間， 實際就是 Times/Waits，單位ms， 對於DB CPU此項不可用
% 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
2-1 Time Model Statistics
Time Model Statistics幾個特別有用的時間指標：
parse time elapsed、hard parse elapsed time 結合起來看解析是否是主要矛盾，若是則重點是軟解析還是硬解析
sequence load elapsed time sequence序列爭用是否是問題焦點
PL/SQL compilation elapsed time PL/SQL對象編譯的耗時
注意PL/SQL execution elapsed time 純耗費在PL/SQL解釋器上的時間。不包括花在執行和解析其包含SQL上的時間
connection management call elapsed time 建立數據庫session連接和斷開的耗時
failed parse elapsed time 解析失敗，例如由於ORA-4031
hard parse (sharing criteria) elapsed time 由於無法共享游標造成的硬解析
hard parse (bind mismatch) elapsed time 由於bind type or bind size 不一致造成的硬解析
2-2 Foreground Wait Class
Wait Class: 等待事件的類型，如上查詢所示，被分作12個類型。 10.2.0.5有916個等待事件，其中Other類型占622個。
Waits: 該類型所屬等待事件在快照時間內的等待次數
%Time Out 等待超時的比率， 未 超時次數/waits * 100 (%)
Total Wait Time: 該類型所屬等待事件總的耗時，單位為秒
Avg Wait(ms) : 該類型所屬等待事件的平均單次等待時間，單位為ms ，實際這個指標對commit 和 user i/o 以及system i/o類型有點意義，其他等待類型由於等待事件差異較大所以看平均值的意義較小
waits / txn: 該類型所屬等待事件的等待次數和事務比
2-3 前台等待事件
Foreground Wait Events 前台等待事件，數據主要來源於DBA_HIST_SYSTEM_EVENT
Event 等待事件名字
Waits 該等待事件在快照時間內等待的次數
%Timeouts : 每一個等待事件有其超時的設置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件 單次等待達到timeout的時間，則會進入下一次該等待事件
Total Wait Time 該等待事件 總的消耗的時間 ，單位為秒
Avg wait(ms): 該等待事件的單次平均等待時間，單位為毫秒
Waits/Txn: 該等待事件的等待次數和事務比
2-4 后台等待事件
Background Wait Events 后台等待事件， 數據主要來源於DBA_HIST_BG_EVENT_SUMMARY
Event 等待事件名字
Waits 該等待事件在快照時間內等待的次數
%Timeouts : 每一個等待事件有其超時的設置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件 單次等待達到timeout的時間，則會進入下一次該等待事件
Total Wait Time 該等待事件 總的消耗的時間 ，單位為秒
Avg wait(ms): 該等待事件的單次平均等待時間，單位為毫秒
Waits/Txn: 該等待事件的等待次數和事務比
2-5 Operating System Statistics
NUM_CPU_SOCKETS 物理CPU的數目
NUM_CPU_CORES CPU的核數
NUM_CPUS 邏輯CPU的數目
SYS_TIME 在內核態被消耗掉的CPU時間片，單位為百分之一秒
USER_TIME 在用戶態被消耗掉的CPU時間片，單位為百分之一秒
BUSY_TIME Busy_Time=SYS_TIME+USER_TIME 消耗的CPU時間片，單位為百分之一秒
AVG_BUSY_TIME AVG_BUSY_TIME= BUSY_TIME/NUM_CPUS
IDLE_TIME 空閑的CPU時間片，單位為百分之一秒
所有CPU所能提供總的時間片 BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
OS_CPU_WAIT_TIME 進程等OS調度的時間，cpu queuing
VM_IN_BYTES 換入頁的字節數
VM_OUT_BYTES 換出頁的字節數，部分版本下並不准確，例如Bug 11712010 Abstract: VIRTUAL MEMORY PAGING ON 11.2.0.2 DATABASES，僅供參考
IOWAIT_TIME 所有CPU花費在等待I/O完成上的時間 單位為百分之一秒
RSRC_MGR_CPU_WAIT_TIME 是指當resource manager控制CPU調度時，需要控制對應進程暫時不使用CPU而進程到內部運行隊列中，以保證該進程對應的consumer group(消費組)沒有消耗比指定resource manager指令更多的CPU。RSRC_MGR_CPU_WAIT_TIME指等在內部運行隊列上的時間，在等待時不消耗CPU
2-6 Service Statistcs
按照Service Name來分組時間模型和 物理、邏輯讀取， 部分數據來源於 WRH$_SERVICE_NAME;
Service Name 對應的服務名 (v$services)， SYS$BACKGROUND代表后台進程， SYS$USERS一般是系統用戶登錄
DB TIME (s): 本服務名所消耗的DB TIME時間，單位為秒
DB CPU(s): 本服務名所消耗的DB CPU 時間，單位為秒
Physical Reads : 本服務名所消耗的物理讀
Logical Reads : 本服務所消耗的邏輯讀
2-7 Service Wait Class Stats
User I/O Total Wts : 對應該服務名下 用戶I/O類等待的總的次數
User I/O Wt Time : 對應該服務名下 用戶I/O累等待的總時間，單位為 1/100秒
Concurcy Total Wts: 對應該服務名下 Concurrency 類型等待的總次數
Concurcy Wt Time :對應該服務名下 Concurrency 類型等待的總時間， 單位為 1/100秒
Admin Total Wts: 對應該服務名下Admin 類等待的總次數
Admin Wt Time: 對應該服務名下Admin類等待的總時間，單位為 1/100秒
Network Total Wts : 對應服務名下Network類等待的總次數
Network Wt Time： 對應服務名下Network類等待的總事件， 單位為 1/100秒
2-8 Host CPU
Load Average begin/end值代表每個CPU的大致運行隊列大小。上例中快照開始到結束，平均 CPU負載增加了；與《2-5 Operating System Statistics》中的LOAD相呼應。
%User+%System=> 總的CPU使用率，在這里是31.8%
Elapsed Time * NUM_CPUS * CPU utilization= 60.23 (mins) * 24 * 31.8% = 459.67536 mins=Busy Time
2-9 Instance CPU
%Total CPU,該實例所使用的CPU占總CPU的比例 % of total CPU for Instance
%Busy CPU，該實例所使用的Cpu占總的被使用CPU的比例 % of busy CPU for Instance
例如共4個邏輯CPU，其中3個被完全使用，3個中的1個完全被該實例使用，
則%Total CPU= ? =25%，
而%Busy CPU= 1/3= 33%
當CPU高時一般看%Busy CPU可以確定CPU到底是否是本實例消耗的，還是主機上其他程序
% 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
【性能調優】Oracle AWR報告指標全解析
2013/08/31 by Maclean Liu 暫無評論
【性能調優】Oracle AWR報告指標全解析
開Oracle調優鷹眼，深入理解AWR性能報告：http://www.askmaclean.com/archives/awr-hawk-eyes-training.html
開Oracle調優鷹眼，深入理解AWR性能報告 第二講： http://www.askmaclean.com/archives/awr-tuning-hawk-eyes.html
如果自己搞不定可以找詩檀軟件專業ORACLE數據庫修復團隊成員幫您恢復!
詩檀軟件專業數據庫修復團隊
服務熱線 ： 13764045638 QQ號:47079569 郵箱：service@parnassusdata.com
有同學在看過《Oracle調優鷹眼，深入理解AWR性能報告》的教學視頻后急切期待第三講，但實際是第三講需要結合大量的原理知識才能充分理解 例如Latch activity 、Undo、Dynamic Resource Master均需要理解其原理才能充分理解。 所以這些AWR的環節將在 Maclean 今后的 系列調優講座中介紹。 對於《Oracle調優鷹眼系列》 則會增加本附錄，作為對全部Oracle AWR指標的介紹， 本附錄對於原理理解方面的內容將不多，而更側重於指標含義的介紹，是對AWR鷹眼講座的工具文檔。
如果你覺得本AWR解析中的哪些指標仍理解不透徹 或者講的不清楚的，可以在本頁中留言，謝謝大家的支持。
Hawk Eyes 看AWR的鷹眼= 基礎理論夯實+看過500份以上AWR
啥是AWR?
=====================================================================================================
AWR (Automatic Workload Repository)
一堆歷史性能數據，放在SYSAUX表空間上， AWR和SYSAUX都是10g出現的，是Oracle調優的關鍵特性； 大約1999年左右開始開發，已經有15年歷史
默認快照間隔1小時，10g保存7天、11g保存8天; 可以通過DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS修改
DBA_HIST_WR_CONTROL
AWR程序核心是dbms_workload_repository包
@?/rdbms/admin/awrrpt 本實例
@?/rdbms/admin/awrrpti RAC中選擇實例號
誰維護AWR?
主要是MMON(Manageability Monitor Process)和它的小工進程(m00x)
MMON的功能包括:
1.啟動slave進程m00x去做AWR快照
2.當某個度量閥值被超過時發出alert告警
3.為最近改變過的SQL對象捕獲指標信息
AWR小技巧
手動執行一個快照：
Exec dbms_workload_repository.create_snapshot; (這個要背出來哦，用的時候去翻手冊，丟臉哦 J!)
創建一個AWR基線
Exec DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id，end_snap_id ,baseline_name);
@?/rdbms/admin/awrddrpt AWR比對報告
@?/rdbms/admin/awrgrpt RAC 全局AWR
自動生成AWR HTML報告：
http://www.oracle-base.com/dba/10g/generate_multiple_awr_reports.sql
1、報告總結
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst Num Startup Time Release RAC
------------ ----------- ------------ -------- --------------- ----------- ---
MAC 2629627371 askmaclean.com 1 22-Jan-13 16:49 11.2.0.3.0 YES
Host Name Platform CPUs Cores Sockets Memory(GB)
---------------- -------------------------------- ---- ----- ------- ----------
MAC10 AIX-Based Systems (64-bit) 128 32 320.00
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 5853 23-Jan-13 15:00:56 3,520 1.8
End Snap: 5854 23-Jan-13 15:30:41 3,765 1.9
Elapsed: 29.75 (mins)
DB Time: 7,633.76 (mins)
Elapsed 為該AWR性能報告的時間跨度(自然時間的跨度，例如前一個快照snapshot是4點生成的，后一個快照snapshot是6點生成的，則若使用@?/rdbms/admin/awrrpt 腳本中指定這2個快照的話，那么其elapsed = (6-4)=2 個小時)，一個AWR性能報告 至少需要2個AWR snapshot性能快照才能生成 ( 注意這2個快照時間 實例不能重啟過，否則指定這2個快照生成AWR性能報告 會報錯)，AWR性能報告中的 指標往往是 后一個快照和前一個快照的 指標的delta，這是因為 累計值並不能反映某段時間內的系統workload。
DB TIME= 所有前台session花費在database調用上的總和時間：
■注意是前台進程foreground sessions
■包括CPU時間、IO Time、和其他一系列非空閑等待時間，別忘了cpu on queue time
DB TIME 不等於 響應時間，DB TIME高了未必響應慢，DB TIME低了未必響應快
DB Time描繪了數據庫總體負載，但要和elapsed time逝去時間結合其他來。
Average Active Session AAS= DB time/Elapsed Time
DB Time =60 min ， Elapsed Time =60 min AAS=60/60=1 負載一般
DB Time= 1min , Elapsed Time= 60 min AAS= 1/60 負載很輕
DB Time= 60000 min，Elapsed Time= 60 min AAS=1000 系統hang了吧？
DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue
如果僅有2個邏輯CPU，而2個session在60分鍾都沒等待事件，一直跑在CPU上，那么：
DB CPU= 2 * 60 mins ， DB Time = 2* 60 + 0 + 0 =120
AAS = 120/60=2 正好等於OS load 2。
如果有3個session都100%僅消耗CPU，那么總有一個要wait on queue
DB CPU = 2* 60 mins ，wait on CPU queue= 60 mins
AAS= (120+ 60)/60=3 主機load 亦為3，此時vmstat 看waiting for run time
真實世界中？ DB Cpu = xx mins ， Non-Idle Wait= enq:TX + cursor pin S on X + latch : xxx + db file sequential read + ……….. 阿貓阿狗
1-1 內存參數大小
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 49,152M 49,152M Std Block Size: 8K
Shared Pool Size: 13,312M 13,312M Log Buffer: 334,848K
內存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)
小內存有小內存的問題， 大內存有大內存的麻煩！ ORA-04031???!!
Buffer cache和shared pool size的 begin/end值在ASMM、AMM和11gR2 MSMM下可是會動的哦！
這里說 shared pool一直收縮，則在shrink過程中一些row cache 對象被lock住可能導致前台row cache lock等解析等待，最好別讓shared pool shrink。如果這里shared pool一直在grow，那說明shared pool原有大小不足以滿足需求(可能是大量硬解析)，結合下文的解析信息和SGA breakdown來一起診斷問題。
1-2 Load Profile
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ --------------- --------------- ---------- ----------
DB Time(s): 256.6 0.2 0.07 0.03
DB CPU(s): 3.7 0.0 0.00 0.00
Redo size: 1,020,943.0 826.5
Logical reads: 196,888.0 159.4
Block changes: 6,339.4 5.1
Physical reads: 5,076.7 4.1
Physical writes: 379.2 0.3
User calls: 10,157.4 8.2
Parses: 204.0 0.2
Hard parses: 0.9 0.0
W/A MB processed: 5.0 0.0
Logons: 1.7 0.0
Executes: 3,936.6 3.2
Rollbacks: 1,126.3 0.9
Transactions: 1,235.3
% Blocks changed per Read: 53.49 Recursive Call %: 98.04
Rollback per transaction %: 36.57 Rows per Sort: 73.70
指標 指標含義
redo size 單位 bytes，redo size可以用來估量update/insert/delete的頻率，大的redo size往往對lgwr寫日志，和arch歸檔造成I/O壓力， Per Transaction可以用來分辨是 大量小事務， 還是少量大事務。如上例每秒redo 約1MB ，每個事務800 字節，符合OLTP特征
Logical Read 單位 次數*塊數， 相當於 “人*次”， 如上例 196,888 * db_block_size=1538MB/s ， 邏輯讀耗CPU，主頻和CPU核數都很重要，邏輯讀高則DB CPU往往高，也往往可以看到latch: cache buffer chains等待。 大量OLTP系統(例如siebel)可以高達幾十乃至上百Gbytes。
Block changes 單位 次數*塊數 ， 描繪數據變化頻率
Physical Read 單位次數*塊數， 如上例 5076 * 8k = 39MB/s， 物理讀消耗IO讀，體現在IOPS和吞吐量等不同緯度上；但減少物理讀可能意味着消耗更多CPU。好的存儲 每秒物理讀能力達到幾GB，例如Exadata。 這個physical read包含了physical reads cache和physical reads direct
Physical writes 單位 次數*塊數，主要是DBWR寫datafile，也有direct path write。 dbwr長期寫出慢會導致定期log file switch(checkpoint no complete) 檢查點無法完成的前台等待。 這個physical write 包含了physical writes direct +physical writes from cache
User Calls 單位次數，用戶調用數，more details from internal
Parses 解析次數，包括軟解析+硬解析，軟解析優化得不好，則誇張地說幾乎等於每秒SQL執行次數。 即執行解析比1:1，而我們希望的是 解析一次 到處運行哦！
Hard Parses 萬惡之源． 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中處理的數據數量
結合 In-memory Sort%， sorts (disk) PGA Aggr一起看
Logons 登陸次數， logon storm 登陸風暴，結合AUDIT審計數據一起看。短連接的附帶效應是游標緩存無用
Executes 執行次數，反應執行頻率
Rollback 回滾次數， 反應回滾頻率， 但是這個指標不太精確，參考而已，別太當真
Transactions 每秒事務數，是數據庫層的TPS，可以看做壓力測試或比對性能時的一個指標，孤立看無意義
% Blocks changed per Read 每次邏輯讀導致數據塊變化的比率；如果’redo size’, ‘block changes’ ‘pct of blocks changed per read’三個指標都很高，則說明系統正執行大量insert/update/delete;
pct of blocks changed per read = (block changes ) /( logical reads)
Recursive Call % 遞歸調用的比率;Recursive Call % = (recursive calls)/(user calls)
Rollback per transaction % 事務回滾比率。 Rollback per transaction %= (rollback)/(transactions)
Rows per Sort 平均每次排序涉及到的行數 ; Rows per Sort= ( sorts(rows) ) / ( sorts(disk) + sorts(memory))
注意這些Load Profile 負載指標 在本環節提供了 2個維度 per second 和 per transaction。
per Second: 主要是把 快照內的delta值除以 快站時間的秒數 ， 例如 在 A快照中V$SYSSTAT視圖反應 table scans (long tables) 這個指標是 100 ，在B快照中V$SYSSTAT視圖反應 table scans (long tables) 這個指標是 3700, 而A快照和B快照 之間 間隔了一個小時 3600秒， 則 對於 table scans (long tables) per second 就是 ( 3700- 100) /3600=1。
pert Second是我們審視數據的主要維度 ，任何性能數據脫離了 時間模型則毫無意義。
在statspack/AWR出現之前 的調優 洪荒時代， 有很多DBA 依賴 V$SYSSTAT等視圖中的累計 統計信息來調優，以當前的調優眼光來看，那無異於刀耕火種。
per transaction : 基於事務的維度， 與per second相比 是把除數從時間的秒數改為了該段時間內的事務數。 這個維度的很大用戶是用來 識別應用特性的變化 ，若2個AWR性能報告中該維度指標 出現了大幅變化，例如 redo size從本來per transaction 1k變化為 10k per transaction，則說明SQL業務邏輯肯定發生了某些變化。
注意AWR中的這些指標 並不僅僅用來孤立地了解 Oracle數據庫負載情況， 實施調優工作。 對於 故障診斷 例如HANG、Crash等， 完全可以通過對比問題時段的性能報告和常規時間來對比，通過各項指標的對比往往可以找出 病灶所在。
SELECT VALUE FROM DBA_HIST_SYSSTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND STAT_NAME in ( "db block changes","user calls","user rollbacks","user commits",redo size","physical reads direct","physical writes","parse count (hard)","parse count (total)","session logical reads","recursive calls","redo log space requests","redo entries","sorts (memory)","sorts (disk)","sorts (rows)","logons cumulative","parse time cpu","parse time elapsed","execute count","logons current","opened cursors current","DBWR fusion writes","gcs messages sent","ges messages sent","global enqueue gets sync","global enqueue get time","gc cr blocks received","gc cr block receive time","gc current blocks received","gc current block receive time","gc cr blocks served","gc cr block build time","gc cr block flush time","gc cr block send time","gc current blocks served","gc current block pin time","gc current block flush time","gc current block send time","physical reads","physical reads direct (lob)",
SELECT TOTAL_WAITS FROM DBA_HIST_SYSTEM_EVENT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND EVENT_NAME in ("gc buffer busy","buffer busy waits"
SELECT VALUE FROM DBA_HIST_SYS_TIME_MODEL WHERE DBID = :B4 AND SNAP_ID = :B3 AND INSTANCE_NUMBER = :B2 AND STAT_NAME in ("DB CPU","sql execute elapsed time","DB time"
SELECT VALUE FROM DBA_HIST_PARAMETER WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND PARAMETER_NAME in ("__db_cache_size","__shared_pool_size","sga_target","pga_aggregate_target","undo_management","db_block_size","log_buffer","timed_statistics","statistics_level"
SELECT BYTES FROM DBA_HIST_SGASTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND POOL IN ('shared pool', 'all pools') AND NAME in ("free memory",
SELECT BYTES FROM DBA_HIST_SGASTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND NAME = :B1 AND POOL IS NULL
SELECT (E.BYTES_PROCESSED - B.BYTES_PROCESSED) FROM DBA_HIST_PGA_TARGET_ADVICE B, DBA_HIST_PGA_TARGET_ADVICE E WHERE B.DBID = :B4 AND B.SNAP_ID = :B3 AND B.INSTANCE_NUM
BER = :B2 AND B.ADVICE_STATUS = 'ON' AND E.DBID = B.DBID AND E.SNAP_ID = :B1 AND E.INSTANCE_NUMBER = B.INSTANCE_NUMBER AND E.PGA_TARGET_FACTOR = 1 AND B.PGA_TARGET_FACT
OR = 1 AND E.ADVICE_STATUS = 'ON'
SELECT SUM(E.TOTAL_WAITS - NVL(B.TOTAL_WAITS, 0)) FROM DBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT E WHERE B.SNAP_ID(+) = :B4 AND E.SNAP_ID = :B3 AND B.DBID(+) = :B2
AND E.DBID = :B2 AND B.INSTANCE_NUMBER(+) = :B1 AND E.INSTANCE_NUMBER = :B1 AND B.EVENT_ID(+) = E.EVENT_ID AND (E.EVENT_NAME = 'latch free' OR E.EVENT_NAME LIKE 'latch
:%')
SELECT DECODE(B.TOTAL_SQL, 0, 0, 100*(1-B.SINGLE_USE_SQL/B.TOTAL_SQL)), DECODE(E.TOTAL_SQL, 0, 0, 100*(1-E.SINGLE_USE_SQL/E.TOTAL_SQL)), DECODE(B.TOTAL_SQL_MEM, 0, 0, 1
00*(1-B.SINGLE_USE_SQL_MEM/B.TOTAL_SQL_MEM)), DECODE(E.TOTAL_SQL_MEM, 0, 0, 100*(1-E.SINGLE_USE_SQL_MEM/E.TOTAL_SQL_MEM)) FROM DBA_HIST_SQL_SUMMARY B, DBA_HIST_SQL_SUMM
ARY E WHERE B.SNAP_ID = :B4 AND E.SNAP_ID = :B3 AND B.INSTANCE_NUMBER = :B2 AND E.INSTANCE_NUMBER = :B2 AND B.DBID = :B1 AND E.DBID = :B1
SELECT EVENT, WAITS, TIME, DECODE(WAITS, NULL, TO_NUMBER(NULL), 0, TO_NUMBER(NULL), TIME/WAITS*1000) AVGWT, PCTWTT, WAIT_CLASS FROM (SELECT EVENT, WAITS, TIME, PCTWTT,
WAIT_CLASS FROM (SELECT E.EVENT_NAME EVENT, E.TOTAL_WAITS - NVL(B.TOTAL_WAITS,0) WAITS, (E.TIME_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0)) / 1000000 TIME, 100 * (E.TIME
_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0)) / :B1 PCTWTT, E.WAIT_CLASS WAIT_CLASS FROM DBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT E WHERE B.SNAP_ID(+) = :B5 AND E.S
NAP_ID = :B4 AND B.DBID(+) = :B3 AND E.DBID = :B3 AND B.INSTANCE_NUMBER(+) = :B2 AND E.INSTANCE_NUMBER = :B2 AND B.EVENT_ID(+) = E.EVENT_ID AND E.TOTAL_WAITS > NVL(B.TO
TAL_WAITS,0) AND E.WAIT_CLASS != 'Idle' UNION ALL SELECT 'CPU time' EVENT, TO_NUMBER(NULL) WAITS, :B6 /1000000 TIME, 100 * :B6 / :B1 PCTWTT, NULL WAIT_CLASS FROM DUAL W
HERE :B6 > 0) ORDER BY TIME DESC, WAITS DESC) WHERE ROWNUM <= :B7
SELECT SUM(E.TIME_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0)) FROM DBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT E WHERE B.SNAP_ID(+) = :B4 AND E.SNAP_ID = :B3 AND B.DB
ID(+) = :B2 AND E.DBID = :B2 AND B.INSTANCE_NUMBER(+) = :B1 AND E.INSTANCE_NUMBER = :B1 AND B.EVENT_ID(+) = E.EVENT_ID AND E.WAIT_CLASS = 'User I/O'
SELECT (E.ESTD_LC_TIME_SAVED - B.ESTD_LC_TIME_SAVED) FROM DBA_HIST_SHARED_POOL_ADVICE B, DBA_HIST_SHARED_POOL_ADVICE E WHERE B.DBID = :B3 AND B.INSTANCE_NUMBER = :B2 AN
D B.SNAP_ID = :B4 AND E.DBID = :B3 AND E.INSTANCE_NUMBER = :B2 AND E.SNAP_ID = :B1 AND E.SHARED_POOL_SIZE_FACTOR = 1 AND B.SHARED_POOL_SIZE_FACTOR = 1
1-3 Instance Efficiency Percentages (Target 100%)
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.97 Redo NoWait %: 100.00
Buffer Hit %: 97.43 In-memory Sort %: 100.00
Library Hit %: 99.88 Soft Parse %: 99.58
Execute to Parse %: 94.82 Latch Hit %: 99.95
Parse CPU to Parse Elapsd %: 1.75 % Non-Parse CPU: 99.85
上述所有指標 的目標均為100%，即越大越好，在少數bug情況下可能超過100%或者為負值。
■80%以上 %Non-Parse CPU
■90%以上 Buffer Hit%, In-memory Sort%, Soft Parse%
■95%以上 Library Hit%, Redo Nowait%, Buffer Nowait%
■98%以上 Latch Hit%
1、 Buffer Nowait % session申請一個buffer(兼容模式)不等待的次數比例。 需要訪問buffer時立即可以訪問的比率， 不兼容的情況 在9i中是 buffer busy waits，從10g以后 buffer busy waits 分離為 buffer busy wait 和 read by other session2個等待事件 :
9i 中 waitstat的總次數基本等於buffer busy waits等待事件的次數
SQL> select sum(TOTAL_WAITS) from v$system_event where event='buffer busy waits';
SUM(TOTAL_WAITS)
—————-
33070394
SQL> select sum(count) from v$waitstat;
SUM(COUNT)
———-
33069335
10g waitstat的總次數基本等於 buffer busy waits 和 read by other session 等待的次數總和
SQL> select sum(TOTAL_WAITS) from v$system_event where event='buffer busy waits' or event='read by other session';
SUM(TOTAL_WAITS)
—————-
60675815
SQL> select sum(count) from v$waitstat;
SUM(COUNT)
———-
60423739
Buffer Nowait %的計算公式是 sum(v$waitstat.wait_count) / (v$sysstat statistic session logical reads)，例如在AWR中：
Class Waits Total Wait Time (s) Avg Time (ms)
data block 24,543 2,267 92
undo header 743 2 3
undo block 1,116 0 0
1st level bmb 35 0 0
session logical reads 40,769,800 22,544.84 204.71
Buffer Nowait %: 99.94
Buffer Nowait= ( 40,769,800 – (24543+743+1116+35))/ ( 40,769,800) = 0.99935= 99.94%
SELECT SUM(WAIT_COUNT) FROM DBA_HIST_WAITSTAT WHERE SNAP_ID = :B3 AND DBID = :B2 AND INSTANCE_NUMBER = :B1
2、buffer HIT%: 經典的經典，高速緩存命中率，反應物理讀和緩存命中間的糾結，但這個指標即便99% 也不能說明物理讀等待少了
不合理的db_cache_size，或者是SGA自動管理ASMM /Memory 自動管理AMM下都可能因為db_cache_size過小引起大量的db file sequential /scattered read等待事件； maclean曾經遇到過因為大量硬解析導致ASMM 下shared pool共享池大幅度膨脹，而db cache相應縮小shrink的例子，最終db cache收縮到只有幾百兆，本來沒有的物理讀等待事件都大幅涌現出來 。
此外與 buffer HIT%相關的指標值得關注的還有 table scans(long tables) 大表掃描這個統計項目、此外相關的欄目還有Buffer Pool Statistics 、Buffer Pool Advisory等（如果不知道在哪里，直接找一個AWR 去搜索這些關鍵詞即可)。
buffer HIT%在 不同版本有多個計算公式：
在9i中
Buffer Hit Ratio = 1 – ((physical reads – physical reads direct – physical reads direct (lob)) / (db block gets + consistent gets – physical reads direct – physical reads direct (lob))
在10g以后：
Buffer Hit Ratio= 1 – ((‘physical reads cache’) / (‘consistent gets from cache’ + ‘db block gets from cache’)
注意：但是實際AWR中 似乎還是按照9i中的算法，雖然算法的區別對最后算得的比率影響不大。
對於buffer hit % 看它的命中率有多高沒有意義，主要是關注 未命中的次數有多少。通過上述公式很容易反推出未命中的物理讀的次數。
db block gets 、consistent gets 以及 session logical reads的關系如下：
db block gets＝db block gets direct＋ db block gets from cache
consistent gets ＝ consistent gets from cache＋ consistent gets direct
consistent gets from cache＝ consistent gets – examination + else
consistent gets – examination==>指的是不需要pin buffer直接可以執行consistent get的次數，常用於索引，只需要一次latch get
session logical reads = db block gets +consistent gets
其中physical reads 、physical reads cache、physical reads direct、physical reads direct (lob)幾者的關系為：
physical reads = physical reads cache + physical reads direct
這個公式其實說明了 物理讀有2種 ：
■物理讀進入buffer cache中 ，是常見的模式 physical reads cache
■物理讀直接進入PGA 直接路徑讀， 即physical reads direct
physical reads 8 Total number 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 cache 8 Total number of data blocks read from disk into the buffer cache. This is a subset of “physical reads” statistic.
physical reads direct 8 Number 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(普通)
這個公式也說明了 直接路徑讀 分成三個部分：
■physical reads direct (lob) 直接路徑讀LOB對象
■physical reads direct temporary tablespace 直接路徑讀臨時表空間
■physical read direct(普通) 普通的直接路徑讀， 一般是11g開始的自動的大表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時不用等待的比例，redo相關的資源爭用例如redo space request爭用可能造成生成redo時需求等待。此項數據來源於v$sysstat中的(redo log space requests/redo entries)。 一般來說10g以后不太用關注log_buffer參數的大小，需要關注是否有十分頻繁的 log switch ； 過小的redo logfile size 如果配合較大的SGA和頻繁的commit提交都可能造成該問題。 考慮增到redo logfile 的尺寸 : 1~4G 每個，7~10組都是合適的。同時考慮優化redo logfile和datafile 的I/O。
4、In-memory Sort%:這個指標因為它不計算workarea中所有的操作類型，所以現在越來越雞肋了。 純粹在內存中完成的排序比例。數據來源於v$sysstat statistics sorts (disk) 和 sorts (memory)， In-memory Sort% = sort(memory) / ( sort(disk)+ sort(memory) )
5、
Library Hit%: library cache命中率，申請一個library cache object例如一個SQL cursor時，其已經在library cache中的比例。 數據來源 V$librarycache的pins和pinhits。 合理值：>95% ，該比例來源於1- ( Σ(pin Requests * Pct Miss) / Sum(Pin Requests) )
維護這個指標的重點是 保持shared pool共享池有足夠的Free Memory，且沒有過多的內存碎片，具體可以參考這里。 顯然過小的shared pool可用空間會導致library cache object被aged out換出共享池。
此外保證SQL語句綁定變量和游標可以共享也是很重要的因素。
Library Cache Activity DB/Inst: G10R25/G10R25 Snaps: 2964-2965
-> "Pct Misses" should be very low http://www.askmaclean.com
Get Pct Pin Pct Invali-
Namespace Requests Miss Requests Miss Reloads dations
--------------- ------------ ------ -------------- ------ ---------- --------
BODY 5 0.0 6 16.7 1 0
CLUSTER 10 0.0 26 0.0 0 0
SQL AREA 601,357 99.8 902,828 99.7 47 2
TABLE/PROCEDURE 83 9.6 601,443 0.0 48 0
GETS NUMBER Number of times a lock was requested for objects of this namespace
GETHITS NUMBER Number of times an object’s handle was found in memory
GETHITRATIO NUMBER Ratio of GETHITS to GETS
PINS NUMBER Number of times a PIN was requested for objects of this namespace
PINHITS NUMBER Number of times all of the metadata pieces of the library object were found in memory
PINHITRATIO NUMBER Ratio of PINHITS to PINS
RELOADS NUMBER Any 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
INVALIDATIONS NUMBER Total 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: 軟解析比例，無需多說的經典指標，數據來源v$sysstat statistics的parse count(total)和parse count(hard)。 合理值>95%
Soft Parse %是AWR中另一個重要的解析指標，該指標反應了快照時間內 軟解析次數 和 總解析次數 (soft+hard 軟解析次數+硬解析次數)的比值，若該指標很低，那么說明了可能存在劇烈的hard parse硬解析，大量的硬解析會消耗更多的CPU時間片並產生解析爭用(此時可以考慮使用cursor_sharing=FORCE)； 理論上我們總是希望 Soft Parse % 接近於100%， 但並不是說100%的軟解析就是最理想的解析狀態，通過設置 session_cached_cursors參數和反復重用游標我們可以讓解析來的更輕量級，即通俗所說的利用會話緩存游標實現的軟軟解析(soft soft parse)。
7、
Execute to Parse% 指標反映了執行解析比 其公式為 1-(parse/execute) , 目標為100% 及接近於只 執行而不解析。 數據來源v$sysstat statistics parse count (total) 和execute count
在oracle中解析往往是執行的先提工作，但是通過游標共享 可以解析一次 執行多次， 執行解析可能分成多種場景：
1.hard coding => 硬編碼代碼 硬解析一次 ，執行一次， 則理論上其執行解析比 為 1:1 ，則理論上Execute to Parse =0 極差，且soft parse比例也為0%
2.綁定變量但是仍軟解析=》 軟解析一次，執行一次 ， 這種情況雖然比前一種好 但是執行解析比(這里的parse，包含了軟解析和硬解析)仍是1:1， 理論上Execute to Parse =0 極差， 但是soft parse比例可能很高
3.使用 靜態SQL、動態綁定、session_cached_cursor、open cursors等技術實現的 解析一次，執行多次， 執行解析比為N:1， 則 Execute to Parse= 1- (1/N) 執行次數越多 Execute to Parse越接近100% ，這種是我們在OLTP環境中喜聞樂見的！
通俗地說 soft parse% 反映了軟解析率， 而軟解析在oracle中仍是較昂貴的操作， 我們希望的是解析1次執行N次，如果每次執行均需要軟解析，那么雖然soft parse%=100% 但是parse time仍可能是消耗DB TIME的大頭。
Execute to Parse反映了 執行解析比，Execute to Parse和soft parse% 都很低 那么說明確實沒有綁定變量 ， 而如果 soft parse% 接近99% 而Execute to Parse 不足90% 則說明沒有執行解析比低， 需要通過 靜態SQL、動態綁定、session_cached_cursor、open cursors等技術減少軟解析。
8、
Latch Hit%: willing-to-wait latch閂申請不要等待的比例。 數據來源V$latch gets和misses
Latch Name
----------------------------------------
Get Requests Misses Sleeps Spin Gets Sleep1 Sleep2 Sleep3
-------------- ----------- ----------- ---------- -------- -------- --------
shared pool
9,988,637 364 23 341 0 0 0
library cache
6,753,468 152 6 146 0 0 0
Memory Management Latch
369 1 1 0 0 0 0
qmn task queue latch
24 1 1 0 0 0 0
Latch Hit%:= (1 – (Sum(misses) / Sum(gets)))
關於Latch的更多信息內容可以參考 AWR后面的專欄Latch Statistics， 注意對於一個並發設計良好的OLTP應用來說，Latch、Enqueue等並發控制不應當成為系統的主要瓶頸， 同時對於這些並發爭用而言 堆積硬件CPU和內存 很難有效改善性能。
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:該指標反映了 快照內解析CPU時間和總的解析時間的比值(Parse CPU Time/ Parse Elapsed Time)； 若該指標水平很低，那么說明在整個解析過程中 實際在CPU上運算的時間是很短的，而主要的解析時間都耗費在各種其他非空閑的等待事件上了(如latch:shared pool,row cache lock之類等) 數據來源 V$sysstat 的 parse time cpu和parse time elapsed
10、
%Non-Parse CPU 非解析cpu比例，公式為 (DB CPU – Parse CPU)/DB CPU， 若大多數CPU都用在解析上了，則可能好鋼沒用在刃上了。 數據來源 v$sysstat 的 parse time cpu和 cpu used by this session
1-4 Shared Pool Statistics
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 84.64 79.67
% SQL with executions>1: 93.77 24.69
% Memory for SQL w/exec>1: 85.36 34.8
該環節提供一個大致的SQL重用及shared pool內存使用的評估。 應用是否共享SQL? 有多少內存是給只運行一次的SQL占掉的，對比共享SQL呢？
如果該環節中% SQL with executions>1的 比例 小於%90 ， 考慮用下面鏈接的SQL去抓 硬編碼的非綁定變量SQL語句。
利用FORCE_MATCHING_SIGNATURE捕獲非綁定變量SQL
Memory Usage %: (shared pool 的實時大小- shared pool free memory)/ shared pool 的實時大小， 代表shared pool的空間使用率，雖然有使用率但沒有標明碎片程度
% SQL with executions>1 復用的SQL占總的SQL語句的比率,數據來源 DBA_HIST_SQL_SUMMARY 的 SINGLE_USE_SQL和TOTAL_SQL：1 – SINGLE_USE_SQL / TOTAL_SQL
% Memory for SQL w/exec>1 執行2次以上的SQL所占內存占總的SQL內存的比率，數據來源DBA_HIST_SQL_SUMMARY 的SINGLE_USE_SQL_MEM和TOTAL_SQL_MEM：1 – SINGLE_USE_SQL_MEM / TOTAL_SQL_MEM
==》上面2個指標也可以用來大致了解shared pool中的內存碎片程序，因為SINGLE_USE_SQL 單次執行的SQL多的話，那么顯然可能有較多的共享池內存碎片
SQL復用率低的原因一般來說就是硬綁定變量(hard Coding)未合理使用綁定變量(bind variable)，對於這種現象短期無法修改代表使用綁定變量的可以ALTER SYSTEM SET CURSOR_SHARING=FORCE; 來繞過問題，對於長期來看還是要修改代碼綁定變量。 Oracle 從11g開始宣稱今后將廢棄CURSOR_SHARING的SIMILAR選項，同時SIMILAR選項本身也造成了很多問題，所以一律不推薦用CURSOR_SHARING=SIMILAR。
如果memory usage%比率一直很高，則可以關注下后面sga breakdown中的shared pool free memory大小，一般推薦至少讓free memroy有個300~500MB 以避免隱患。
1-5 Top 5 Timed Events
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
gc buffer busy 79,083 73,024 923 65.4 Cluster
enq: TX - row lock contention 35,068 17,123 488 15.3 Applicatio
CPU time 12,205 10.9
gc current request 2,714 3,315 1221 3.0 Cluster
gc cr multi block request 83,666 1,008 12 0.9 Cluster
基於Wait Interface的調優是目前的主流！每個指標都重要！
基於命中比例的調優，好比是統計局的報告， 張財主家財產100萬，李木匠家財產1萬， 平均財產50.5萬。
基於等待事件的調優，好比馬路上100輛汽車的行駛記錄表，上車用了幾分鍾， 紅燈等了幾分鍾，擁堵塞了幾分鍾。。。
豐富的等待事件以足夠的細節來描繪系統運行的性能瓶頸，這是Mysql夢寐以求的東西……
Waits : 該等待事件發生的次數， 對於DB CPU此項不可用
Times : 該等待事件消耗的總計時間，單位為秒， 對於DB CPU 而言是前台進程所消耗CPU時間片的總和，但不包括Wait on CPU QUEUE
Avg Wait(ms) : 該等待事件平均等待的時間， 實際就是 Times/Waits，單位ms， 對於DB CPU此項不可用
% 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
CPU 上在干什么？
邏輯讀？ 解析？Latch spin? PL/SQL、函數運算?
DB CPU/CPU time是Top 1 是好事情嗎？ 未必！
注意DB CPU不包含 wait on cpu queue！
SELECT e.event_name event,
e.total_waits - NVL (b.total_waits, 0) waits,
DECODE (
e.total_waits - NVL (b.total_waits, 0),
0, TO_NUMBER (NULL),
DECODE (
e.total_timeouts - NVL (b.total_timeouts, 0),
0, TO_NUMBER (NULL),
100
* (e.total_timeouts - NVL (b.total_timeouts, 0))
/ (e.total_waits - NVL (b.total_waits, 0))))
pctto,
(e.time_waited_micro - NVL (b.time_waited_micro, 0)) / 1000000 time,
DECODE (
(e.total_waits - NVL (b.total_waits, 0)),
0, TO_NUMBER (NULL),
( (e.time_waited_micro - NVL (b.time_waited_micro, 0)) / 1000)
/ (e.total_waits - NVL (b.total_waits, 0)))
avgwt,
DECODE (e.wait_class, 'Idle', 99, 0) idle
FROM dba_hist_system_event b, dba_hist_system_event e
WHERE b.snap_id(+) = &bid
AND e.snap_id = &eid
--AND b.dbid(+) = :dbid
--AND e.dbid = :dbid
AND b.instance_number(+) = 1
AND e.instance_number = 1
AND b.event_id(+) = e.event_id
AND e.total_waits > NVL (b.total_waits, 0)
AND e.event_name NOT IN
('smon timer',
'pmon timer',
'dispatcher timer',
'dispatcher listen timer',
'rdbms ipc message')
ORDER BY idle,
time DESC,
waits DESC,
event
幾種常見的等待事件
=========================>
db file scattered read, Avg wait time應當小於20ms 如果數據庫執行全表掃描或者是全索引掃描會執行 Multi block I/O ，此時等待物理I/O 結束會出現此等待事件。一般會從應用程序（SQL），I/O 方面入手調整; 注意和《Instance Activity Stats》中的index fast full scans (full) 以及 table scans (long tables)集合起來一起看。
db file sequential read ，該等待事件Avg wait time平均單次等待時間應當小於20ms
”db file sequential read”單塊讀等待是一種最為常見的物理IO等待事件，這里的sequential指的是將數據塊讀入到相連的內存空間中(contiguous memory space)，而不是指所讀取的數據塊是連續的。該wait event可能在以下情景中發生:
http://www.askmaclean.com/archives/db-file-sequential-read-wait-event.html
latch free 其實是未獲得latch ，而進入latch sleep，見《全面解析9i以后Oracle Latch閂鎖原理》
enq:XX 隊列鎖等待，視乎不同的隊列鎖有不同的情況：
■你有多了解Oracle Enqueue lock隊列鎖機制？
■Oracle隊列鎖: Enqueue HW
■Oracle隊列鎖enq:US,Undo Segment
■enq: TX – row lock/index contention、allocate ITL等待事件
■enq: TT – contention等待事件
■Oracle隊列鎖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：是由於無法找到可用的buffer cache 空閑區域，需要等待DBWR 寫入完成引起
■一般是由於
■低效的sql
■過小的buffer cache
■DBWR 工作負荷過量
buffer busy wait/ read by other session 一般以上2個等待事件可以歸為一起處理，建議客戶都進行監控 。 以上等待時間可以由如下操作引起
■select/select —- read by other session: 由於需要從 數據文件中將數據塊讀入 buffer cache 中引起，有可能是 大量的 邏輯/物理讀 ;或者過小的 buffer cache 引起
■select/update —- buffer busy waits/ read by other session 是由於更新某數據塊后 需要在undo 中 重建構建 過去時間的塊，有可能伴生 enq:cr-contention 是由於大量的物理讀/邏輯讀造成。
■update/update —- buffer busy waits 由於更新同一個數據塊（非同一行，同一行是enq:TX-contention） 此類問題是熱點塊造成
■insert/insert —- buffer busy waits 是由於freelist 爭用造成，可以將表空間更改為ASSM 管理 或者加大freelist 。
write complete waits :一般此類等待事件是由於 DBWR 將臟數據寫入 數據文件，其他進程如果需要修改 buffer cache會引起此等待事件，一般是 I/O 性能問題或者是DBWR 工作負荷過量引起
Wait time 1 Seconds.
control file parallel write：頻繁的更新控制文件會造成大量此類等待事件，如日志頻繁切換，檢查點經常發生，nologging 引起頻繁的數據文件更改，I/O 系統性能緩慢。
log file sync：一般此類等待時間是由於 LGWR 進程講redo log buffer 寫入redo log 中發生。如果此類事件頻繁發生，可以判斷為：
■commit 次數是否過多
■I/O 系統問題
■重做日志是否不必要被創建
■redo log buffer 是否過大
2-1 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 name
Statistic Name Time (s) % of DB Time
------------------------------------------ ------------------ ------------
sql execute elapsed time 805,159.7 91.1
sequence load elapsed time 41,159.2 4.7
DB CPU 20,649.1 2.3
parse time elapsed 1,112.8 .1
hard parse elapsed time 995.2 .1
hard parse (sharing criteria) elapsed time 237.3 .0
hard parse (bind mismatch) elapsed time 227.6 .0
connection management call elapsed time 29.7 .0
PL/SQL execution elapsed time 9.2 .0
PL/SQL compilation elapsed time 6.6 .0
failed parse elapsed time 2.0 .0
repeated bind elapsed time 0.4 .0
DB time 883,542.2
background elapsed time 25,439.0
background cpu time 1,980.9
-------------------------------------------------------------
Time Model Statistics幾個特別有用的時間指標：
■parse time elapsed、hard parse elapsed time 結合起來看解析是否是主要矛盾，若是則重點是軟解析還是硬解析
■sequence load elapsed time sequence序列爭用是否是問題焦點
■PL/SQL compilation elapsed time PL/SQL對象編譯的耗時
■注意PL/SQL execution elapsed time 純耗費在PL/SQL解釋器上的時間。不包括花在執行和解析其包含SQL上的時間
■connection management call elapsed time 建立數據庫session連接和斷開的耗時
■failed parse elapsed time 解析失敗，例如由於ORA-4031
■hard parse (sharing criteria) elapsed time 由於無法共享游標造成的硬解析
■hard parse (bind mismatch) elapsed time 由於bind type or bind size 不一致造成的硬解析
注意該時間模型中的指標存在包含關系所以Time Model Statistics加起來超過100%再正常不過
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 time
2-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 wait
Wait Class Waits -outs Time (s) (ms) %DB time
-------------------- ---------------- ----- ---------------- -------- ---------
Cluster 9,825,884 1 525,134 53 59.4
Concurrency 688,375 0 113,782 165 12.9
User I/O 34,405,042 0 76,695 2 8.7
Commit 172,193 0 62,776 365 7.1
Application 11,422 0 57,760 5057 6.5
Configuration 19,418 1 48,889 2518 5.5
DB CPU 20,649 2.3
Other 1,757,896 94 924 1 0.1
System I/O 30,165 0 598 20 0.1
Network 171,955,673 0 400 0 0.0
Administrative 2 100 0 101 0.0
-------------------------------------------------------------
select distinct wait_class from v$event_name;
WAIT_CLASS
----------------------------------------------------------------
Concurrency
User I/O
System I/O
Administrative
Other
Configuration
Scheduler
Cluster
Application
Queueing
Idle
Network
Commit
■Wait Class: 等待事件的類型，如上查詢所示，被分作12個類型。 10.2.0.5有916個等待事件，其中Other類型占622個。
■Waits: 該類型所屬等待事件在快照時間內的等待次數
■%Time Out 等待超時的比率， 未 超時次數/waits * 100 (%)
■Total Wait Time: 該類型所屬等待事件總的耗時，單位為秒
■Avg Wait(ms) : 該類型所屬等待事件的平均單次等待時間，單位為ms ，實際這個指標對commit 和 user i/o 以及system i/o類型有點意義，其他等待類型由於等待事件差異較大所以看平均值的意義較小
■waits / txn: 該類型所屬等待事件的等待次數和事務比
Other 類型，遇到該類型等待事件 的話 常見的原因是Oracle Bug或者 網絡、I/O存在問題， 一般推薦聯系Maclean。
Concurrency 類型 並行爭用類型的等待事件， 典型的如 latch: shared pool、latch: library cache、row cache lock、library cache pin/lock
Cluster 類型 為Real Application Cluster RAC環境中的等待事件， 需要注意的是 如果啟用了RAC option，那么即使你的集群中只啟動了一個實例，那么該實例也可能遇到 Cluster類型的等待事件, 例如gc buffer busy
System I/O 主要是后台進程維護數據庫所產生的I/O，例如control file parallel write 、log file parallel write、db file parallel write。
User I/O 主要是前台進程做了一些I/O操作，並不是說后台進程不會有這些等待事件。 典型的如db file sequential/scattered read、direct path read
Configuration 由於配置引起的等待事件， 例如 日志切換的log file switch completion (日志文件 大小/數目 不夠)，sequence的enq: SQ – contention (Sequence 使用nocache) ； Oracle認為它們是由於配置不當引起的，但實際未必真是這樣的配置引起的。
Application 應用造成的等待事件， 例如enq: TM – contention和enq: TX – row lock contention； Oracle認為這是由於應用設計不當造成的等待事件， 但實際這些Application class 等待可能受到 Concurrency、Cluster、System I/O 、User I/O等多種類型等待的影響，例如本來commit只要1ms ，則某一行數據僅被鎖定1ms， 但由於commit變慢 從而釋放行鎖變慢，引發大量的enq: TX – row lock contention等待事件。
Commit 僅log file sync ，log file sync的影響十分廣泛，值得我們深入討論。
Network : 網絡類型的等待事件 例如 SQL*Net more data to client 、SQL*Net more data to dblink
Idle 空閑等待事件 ，最為常見的是rdbms ipc message (等待實例內部的ipc通信才干活，即別人告知我有活干，我才干，否則我休息==》Idle)， SQL*Net message from client(等待SQL*NET傳來信息，否則目前沒事干)
2-3 前台等待事件
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 % DB
Event Waits -outs Time (s) (ms) /txn time
-------------------------- ------------ ----- ---------- ------- -------- ------
gc buffer busy acquire 3,274,352 3 303,088 93 13.3 34.3
gc buffer busy release 387,673 2 128,114 330 1.6 14.5
enq: TX - index contention 193,918 0 97,375 502 0.8 11.0
cell single block physical 30,738,730 0 63,606 2 124.8 7.2
log file sync 172,193 0 62,776 365 0.7 7.1
gc current block busy 146,154 0 53,027 363 0.6 6.0
enq: TM - contention 1,060 0 47,228 44555 0.0 5.3
enq: SQ - contention 17,431 0 35,683 2047 0.1 4.0
gc cr block busy 105,204 0 33,746 321 0.4 3.8
buffer busy waits 279,721 0 12,646 45 1.1 1.4
enq: HW - contention 1,201 3 12,192 10151 0.0 1.4
enq: TX - row lock content 9,231 0 10,482 1135 0.0 1.2
cell multiblock physical r 247,903 0 6,547 26 1.0 .7
Foreground Wait Events 前台等待事件，數據主要來源於DBA_HIST_SYSTEM_EVENT
Event 等待事件名字
Waits 該等待事件在快照時間內等待的次數
%Timeouts : 每一個等待事件有其超時的設置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件 單次等待達到timeout的時間，則會進入下一次該等待事件
Total Wait Time 該等待事件 總的消耗的時間 ，單位為秒
Avg wait(ms): 該等待事件的單次平均等待時間，單位為毫秒
Waits/Txn: 該等待事件的等待次數和事務比
2-4 后台等待事件
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 % bg
Event Waits -outs Time (s) (ms) /txn time
-------------------------- ------------ ----- ---------- ------- -------- ------
db file parallel write 90,979 0 7,831 86 0.4 30.8
gcs log flush sync 4,756,076 6 4,714 1 19.3 18.5
enq: CF - contention 2,123 40 4,038 1902 0.0 15.9
control file sequential re 90,227 0 2,380 26 0.4 9.4
log file parallel write 108,383 0 1,723 16 0.4 6.8
control file parallel writ 4,812 0 988 205 0.0 3.9
Disk file operations I/O 26,216 0 731 28 0.1 2.9
flashback log file write 9,870 0 720 73 0.0 2.8
LNS wait on SENDREQ 202,747 0 600 3 0.8 2.4
ASM file metadata operatio 15,801 0 344 22 0.1 1.4
cell single block physical 39,283 0 341 9 0.2 1.3
LGWR-LNS wait on channel 183,443 18 203 1 0.7 .8
gc current block busy 122 0 132 1082 0.0 .5
gc buffer busy release 60 12 127 2113 0.0 .5
Parameter File I/O 592 0 116 195 0.0 .5
log file sequential read 1,804 0 104 58 0.0 .4
Background Wait Events 后台等待事件， 數據主要來源於DBA_HIST_BG_EVENT_SUMMARY
Event 等待事件名字
Waits 該等待事件在快照時間內等待的次數
%Timeouts : 每一個等待事件有其超時的設置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件 單次等待達到timeout的時間，則會進入下一次該等待事件
Total Wait Time 該等待事件 總的消耗的時間 ，單位為秒
Avg wait(ms): 該等待事件的單次平均等待時間，單位為毫秒
Waits/Txn: 該等待事件的等待次數和事務比
2-5 Operating System Statistics
Operating System Statistics Snaps: 70719-70723
TIME 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), Name
Statistic Value End Value
------------------------- ---------------------- ----------------
BUSY_TIME 2,894,855
IDLE_TIME 5,568,240
IOWAIT_TIME 18,973
SYS_TIME 602,532
USER_TIME 2,090,082
LOAD 8 13
VM_IN_BYTES 0
VM_OUT_BYTES 0
PHYSICAL_MEMORY_BYTES 101,221,343,232
NUM_CPUS 24
NUM_CPU_CORES 12
NUM_CPU_SOCKETS 2
GLOBAL_RECEIVE_SIZE_MAX 4,194,304
GLOBAL_SEND_SIZE_MAX 2,097,152
TCP_RECEIVE_SIZE_DEFAULT 87,380
TCP_RECEIVE_SIZE_MAX 4,194,304
TCP_RECEIVE_SIZE_MIN 4,096
TCP_SEND_SIZE_DEFAULT 16,384
TCP_SEND_SIZE_MAX 4,194,304
TCP_SEND_SIZE_MIN 4,096
-------------------------------------------------------------
Operating System Statistics 操作系統統計信息
數據來源於V$OSSTAT / DBA_HIST_OSSTAT，, TIME相關的指標單位均為百分之一秒
統計項 描述
NUM_CPU_SOCKETS 物理CPU的數目
NUM_CPU_CORES CPU的核數
NUM_CPUS 邏輯CPU的數目
SYS_TIME 在內核態被消耗掉的CPU時間片，單位為百分之一秒
USER_TIME 在用戶態被消耗掉的CPU時間片，單位為百分之一秒
BUSY_TIME Busy_Time=SYS_TIME+USER_TIME 消耗的CPU時間片，單位為百分之一秒
AVG_BUSY_TIME AVG_BUSY_TIME= BUSY_TIME/NUM_CPUS
IDLE_TIME 空閑的CPU時間片，單位為百分之一秒
所有CPU所能提供總的時間片 BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
OS_CPU_WAIT_TIME 進程等OS調度的時間，cpu queuing
VM_IN_BYTES 換入頁的字節數
VM_OUT_BYTES 換出頁的字節數，部分版本下並不准確，例如Bug 11712010 Abstract: VIRTUAL MEMORY PAGING ON 11.2.0.2 DATABASES，僅供參考
IOWAIT_TIME 所有CPU花費在等待I/O完成上的時間 單位為百分之一秒
RSRC_MGR_CPU_WAIT_TIME 是指當resource manager控制CPU調度時，需要控制對應進程暫時不使用CPU而進程到內部運行隊列中，以保證該進程對應的consumer group(消費組)沒有消耗比指定resource manager指令更多的CPU。RSRC_MGR_CPU_WAIT_TIME指等在內部運行隊列上的時間，在等待時不消耗CPU
2-6 Service Statistcs
Service Statistics Snaps: 70719-70723
-> ordered by DB Time
Physical Logical
Service Name DB Time (s) DB CPU (s) Reads (K) Reads (K)
---------------------------- ------------ ------------ ------------ ------------
itms-contentmasterdb-prod 897,099 20,618 35,668 1,958,580
SYS$USERS 4,312 189 5,957 13,333
itmscmp 1,941 121 14,949 18,187
itscmp 331 20 114 218
itscmp_dgmgrl 121 1 0 0
SYS$BACKGROUND 0 0 142 30,022
ITSCMP1_PR 0 0 0 0
its-reference-prod 0 0 0 0
itscmpXDB 0 0 0 0
按照Service Name來分組時間模型和 物理、邏輯讀取， 部分數據來源於 WRH$_SERVICE_NAME;
Service Name 對應的服務名 (v$services)， SYS$BACKGROUND代表后台進程， SYS$USERS一般是系統用戶登錄
DB TIME (s): 本服務名所消耗的DB TIME時間，單位為秒
DB CPU(s): 本服務名所消耗的DB CPU 時間，單位為秒
Physical Reads : 本服務名所消耗的物理讀
Logical Reads : 本服務所消耗的邏輯讀
2-7 Service Wait Class Stats
Service Wait Class Stats Snaps: 70719-70723
-> Wait Class info 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 seconds
Service Name
----------------------------------------------------------------
User I/O User I/O Concurcy Concurcy Admin Admin Network Network
Total 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 127
SYS$USERS
173233 3656 6738 30 2 0 72674 3
itmscmp
676773 1319 1831 0 0 0 2216 0
itscmp
219577 236 1093 0 0 0 18112 0
itscmp_dgmgrl
34 0 8 0 0 0 9 0
SYS$BACKGROUND
71940 1300 320677 56 0 0 442252 872
-------------------------------------------------------------
■User I/O Total Wts : 對應該服務名下 用戶I/O類等待的總的次數
■User I/O Wt Time : 對應該服務名下 用戶I/O累等待的總時間，單位為 1/100秒
■Concurcy Total Wts: 對應該服務名下 Concurrency 類型等待的總次數
■Concurcy Wt Time :對應該服務名下 Concurrency 類型等待的總時間， 單位為 1/100秒
■Admin Total Wts: 對應該服務名下Admin 類等待的總次數
■Admin Wt Time: 對應該服務名下Admin類等待的總時間，單位為 1/100秒
■Network Total Wts : 對應服務名下Network類等待的總次數
■Network Wt Time： 對應服務名下Network類等待的總事件， 單位為 1/100秒
2-8 Host CPU
Host CPU (CPUs: 24 Cores: 12 Sockets: 2)
~~~~~~~~ Load Average
Begin End %User %System %WIO %Idle
--------- --------- --------- --------- --------- ---------
8.41 12.84 24.7 7.1 0.2 65.8
“Load Average” begin/end值代表每個CPU的大致運行隊列大小。上例中快照開始到結束，平均 CPU負載增加了；與《2-5 Operating System Statistics》中的LOAD相呼應。
%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,該實例所使用的CPU占總CPU的比例 % of total CPU for Instance
%Busy CPU，該實例所使用的Cpu占總的被使用CPU的比例 % of busy CPU for Instance
例如共4個邏輯CPU，其中3個被完全使用，3個中的1個完全被該實例使用，則%Total CPU= ? =25%，而%Busy CPU= 1/3= 33%
當CPU高時一般看%Busy CPU可以確定CPU到底是否是本實例消耗的，還是主機上其他程序
% 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
【性能調優】Oracle AWR報告指標全解析
2013/08/31 by Maclean Liu 暫無評論
【性能調優】Oracle AWR報告指標全解析
開Oracle調優鷹眼，深入理解AWR性能報告：http://www.askmaclean.com/archives/awr-hawk-eyes-training.html
開Oracle調優鷹眼，深入理解AWR性能報告 第二講： http://www.askmaclean.com/archives/awr-tuning-hawk-eyes.html
如果自己搞不定可以找詩檀軟件專業ORACLE數據庫修復團隊成員幫您恢復!
詩檀軟件專業數據庫修復團隊
服務熱線 ： 13764045638 QQ號:47079569 郵箱：service@parnassusdata.com
有同學在看過《Oracle調優鷹眼，深入理解AWR性能報告》的教學視頻后急切期待第三講，但實際是第三講需要結合大量的原理知識才能充分理解 例如Latch activity 、Undo、Dynamic Resource Master均需要理解其原理才能充分理解。 所以這些AWR的環節將在 Maclean 今后的 系列調優講座中介紹。 對於《Oracle調優鷹眼系列》 則會增加本附錄，作為對全部Oracle AWR指標的介紹， 本附錄對於原理理解方面的內容將不多，而更側重於指標含義的介紹，是對AWR鷹眼講座的工具文檔。
如果你覺得本AWR解析中的哪些指標仍理解不透徹 或者講的不清楚的，可以在本頁中留言，謝謝大家的支持。
Hawk Eyes 看AWR的鷹眼= 基礎理論夯實+看過500份以上AWR
啥是AWR?
=====================================================================================================
AWR (Automatic Workload Repository)
一堆歷史性能數據，放在SYSAUX表空間上， AWR和SYSAUX都是10g出現的，是Oracle調優的關鍵特性； 大約1999年左右開始開發，已經有15年歷史
默認快照間隔1小時，10g保存7天、11g保存8天; 可以通過DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS修改
DBA_HIST_WR_CONTROL
AWR程序核心是dbms_workload_repository包
@?/rdbms/admin/awrrpt 本實例
@?/rdbms/admin/awrrpti RAC中選擇實例號
誰維護AWR?
主要是MMON(Manageability Monitor Process)和它的小工進程(m00x)
MMON的功能包括:
1.啟動slave進程m00x去做AWR快照
2.當某個度量閥值被超過時發出alert告警
3.為最近改變過的SQL對象捕獲指標信息
AWR小技巧
手動執行一個快照：
Exec dbms_workload_repository.create_snapshot; (這個要背出來哦，用的時候去翻手冊，丟臉哦 J!)
創建一個AWR基線
Exec DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id，end_snap_id ,baseline_name);
@?/rdbms/admin/awrddrpt AWR比對報告
@?/rdbms/admin/awrgrpt RAC 全局AWR
自動生成AWR HTML報告：
http://www.oracle-base.com/dba/10g/generate_multiple_awr_reports.sql
1、報告總結
WORKLOAD REPOSITORY report for
DB Name DB Id Instance Inst Num Startup Time Release RAC
------------ ----------- ------------ -------- --------------- ----------- ---
MAC 2629627371 askmaclean.com 1 22-Jan-13 16:49 11.2.0.3.0 YES
Host Name Platform CPUs Cores Sockets Memory(GB)
---------------- -------------------------------- ---- ----- ------- ----------
MAC10 AIX-Based Systems (64-bit) 128 32 320.00
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 5853 23-Jan-13 15:00:56 3,520 1.8
End Snap: 5854 23-Jan-13 15:30:41 3,765 1.9
Elapsed: 29.75 (mins)
DB Time: 7,633.76 (mins)
Elapsed 為該AWR性能報告的時間跨度(自然時間的跨度，例如前一個快照snapshot是4點生成的，后一個快照snapshot是6點生成的，則若使用@?/rdbms/admin/awrrpt 腳本中指定這2個快照的話，那么其elapsed = (6-4)=2 個小時)，一個AWR性能報告 至少需要2個AWR snapshot性能快照才能生成 ( 注意這2個快照時間 實例不能重啟過，否則指定這2個快照生成AWR性能報告 會報錯)，AWR性能報告中的 指標往往是 后一個快照和前一個快照的 指標的delta，這是因為 累計值並不能反映某段時間內的系統workload。
DB TIME= 所有前台session花費在database調用上的總和時間：
■注意是前台進程foreground sessions
■包括CPU時間、IO Time、和其他一系列非空閑等待時間，別忘了cpu on queue time
DB TIME 不等於 響應時間，DB TIME高了未必響應慢，DB TIME低了未必響應快
DB Time描繪了數據庫總體負載，但要和elapsed time逝去時間結合其他來。
Average Active Session AAS= DB time/Elapsed Time
DB Time =60 min ， Elapsed Time =60 min AAS=60/60=1 負載一般
DB Time= 1min , Elapsed Time= 60 min AAS= 1/60 負載很輕
DB Time= 60000 min，Elapsed Time= 60 min AAS=1000 系統hang了吧？
DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue
如果僅有2個邏輯CPU，而2個session在60分鍾都沒等待事件，一直跑在CPU上，那么：
DB CPU= 2 * 60 mins ， DB Time = 2* 60 + 0 + 0 =120
AAS = 120/60=2 正好等於OS load 2。
如果有3個session都100%僅消耗CPU，那么總有一個要wait on queue
DB CPU = 2* 60 mins ，wait on CPU queue= 60 mins
AAS= (120+ 60)/60=3 主機load 亦為3，此時vmstat 看waiting for run time
真實世界中？ DB Cpu = xx mins ， Non-Idle Wait= enq:TX + cursor pin S on X + latch : xxx + db file sequential read + ……….. 阿貓阿狗
1-1 內存參數大小
Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 49,152M 49,152M Std Block Size: 8K
Shared Pool Size: 13,312M 13,312M Log Buffer: 334,848K
內存管理方式：MSMM、ASMM(sga_target)、AMM(memory_target)
小內存有小內存的問題， 大內存有大內存的麻煩！ ORA-04031???!!
Buffer cache和shared pool size的 begin/end值在ASMM、AMM和11gR2 MSMM下可是會動的哦！
這里說 shared pool一直收縮，則在shrink過程中一些row cache 對象被lock住可能導致前台row cache lock等解析等待，最好別讓shared pool shrink。如果這里shared pool一直在grow，那說明shared pool原有大小不足以滿足需求(可能是大量硬解析)，結合下文的解析信息和SGA breakdown來一起診斷問題。
1-2 Load Profile
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ --------------- --------------- ---------- ----------
DB Time(s): 256.6 0.2 0.07 0.03
DB CPU(s): 3.7 0.0 0.00 0.00
Redo size: 1,020,943.0 826.5
Logical reads: 196,888.0 159.4
Block changes: 6,339.4 5.1
Physical reads: 5,076.7 4.1
Physical writes: 379.2 0.3
User calls: 10,157.4 8.2
Parses: 204.0 0.2
Hard parses: 0.9 0.0
W/A MB processed: 5.0 0.0
Logons: 1.7 0.0
Executes: 3,936.6 3.2
Rollbacks: 1,126.3 0.9
Transactions: 1,235.3
% Blocks changed per Read: 53.49 Recursive Call %: 98.04
Rollback per transaction %: 36.57 Rows per Sort: 73.70
指標 指標含義
redo size 單位 bytes，redo size可以用來估量update/insert/delete的頻率，大的redo size往往對lgwr寫日志，和arch歸檔造成I/O壓力， Per Transaction可以用來分辨是 大量小事務， 還是少量大事務。如上例每秒redo 約1MB ，每個事務800 字節，符合OLTP特征
Logical Read 單位 次數*塊數， 相當於 “人*次”， 如上例 196,888 * db_block_size=1538MB/s ， 邏輯讀耗CPU，主頻和CPU核數都很重要，邏輯讀高則DB CPU往往高，也往往可以看到latch: cache buffer chains等待。 大量OLTP系統(例如siebel)可以高達幾十乃至上百Gbytes。
Block changes 單位 次數*塊數 ， 描繪數據變化頻率
Physical Read 單位次數*塊數， 如上例 5076 * 8k = 39MB/s， 物理讀消耗IO讀，體現在IOPS和吞吐量等不同緯度上；但減少物理讀可能意味着消耗更多CPU。好的存儲 每秒物理讀能力達到幾GB，例如Exadata。 這個physical read包含了physical reads cache和physical reads direct
Physical writes 單位 次數*塊數，主要是DBWR寫datafile，也有direct path write。 dbwr長期寫出慢會導致定期log file switch(checkpoint no complete) 檢查點無法完成的前台等待。 這個physical write 包含了physical writes direct +physical writes from cache
User Calls 單位次數，用戶調用數，more details from internal
Parses 解析次數，包括軟解析+硬解析，軟解析優化得不好，則誇張地說幾乎等於每秒SQL執行次數。 即執行解析比1:1，而我們希望的是 解析一次 到處運行哦！
Hard Parses 萬惡之源． 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中處理的數據數量
結合 In-memory Sort%， sorts (disk) PGA Aggr一起看
Logons 登陸次數， logon storm 登陸風暴，結合AUDIT審計數據一起看。短連接的附帶效應是游標緩存無用
Executes 執行次數，反應執行頻率
Rollback 回滾次數， 反應回滾頻率， 但是這個指標不太精確，參考而已，別太當真
Transactions 每秒事務數，是數據庫層的TPS，可以看做壓力測試或比對性能時的一個指標，孤立看無意義
% Blocks changed per Read 每次邏輯讀導致數據塊變化的比率；如果’redo size’, ‘block changes’ ‘pct of blocks changed per read’三個指標都很高，則說明系統正執行大量insert/update/delete;
pct of blocks changed per read = (block changes ) /( logical reads)
Recursive Call % 遞歸調用的比率;Recursive Call % = (recursive calls)/(user calls)
Rollback per transaction % 事務回滾比率。 Rollback per transaction %= (rollback)/(transactions)
Rows per Sort 平均每次排序涉及到的行數 ; Rows per Sort= ( sorts(rows) ) / ( sorts(disk) + sorts(memory))
注意這些Load Profile 負載指標 在本環節提供了 2個維度 per second 和 per transaction。
per Second: 主要是把 快照內的delta值除以 快站時間的秒數 ， 例如 在 A快照中V$SYSSTAT視圖反應 table scans (long tables) 這個指標是 100 ，在B快照中V$SYSSTAT視圖反應 table scans (long tables) 這個指標是 3700, 而A快照和B快照 之間 間隔了一個小時 3600秒， 則 對於 table scans (long tables) per second 就是 ( 3700- 100) /3600=1。
pert Second是我們審視數據的主要維度 ，任何性能數據脫離了 時間模型則毫無意義。
在statspack/AWR出現之前 的調優 洪荒時代， 有很多DBA 依賴 V$SYSSTAT等視圖中的累計 統計信息來調優，以當前的調優眼光來看，那無異於刀耕火種。
per transaction : 基於事務的維度， 與per second相比 是把除數從時間的秒數改為了該段時間內的事務數。 這個維度的很大用戶是用來 識別應用特性的變化 ，若2個AWR性能報告中該維度指標 出現了大幅變化，例如 redo size從本來per transaction 1k變化為 10k per transaction，則說明SQL業務邏輯肯定發生了某些變化。
注意AWR中的這些指標 並不僅僅用來孤立地了解 Oracle數據庫負載情況， 實施調優工作。 對於 故障診斷 例如HANG、Crash等， 完全可以通過對比問題時段的性能報告和常規時間來對比，通過各項指標的對比往往可以找出 病灶所在。
SELECT VALUE FROM DBA_HIST_SYSSTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND STAT_NAME in ( "db block changes","user calls","user rollbacks","user commits",redo size","physical reads direct","physical writes","parse count (hard)","parse count (total)","session logical reads","recursive calls","redo log space requests","redo entries","sorts (memory)","sorts (disk)","sorts (rows)","logons cumulative","parse time cpu","parse time elapsed","execute count","logons current","opened cursors current","DBWR fusion writes","gcs messages sent","ges messages sent","global enqueue gets sync","global enqueue get time","gc cr blocks received","gc cr block receive time","gc current blocks received","gc current block receive time","gc cr blocks served","gc cr block build time","gc cr block flush time","gc cr block send time","gc current blocks served","gc current block pin time","gc current block flush time","gc current block send time","physical reads","physical reads direct (lob)",
SELECT TOTAL_WAITS FROM DBA_HIST_SYSTEM_EVENT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND EVENT_NAME in ("gc buffer busy","buffer busy waits"
SELECT VALUE FROM DBA_HIST_SYS_TIME_MODEL WHERE DBID = :B4 AND SNAP_ID = :B3 AND INSTANCE_NUMBER = :B2 AND STAT_NAME in ("DB CPU","sql execute elapsed time","DB time"
SELECT VALUE FROM DBA_HIST_PARAMETER WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND PARAMETER_NAME in ("__db_cache_size","__shared_pool_size","sga_target","pga_aggregate_target","undo_management","db_block_size","log_buffer","timed_statistics","statistics_level"
SELECT BYTES FROM DBA_HIST_SGASTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND POOL IN ('shared pool', 'all pools') AND NAME in ("free memory",
SELECT BYTES FROM DBA_HIST_SGASTAT WHERE SNAP_ID = :B4 AND DBID = :B3 AND INSTANCE_NUMBER = :B2 AND NAME = :B1 AND POOL IS NULL
SELECT (E.BYTES_PROCESSED - B.BYTES_PROCESSED) FROM DBA_HIST_PGA_TARGET_ADVICE B, DBA_HIST_PGA_TARGET_ADVICE E WHERE B.DBID = :B4 AND B.SNAP_ID = :B3 AND B.INSTANCE_NUM
BER = :B2 AND B.ADVICE_STATUS = 'ON' AND E.DBID = B.DBID AND E.SNAP_ID = :B1 AND E.INSTANCE_NUMBER = B.INSTANCE_NUMBER AND E.PGA_TARGET_FACTOR = 1 AND B.PGA_TARGET_FACT
OR = 1 AND E.ADVICE_STATUS = 'ON'
SELECT SUM(E.TOTAL_WAITS - NVL(B.TOTAL_WAITS, 0)) FROM DBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT E WHERE B.SNAP_ID(+) = :B4 AND E.SNAP_ID = :B3 AND B.DBID(+) = :B2
AND E.DBID = :B2 AND B.INSTANCE_NUMBER(+) = :B1 AND E.INSTANCE_NUMBER = :B1 AND B.EVENT_ID(+) = E.EVENT_ID AND (E.EVENT_NAME = 'latch free' OR E.EVENT_NAME LIKE 'latch
:%')
SELECT DECODE(B.TOTAL_SQL, 0, 0, 100*(1-B.SINGLE_USE_SQL/B.TOTAL_SQL)), DECODE(E.TOTAL_SQL, 0, 0, 100*(1-E.SINGLE_USE_SQL/E.TOTAL_SQL)), DECODE(B.TOTAL_SQL_MEM, 0, 0, 1
00*(1-B.SINGLE_USE_SQL_MEM/B.TOTAL_SQL_MEM)), DECODE(E.TOTAL_SQL_MEM, 0, 0, 100*(1-E.SINGLE_USE_SQL_MEM/E.TOTAL_SQL_MEM)) FROM DBA_HIST_SQL_SUMMARY B, DBA_HIST_SQL_SUMM
ARY E WHERE B.SNAP_ID = :B4 AND E.SNAP_ID = :B3 AND B.INSTANCE_NUMBER = :B2 AND E.INSTANCE_NUMBER = :B2 AND B.DBID = :B1 AND E.DBID = :B1
SELECT EVENT, WAITS, TIME, DECODE(WAITS, NULL, TO_NUMBER(NULL), 0, TO_NUMBER(NULL), TIME/WAITS*1000) AVGWT, PCTWTT, WAIT_CLASS FROM (SELECT EVENT, WAITS, TIME, PCTWTT,
WAIT_CLASS FROM (SELECT E.EVENT_NAME EVENT, E.TOTAL_WAITS - NVL(B.TOTAL_WAITS,0) WAITS, (E.TIME_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0)) / 1000000 TIME, 100 * (E.TIME
_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0)) / :B1 PCTWTT, E.WAIT_CLASS WAIT_CLASS FROM DBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT E WHERE B.SNAP_ID(+) = :B5 AND E.S
NAP_ID = :B4 AND B.DBID(+) = :B3 AND E.DBID = :B3 AND B.INSTANCE_NUMBER(+) = :B2 AND E.INSTANCE_NUMBER = :B2 AND B.EVENT_ID(+) = E.EVENT_ID AND E.TOTAL_WAITS > NVL(B.TO
TAL_WAITS,0) AND E.WAIT_CLASS != 'Idle' UNION ALL SELECT 'CPU time' EVENT, TO_NUMBER(NULL) WAITS, :B6 /1000000 TIME, 100 * :B6 / :B1 PCTWTT, NULL WAIT_CLASS FROM DUAL W
HERE :B6 > 0) ORDER BY TIME DESC, WAITS DESC) WHERE ROWNUM <= :B7
SELECT SUM(E.TIME_WAITED_MICRO - NVL(B.TIME_WAITED_MICRO,0)) FROM DBA_HIST_SYSTEM_EVENT B, DBA_HIST_SYSTEM_EVENT E WHERE B.SNAP_ID(+) = :B4 AND E.SNAP_ID = :B3 AND B.DB
ID(+) = :B2 AND E.DBID = :B2 AND B.INSTANCE_NUMBER(+) = :B1 AND E.INSTANCE_NUMBER = :B1 AND B.EVENT_ID(+) = E.EVENT_ID AND E.WAIT_CLASS = 'User I/O'
SELECT (E.ESTD_LC_TIME_SAVED - B.ESTD_LC_TIME_SAVED) FROM DBA_HIST_SHARED_POOL_ADVICE B, DBA_HIST_SHARED_POOL_ADVICE E WHERE B.DBID = :B3 AND B.INSTANCE_NUMBER = :B2 AN
D B.SNAP_ID = :B4 AND E.DBID = :B3 AND E.INSTANCE_NUMBER = :B2 AND E.SNAP_ID = :B1 AND E.SHARED_POOL_SIZE_FACTOR = 1 AND B.SHARED_POOL_SIZE_FACTOR = 1
1-3 Instance Efficiency Percentages (Target 100%)
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.97 Redo NoWait %: 100.00
Buffer Hit %: 97.43 In-memory Sort %: 100.00
Library Hit %: 99.88 Soft Parse %: 99.58
Execute to Parse %: 94.82 Latch Hit %: 99.95
Parse CPU to Parse Elapsd %: 1.75 % Non-Parse CPU: 99.85
上述所有指標 的目標均為100%，即越大越好，在少數bug情況下可能超過100%或者為負值。
■80%以上 %Non-Parse CPU
■90%以上 Buffer Hit%, In-memory Sort%, Soft Parse%
■95%以上 Library Hit%, Redo Nowait%, Buffer Nowait%
■98%以上 Latch Hit%
1、 Buffer Nowait % session申請一個buffer(兼容模式)不等待的次數比例。 需要訪問buffer時立即可以訪問的比率， 不兼容的情況 在9i中是 buffer busy waits，從10g以后 buffer busy waits 分離為 buffer busy wait 和 read by other session2個等待事件 :
9i 中 waitstat的總次數基本等於buffer busy waits等待事件的次數
SQL> select sum(TOTAL_WAITS) from v$system_event where event='buffer busy waits';
SUM(TOTAL_WAITS)
—————-
33070394
SQL> select sum(count) from v$waitstat;
SUM(COUNT)
———-
33069335
10g waitstat的總次數基本等於 buffer busy waits 和 read by other session 等待的次數總和
SQL> select sum(TOTAL_WAITS) from v$system_event where event='buffer busy waits' or event='read by other session';
SUM(TOTAL_WAITS)
—————-
60675815
SQL> select sum(count) from v$waitstat;
SUM(COUNT)
———-
60423739
Buffer Nowait %的計算公式是 sum(v$waitstat.wait_count) / (v$sysstat statistic session logical reads)，例如在AWR中：
Class Waits Total Wait Time (s) Avg Time (ms)
data block 24,543 2,267 92
undo header 743 2 3
undo block 1,116 0 0
1st level bmb 35 0 0
session logical reads 40,769,800 22,544.84 204.71
Buffer Nowait %: 99.94
Buffer Nowait= ( 40,769,800 – (24543+743+1116+35))/ ( 40,769,800) = 0.99935= 99.94%
SELECT SUM(WAIT_COUNT) FROM DBA_HIST_WAITSTAT WHERE SNAP_ID = :B3 AND DBID = :B2 AND INSTANCE_NUMBER = :B1
2、buffer HIT%: 經典的經典，高速緩存命中率，反應物理讀和緩存命中間的糾結，但這個指標即便99% 也不能說明物理讀等待少了
不合理的db_cache_size，或者是SGA自動管理ASMM /Memory 自動管理AMM下都可能因為db_cache_size過小引起大量的db file sequential /scattered read等待事件； maclean曾經遇到過因為大量硬解析導致ASMM 下shared pool共享池大幅度膨脹，而db cache相應縮小shrink的例子，最終db cache收縮到只有幾百兆，本來沒有的物理讀等待事件都大幅涌現出來 。
此外與 buffer HIT%相關的指標值得關注的還有 table scans(long tables) 大表掃描這個統計項目、此外相關的欄目還有Buffer Pool Statistics 、Buffer Pool Advisory等（如果不知道在哪里，直接找一個AWR 去搜索這些關鍵詞即可)。
buffer HIT%在 不同版本有多個計算公式：
在9i中
Buffer Hit Ratio = 1 – ((physical reads – physical reads direct – physical reads direct (lob)) / (db block gets + consistent gets – physical reads direct – physical reads direct (lob))
在10g以后：
Buffer Hit Ratio= 1 – ((‘physical reads cache’) / (‘consistent gets from cache’ + ‘db block gets from cache’)
注意：但是實際AWR中 似乎還是按照9i中的算法，雖然算法的區別對最后算得的比率影響不大。
對於buffer hit % 看它的命中率有多高沒有意義，主要是關注 未命中的次數有多少。通過上述公式很容易反推出未命中的物理讀的次數。
db block gets 、consistent gets 以及 session logical reads的關系如下：
db block gets＝db block gets direct＋ db block gets from cache
consistent gets ＝ consistent gets from cache＋ consistent gets direct
consistent gets from cache＝ consistent gets – examination + else
consistent gets – examination==>指的是不需要pin buffer直接可以執行consistent get的次數，常用於索引，只需要一次latch get
session logical reads = db block gets +consistent gets
其中physical reads 、physical reads cache、physical reads direct、physical reads direct (lob)幾者的關系為：
physical reads = physical reads cache + physical reads direct
這個公式其實說明了 物理讀有2種 ：
■物理讀進入buffer cache中 ，是常見的模式 physical reads cache
■物理讀直接進入PGA 直接路徑讀， 即physical reads direct
physical reads 8 Total number 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 cache 8 Total number of data blocks read from disk into the buffer cache. This is a subset of “physical reads” statistic.
physical reads direct 8 Number 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(普通)
這個公式也說明了 直接路徑讀 分成三個部分：
■physical reads direct (lob) 直接路徑讀LOB對象
■physical reads direct temporary tablespace 直接路徑讀臨時表空間
■physical read direct(普通) 普通的直接路徑讀， 一般是11g開始的自動的大表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時不用等待的比例，redo相關的資源爭用例如redo space request爭用可能造成生成redo時需求等待。此項數據來源於v$sysstat中的(redo log space requests/redo entries)。 一般來說10g以后不太用關注log_buffer參數的大小，需要關注是否有十分頻繁的 log switch ； 過小的redo logfile size 如果配合較大的SGA和頻繁的commit提交都可能造成該問題。 考慮增到redo logfile 的尺寸 : 1~4G 每個，7~10組都是合適的。同時考慮優化redo logfile和datafile 的I/O。
4、In-memory Sort%:這個指標因為它不計算workarea中所有的操作類型，所以現在越來越雞肋了。 純粹在內存中完成的排序比例。數據來源於v$sysstat statistics sorts (disk) 和 sorts (memory)， In-memory Sort% = sort(memory) / ( sort(disk)+ sort(memory) )
5、
Library Hit%: library cache命中率，申請一個library cache object例如一個SQL cursor時，其已經在library cache中的比例。 數據來源 V$librarycache的pins和pinhits。 合理值：>95% ，該比例來源於1- ( Σ(pin Requests * Pct Miss) / Sum(Pin Requests) )
維護這個指標的重點是 保持shared pool共享池有足夠的Free Memory，且沒有過多的內存碎片，具體可以參考這里。 顯然過小的shared pool可用空間會導致library cache object被aged out換出共享池。
此外保證SQL語句綁定變量和游標可以共享也是很重要的因素。
Library Cache Activity DB/Inst: G10R25/G10R25 Snaps: 2964-2965
-> "Pct Misses" should be very low http://www.askmaclean.com
Get Pct Pin Pct Invali-
Namespace Requests Miss Requests Miss Reloads dations
--------------- ------------ ------ -------------- ------ ---------- --------
BODY 5 0.0 6 16.7 1 0
CLUSTER 10 0.0 26 0.0 0 0
SQL AREA 601,357 99.8 902,828 99.7 47 2
TABLE/PROCEDURE 83 9.6 601,443 0.0 48 0
GETS NUMBER Number of times a lock was requested for objects of this namespace
GETHITS NUMBER Number of times an object’s handle was found in memory
GETHITRATIO NUMBER Ratio of GETHITS to GETS
PINS NUMBER Number of times a PIN was requested for objects of this namespace
PINHITS NUMBER Number of times all of the metadata pieces of the library object were found in memory
PINHITRATIO NUMBER Ratio of PINHITS to PINS
RELOADS NUMBER Any 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
INVALIDATIONS NUMBER Total 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: 軟解析比例，無需多說的經典指標，數據來源v$sysstat statistics的parse count(total)和parse count(hard)。 合理值>95%
Soft Parse %是AWR中另一個重要的解析指標，該指標反應了快照時間內 軟解析次數 和 總解析次數 (soft+hard 軟解析次數+硬解析次數)的比值，若該指標很低，那么說明了可能存在劇烈的hard parse硬解析，大量的硬解析會消耗更多的CPU時間片並產生解析爭用(此時可以考慮使用cursor_sharing=FORCE)； 理論上我們總是希望 Soft Parse % 接近於100%， 但並不是說100%的軟解析就是最理想的解析狀態，通過設置 session_cached_cursors參數和反復重用游標我們可以讓解析來的更輕量級，即通俗所說的利用會話緩存游標實現的軟軟解析(soft soft parse)。
7、
Execute to Parse% 指標反映了執行解析比 其公式為 1-(parse/execute) , 目標為100% 及接近於只 執行而不解析。 數據來源v$sysstat statistics parse count (total) 和execute count
在oracle中解析往往是執行的先提工作，但是通過游標共享 可以解析一次 執行多次， 執行解析可能分成多種場景：
1.hard coding => 硬編碼代碼 硬解析一次 ，執行一次， 則理論上其執行解析比 為 1:1 ，則理論上Execute to Parse =0 極差，且soft parse比例也為0%
2.綁定變量但是仍軟解析=》 軟解析一次，執行一次 ， 這種情況雖然比前一種好 但是執行解析比(這里的parse，包含了軟解析和硬解析)仍是1:1， 理論上Execute to Parse =0 極差， 但是soft parse比例可能很高
3.使用 靜態SQL、動態綁定、session_cached_cursor、open cursors等技術實現的 解析一次，執行多次， 執行解析比為N:1， 則 Execute to Parse= 1- (1/N) 執行次數越多 Execute to Parse越接近100% ，這種是我們在OLTP環境中喜聞樂見的！
通俗地說 soft parse% 反映了軟解析率， 而軟解析在oracle中仍是較昂貴的操作， 我們希望的是解析1次執行N次，如果每次執行均需要軟解析，那么雖然soft parse%=100% 但是parse time仍可能是消耗DB TIME的大頭。
Execute to Parse反映了 執行解析比，Execute to Parse和soft parse% 都很低 那么說明確實沒有綁定變量 ， 而如果 soft parse% 接近99% 而Execute to Parse 不足90% 則說明沒有執行解析比低， 需要通過 靜態SQL、動態綁定、session_cached_cursor、open cursors等技術減少軟解析。
8、
Latch Hit%: willing-to-wait latch閂申請不要等待的比例。 數據來源V$latch gets和misses
Latch Name
----------------------------------------
Get Requests Misses Sleeps Spin Gets Sleep1 Sleep2 Sleep3
-------------- ----------- ----------- ---------- -------- -------- --------
shared pool
9,988,637 364 23 341 0 0 0
library cache
6,753,468 152 6 146 0 0 0
Memory Management Latch
369 1 1 0 0 0 0
qmn task queue latch
24 1 1 0 0 0 0
Latch Hit%:= (1 – (Sum(misses) / Sum(gets)))
關於Latch的更多信息內容可以參考 AWR后面的專欄Latch Statistics， 注意對於一個並發設計良好的OLTP應用來說，Latch、Enqueue等並發控制不應當成為系統的主要瓶頸， 同時對於這些並發爭用而言 堆積硬件CPU和內存 很難有效改善性能。
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:該指標反映了 快照內解析CPU時間和總的解析時間的比值(Parse CPU Time/ Parse Elapsed Time)； 若該指標水平很低，那么說明在整個解析過程中 實際在CPU上運算的時間是很短的，而主要的解析時間都耗費在各種其他非空閑的等待事件上了(如latch:shared pool,row cache lock之類等) 數據來源 V$sysstat 的 parse time cpu和parse time elapsed
10、
%Non-Parse CPU 非解析cpu比例，公式為 (DB CPU – Parse CPU)/DB CPU， 若大多數CPU都用在解析上了，則可能好鋼沒用在刃上了。 數據來源 v$sysstat 的 parse time cpu和 cpu used by this session
1-4 Shared Pool Statistics
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 84.64 79.67
% SQL with executions>1: 93.77 24.69
% Memory for SQL w/exec>1: 85.36 34.8
該環節提供一個大致的SQL重用及shared pool內存使用的評估。 應用是否共享SQL? 有多少內存是給只運行一次的SQL占掉的，對比共享SQL呢？
如果該環節中% SQL with executions>1的 比例 小於%90 ， 考慮用下面鏈接的SQL去抓 硬編碼的非綁定變量SQL語句。
利用FORCE_MATCHING_SIGNATURE捕獲非綁定變量SQL
Memory Usage %: (shared pool 的實時大小- shared pool free memory)/ shared pool 的實時大小， 代表shared pool的空間使用率，雖然有使用率但沒有標明碎片程度
% SQL with executions>1 復用的SQL占總的SQL語句的比率,數據來源 DBA_HIST_SQL_SUMMARY 的 SINGLE_USE_SQL和TOTAL_SQL：1 – SINGLE_USE_SQL / TOTAL_SQL
% Memory for SQL w/exec>1 執行2次以上的SQL所占內存占總的SQL內存的比率，數據來源DBA_HIST_SQL_SUMMARY 的SINGLE_USE_SQL_MEM和TOTAL_SQL_MEM：1 – SINGLE_USE_SQL_MEM / TOTAL_SQL_MEM
==》上面2個指標也可以用來大致了解shared pool中的內存碎片程序，因為SINGLE_USE_SQL 單次執行的SQL多的話，那么顯然可能有較多的共享池內存碎片
SQL復用率低的原因一般來說就是硬綁定變量(hard Coding)未合理使用綁定變量(bind variable)，對於這種現象短期無法修改代表使用綁定變量的可以ALTER SYSTEM SET CURSOR_SHARING=FORCE; 來繞過問題，對於長期來看還是要修改代碼綁定變量。 Oracle 從11g開始宣稱今后將廢棄CURSOR_SHARING的SIMILAR選項，同時SIMILAR選項本身也造成了很多問題，所以一律不推薦用CURSOR_SHARING=SIMILAR。
如果memory usage%比率一直很高，則可以關注下后面sga breakdown中的shared pool free memory大小，一般推薦至少讓free memroy有個300~500MB 以避免隱患。
1-5 Top 5 Timed Events
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
gc buffer busy 79,083 73,024 923 65.4 Cluster
enq: TX - row lock contention 35,068 17,123 488 15.3 Applicatio
CPU time 12,205 10.9
gc current request 2,714 3,315 1221 3.0 Cluster
gc cr multi block request 83,666 1,008 12 0.9 Cluster
基於Wait Interface的調優是目前的主流！每個指標都重要！
基於命中比例的調優，好比是統計局的報告， 張財主家財產100萬，李木匠家財產1萬， 平均財產50.5萬。
基於等待事件的調優，好比馬路上100輛汽車的行駛記錄表，上車用了幾分鍾， 紅燈等了幾分鍾，擁堵塞了幾分鍾。。。
豐富的等待事件以足夠的細節來描繪系統運行的性能瓶頸，這是Mysql夢寐以求的東西……
Waits : 該等待事件發生的次數， 對於DB CPU此項不可用
Times : 該等待事件消耗的總計時間，單位為秒， 對於DB CPU 而言是前台進程所消耗CPU時間片的總和，但不包括Wait on CPU QUEUE
Avg Wait(ms) : 該等待事件平均等待的時間， 實際就是 Times/Waits，單位ms， 對於DB CPU此項不可用
% 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
CPU 上在干什么？
邏輯讀？ 解析？Latch spin? PL/SQL、函數運算?
DB CPU/CPU time是Top 1 是好事情嗎？ 未必！
注意DB CPU不包含 wait on cpu queue！
SELECT e.event_name event,
e.total_waits - NVL (b.total_waits, 0) waits,
DECODE (
e.total_waits - NVL (b.total_waits, 0),
0, TO_NUMBER (NULL),
DECODE (
e.total_timeouts - NVL (b.total_timeouts, 0),
0, TO_NUMBER (NULL),
100
* (e.total_timeouts - NVL (b.total_timeouts, 0))
/ (e.total_waits - NVL (b.total_waits, 0))))
pctto,
(e.time_waited_micro - NVL (b.time_waited_micro, 0)) / 1000000 time,
DECODE (
(e.total_waits - NVL (b.total_waits, 0)),
0, TO_NUMBER (NULL),
( (e.time_waited_micro - NVL (b.time_waited_micro, 0)) / 1000)
/ (e.total_waits - NVL (b.total_waits, 0)))
avgwt,
DECODE (e.wait_class, 'Idle', 99, 0) idle
FROM dba_hist_system_event b, dba_hist_system_event e
WHERE b.snap_id(+) = &bid
AND e.snap_id = &eid
--AND b.dbid(+) = :dbid
--AND e.dbid = :dbid
AND b.instance_number(+) = 1
AND e.instance_number = 1
AND b.event_id(+) = e.event_id
AND e.total_waits > NVL (b.total_waits, 0)
AND e.event_name NOT IN
('smon timer',
'pmon timer',
'dispatcher timer',
'dispatcher listen timer',
'rdbms ipc message')
ORDER BY idle,
time DESC,
waits DESC,
event
幾種常見的等待事件
=========================>
db file scattered read, Avg wait time應當小於20ms 如果數據庫執行全表掃描或者是全索引掃描會執行 Multi block I/O ，此時等待物理I/O 結束會出現此等待事件。一般會從應用程序（SQL），I/O 方面入手調整; 注意和《Instance Activity Stats》中的index fast full scans (full) 以及 table scans (long tables)集合起來一起看。
db file sequential read ，該等待事件Avg wait time平均單次等待時間應當小於20ms
”db file sequential read”單塊讀等待是一種最為常見的物理IO等待事件，這里的sequential指的是將數據塊讀入到相連的內存空間中(contiguous memory space)，而不是指所讀取的數據塊是連續的。該wait event可能在以下情景中發生:
http://www.askmaclean.com/archives/db-file-sequential-read-wait-event.html
latch free 其實是未獲得latch ，而進入latch sleep，見《全面解析9i以后Oracle Latch閂鎖原理》
enq:XX 隊列鎖等待，視乎不同的隊列鎖有不同的情況：
■你有多了解Oracle Enqueue lock隊列鎖機制？
■Oracle隊列鎖: Enqueue HW
■Oracle隊列鎖enq:US,Undo Segment
■enq: TX – row lock/index contention、allocate ITL等待事件
■enq: TT – contention等待事件
■Oracle隊列鎖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：是由於無法找到可用的buffer cache 空閑區域，需要等待DBWR 寫入完成引起
■一般是由於
■低效的sql
■過小的buffer cache
■DBWR 工作負荷過量
buffer busy wait/ read by other session 一般以上2個等待事件可以歸為一起處理，建議客戶都進行監控 。 以上等待時間可以由如下操作引起
■select/select —- read by other session: 由於需要從 數據文件中將數據塊讀入 buffer cache 中引起，有可能是 大量的 邏輯/物理讀 ;或者過小的 buffer cache 引起
■select/update —- buffer busy waits/ read by other session 是由於更新某數據塊后 需要在undo 中 重建構建 過去時間的塊，有可能伴生 enq:cr-contention 是由於大量的物理讀/邏輯讀造成。
■update/update —- buffer busy waits 由於更新同一個數據塊（非同一行，同一行是enq:TX-contention） 此類問題是熱點塊造成
■insert/insert —- buffer busy waits 是由於freelist 爭用造成，可以將表空間更改為ASSM 管理 或者加大freelist 。
write complete waits :一般此類等待事件是由於 DBWR 將臟數據寫入 數據文件，其他進程如果需要修改 buffer cache會引起此等待事件，一般是 I/O 性能問題或者是DBWR 工作負荷過量引起
Wait time 1 Seconds.
control file parallel write：頻繁的更新控制文件會造成大量此類等待事件，如日志頻繁切換，檢查點經常發生，nologging 引起頻繁的數據文件更改，I/O 系統性能緩慢。
log file sync：一般此類等待時間是由於 LGWR 進程講redo log buffer 寫入redo log 中發生。如果此類事件頻繁發生，可以判斷為：
■commit 次數是否過多
■I/O 系統問題
■重做日志是否不必要被創建
■redo log buffer 是否過大
2-1 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 name
Statistic Name Time (s) % of DB Time
------------------------------------------ ------------------ ------------
sql execute elapsed time 805,159.7 91.1
sequence load elapsed time 41,159.2 4.7
DB CPU 20,649.1 2.3
parse time elapsed 1,112.8 .1
hard parse elapsed time 995.2 .1
hard parse (sharing criteria) elapsed time 237.3 .0
hard parse (bind mismatch) elapsed time 227.6 .0
connection management call elapsed time 29.7 .0
PL/SQL execution elapsed time 9.2 .0
PL/SQL compilation elapsed time 6.6 .0
failed parse elapsed time 2.0 .0
repeated bind elapsed time 0.4 .0
DB time 883,542.2
background elapsed time 25,439.0
background cpu time 1,980.9
-------------------------------------------------------------
Time Model Statistics幾個特別有用的時間指標：
■parse time elapsed、hard parse elapsed time 結合起來看解析是否是主要矛盾，若是則重點是軟解析還是硬解析
■sequence load elapsed time sequence序列爭用是否是問題焦點
■PL/SQL compilation elapsed time PL/SQL對象編譯的耗時
■注意PL/SQL execution elapsed time 純耗費在PL/SQL解釋器上的時間。不包括花在執行和解析其包含SQL上的時間
■connection management call elapsed time 建立數據庫session連接和斷開的耗時
■failed parse elapsed time 解析失敗，例如由於ORA-4031
■hard parse (sharing criteria) elapsed time 由於無法共享游標造成的硬解析
■hard parse (bind mismatch) elapsed time 由於bind type or bind size 不一致造成的硬解析
注意該時間模型中的指標存在包含關系所以Time Model Statistics加起來超過100%再正常不過
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 time
2-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 wait
Wait Class Waits -outs Time (s) (ms) %DB time
-------------------- ---------------- ----- ---------------- -------- ---------
Cluster 9,825,884 1 525,134 53 59.4
Concurrency 688,375 0 113,782 165 12.9
User I/O 34,405,042 0 76,695 2 8.7
Commit 172,193 0 62,776 365 7.1
Application 11,422 0 57,760 5057 6.5
Configuration 19,418 1 48,889 2518 5.5
DB CPU 20,649 2.3
Other 1,757,896 94 924 1 0.1
System I/O 30,165 0 598 20 0.1
Network 171,955,673 0 400 0 0.0
Administrative 2 100 0 101 0.0
-------------------------------------------------------------
select distinct wait_class from v$event_name;
WAIT_CLASS
----------------------------------------------------------------
Concurrency
User I/O
System I/O
Administrative
Other
Configuration
Scheduler
Cluster
Application
Queueing
Idle
Network
Commit
■Wait Class: 等待事件的類型，如上查詢所示，被分作12個類型。 10.2.0.5有916個等待事件，其中Other類型占622個。
■Waits: 該類型所屬等待事件在快照時間內的等待次數
■%Time Out 等待超時的比率， 未 超時次數/waits * 100 (%)
■Total Wait Time: 該類型所屬等待事件總的耗時，單位為秒
■Avg Wait(ms) : 該類型所屬等待事件的平均單次等待時間，單位為ms ，實際這個指標對commit 和 user i/o 以及system i/o類型有點意義，其他等待類型由於等待事件差異較大所以看平均值的意義較小
■waits / txn: 該類型所屬等待事件的等待次數和事務比
Other 類型，遇到該類型等待事件 的話 常見的原因是Oracle Bug或者 網絡、I/O存在問題， 一般推薦聯系Maclean。
Concurrency 類型 並行爭用類型的等待事件， 典型的如 latch: shared pool、latch: library cache、row cache lock、library cache pin/lock
Cluster 類型 為Real Application Cluster RAC環境中的等待事件， 需要注意的是 如果啟用了RAC option，那么即使你的集群中只啟動了一個實例，那么該實例也可能遇到 Cluster類型的等待事件, 例如gc buffer busy
System I/O 主要是后台進程維護數據庫所產生的I/O，例如control file parallel write 、log file parallel write、db file parallel write。
User I/O 主要是前台進程做了一些I/O操作，並不是說后台進程不會有這些等待事件。 典型的如db file sequential/scattered read、direct path read
Configuration 由於配置引起的等待事件， 例如 日志切換的log file switch completion (日志文件 大小/數目 不夠)，sequence的enq: SQ – contention (Sequence 使用nocache) ； Oracle認為它們是由於配置不當引起的，但實際未必真是這樣的配置引起的。
Application 應用造成的等待事件， 例如enq: TM – contention和enq: TX – row lock contention； Oracle認為這是由於應用設計不當造成的等待事件， 但實際這些Application class 等待可能受到 Concurrency、Cluster、System I/O 、User I/O等多種類型等待的影響，例如本來commit只要1ms ，則某一行數據僅被鎖定1ms， 但由於commit變慢 從而釋放行鎖變慢，引發大量的enq: TX – row lock contention等待事件。
Commit 僅log file sync ，log file sync的影響十分廣泛，值得我們深入討論。
Network : 網絡類型的等待事件 例如 SQL*Net more data to client 、SQL*Net more data to dblink
Idle 空閑等待事件 ，最為常見的是rdbms ipc message (等待實例內部的ipc通信才干活，即別人告知我有活干，我才干，否則我休息==》Idle)， SQL*Net message from client(等待SQL*NET傳來信息，否則目前沒事干)
2-3 前台等待事件
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 % DB
Event Waits -outs Time (s) (ms) /txn time
-------------------------- ------------ ----- ---------- ------- -------- ------
gc buffer busy acquire 3,274,352 3 303,088 93 13.3 34.3
gc buffer busy release 387,673 2 128,114 330 1.6 14.5
enq: TX - index contention 193,918 0 97,375 502 0.8 11.0
cell single block physical 30,738,730 0 63,606 2 124.8 7.2
log file sync 172,193 0 62,776 365 0.7 7.1
gc current block busy 146,154 0 53,027 363 0.6 6.0
enq: TM - contention 1,060 0 47,228 44555 0.0 5.3
enq: SQ - contention 17,431 0 35,683 2047 0.1 4.0
gc cr block busy 105,204 0 33,746 321 0.4 3.8
buffer busy waits 279,721 0 12,646 45 1.1 1.4
enq: HW - contention 1,201 3 12,192 10151 0.0 1.4
enq: TX - row lock content 9,231 0 10,482 1135 0.0 1.2
cell multiblock physical r 247,903 0 6,547 26 1.0 .7
Foreground Wait Events 前台等待事件，數據主要來源於DBA_HIST_SYSTEM_EVENT
Event 等待事件名字
Waits 該等待事件在快照時間內等待的次數
%Timeouts : 每一個等待事件有其超時的設置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件 單次等待達到timeout的時間，則會進入下一次該等待事件
Total Wait Time 該等待事件 總的消耗的時間 ，單位為秒
Avg wait(ms): 該等待事件的單次平均等待時間，單位為毫秒
Waits/Txn: 該等待事件的等待次數和事務比
2-4 后台等待事件
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 % bg
Event Waits -outs Time (s) (ms) /txn time
-------------------------- ------------ ----- ---------- ------- -------- ------
db file parallel write 90,979 0 7,831 86 0.4 30.8
gcs log flush sync 4,756,076 6 4,714 1 19.3 18.5
enq: CF - contention 2,123 40 4,038 1902 0.0 15.9
control file sequential re 90,227 0 2,380 26 0.4 9.4
log file parallel write 108,383 0 1,723 16 0.4 6.8
control file parallel writ 4,812 0 988 205 0.0 3.9
Disk file operations I/O 26,216 0 731 28 0.1 2.9
flashback log file write 9,870 0 720 73 0.0 2.8
LNS wait on SENDREQ 202,747 0 600 3 0.8 2.4
ASM file metadata operatio 15,801 0 344 22 0.1 1.4
cell single block physical 39,283 0 341 9 0.2 1.3
LGWR-LNS wait on channel 183,443 18 203 1 0.7 .8
gc current block busy 122 0 132 1082 0.0 .5
gc buffer busy release 60 12 127 2113 0.0 .5
Parameter File I/O 592 0 116 195 0.0 .5
log file sequential read 1,804 0 104 58 0.0 .4
Background Wait Events 后台等待事件， 數據主要來源於DBA_HIST_BG_EVENT_SUMMARY
Event 等待事件名字
Waits 該等待事件在快照時間內等待的次數
%Timeouts : 每一個等待事件有其超時的設置，例如buffer busy waits 一般為3秒， Write Complete Waits的 timeout為1秒，如果等待事件 單次等待達到timeout的時間，則會進入下一次該等待事件
Total Wait Time 該等待事件 總的消耗的時間 ，單位為秒
Avg wait(ms): 該等待事件的單次平均等待時間，單位為毫秒
Waits/Txn: 該等待事件的等待次數和事務比
2-5 Operating System Statistics
Operating System Statistics Snaps: 70719-70723
TIME 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), Name
Statistic Value End Value
------------------------- ---------------------- ----------------
BUSY_TIME 2,894,855
IDLE_TIME 5,568,240
IOWAIT_TIME 18,973
SYS_TIME 602,532
USER_TIME 2,090,082
LOAD 8 13
VM_IN_BYTES 0
VM_OUT_BYTES 0
PHYSICAL_MEMORY_BYTES 101,221,343,232
NUM_CPUS 24
NUM_CPU_CORES 12
NUM_CPU_SOCKETS 2
GLOBAL_RECEIVE_SIZE_MAX 4,194,304
GLOBAL_SEND_SIZE_MAX 2,097,152
TCP_RECEIVE_SIZE_DEFAULT 87,380
TCP_RECEIVE_SIZE_MAX 4,194,304
TCP_RECEIVE_SIZE_MIN 4,096
TCP_SEND_SIZE_DEFAULT 16,384
TCP_SEND_SIZE_MAX 4,194,304
TCP_SEND_SIZE_MIN 4,096
-------------------------------------------------------------
Operating System Statistics 操作系統統計信息
數據來源於V$OSSTAT / DBA_HIST_OSSTAT，, TIME相關的指標單位均為百分之一秒
統計項 描述
NUM_CPU_SOCKETS 物理CPU的數目
NUM_CPU_CORES CPU的核數
NUM_CPUS 邏輯CPU的數目
SYS_TIME 在內核態被消耗掉的CPU時間片，單位為百分之一秒
USER_TIME 在用戶態被消耗掉的CPU時間片，單位為百分之一秒
BUSY_TIME Busy_Time=SYS_TIME+USER_TIME 消耗的CPU時間片，單位為百分之一秒
AVG_BUSY_TIME AVG_BUSY_TIME= BUSY_TIME/NUM_CPUS
IDLE_TIME 空閑的CPU時間片，單位為百分之一秒
所有CPU所能提供總的時間片 BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
OS_CPU_WAIT_TIME 進程等OS調度的時間，cpu queuing
VM_IN_BYTES 換入頁的字節數
VM_OUT_BYTES 換出頁的字節數，部分版本下並不准確，例如Bug 11712010 Abstract: VIRTUAL MEMORY PAGING ON 11.2.0.2 DATABASES，僅供參考
IOWAIT_TIME 所有CPU花費在等待I/O完成上的時間 單位為百分之一秒
RSRC_MGR_CPU_WAIT_TIME 是指當resource manager控制CPU調度時，需要控制對應進程暫時不使用CPU而進程到內部運行隊列中，以保證該進程對應的consumer group(消費組)沒有消耗比指定resource manager指令更多的CPU。RSRC_MGR_CPU_WAIT_TIME指等在內部運行隊列上的時間，在等待時不消耗CPU
2-6 Service Statistcs
Service Statistics Snaps: 70719-70723
-> ordered by DB Time
Physical Logical
Service Name DB Time (s) DB CPU (s) Reads (K) Reads (K)
---------------------------- ------------ ------------ ------------ ------------
itms-contentmasterdb-prod 897,099 20,618 35,668 1,958,580
SYS$USERS 4,312 189 5,957 13,333
itmscmp 1,941 121 14,949 18,187
itscmp 331 20 114 218
itscmp_dgmgrl 121 1 0 0
SYS$BACKGROUND 0 0 142 30,022
ITSCMP1_PR 0 0 0 0
its-reference-prod 0 0 0 0
itscmpXDB 0 0 0 0
按照Service Name來分組時間模型和 物理、邏輯讀取， 部分數據來源於 WRH$_SERVICE_NAME;
Service Name 對應的服務名 (v$services)， SYS$BACKGROUND代表后台進程， SYS$USERS一般是系統用戶登錄
DB TIME (s): 本服務名所消耗的DB TIME時間，單位為秒
DB CPU(s): 本服務名所消耗的DB CPU 時間，單位為秒
Physical Reads : 本服務名所消耗的物理讀
Logical Reads : 本服務所消耗的邏輯讀
2-7 Service Wait Class Stats
Service Wait Class Stats Snaps: 70719-70723
-> Wait Class info 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 seconds
Service Name
----------------------------------------------------------------
User I/O User I/O Concurcy Concurcy Admin Admin Network Network
Total 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 127
SYS$USERS
173233 3656 6738 30 2 0 72674 3
itmscmp
676773 1319 1831 0 0 0 2216 0
itscmp
219577 236 1093 0 0 0 18112 0
itscmp_dgmgrl
34 0 8 0 0 0 9 0
SYS$BACKGROUND
71940 1300 320677 56 0 0 442252 872
-------------------------------------------------------------
■User I/O Total Wts : 對應該服務名下 用戶I/O類等待的總的次數
■User I/O Wt Time : 對應該服務名下 用戶I/O累等待的總時間，單位為 1/100秒
■Concurcy Total Wts: 對應該服務名下 Concurrency 類型等待的總次數
■Concurcy Wt Time :對應該服務名下 Concurrency 類型等待的總時間， 單位為 1/100秒
■Admin Total Wts: 對應該服務名下Admin 類等待的總次數
■Admin Wt Time: 對應該服務名下Admin類等待的總時間，單位為 1/100秒
■Network Total Wts : 對應服務名下Network類等待的總次數
■Network Wt Time： 對應服務名下Network類等待的總事件， 單位為 1/100秒
2-8 Host CPU
Host CPU (CPUs: 24 Cores: 12 Sockets: 2)
~~~~~~~~ Load Average
Begin End %User %System %WIO %Idle
--------- --------- --------- --------- --------- ---------
8.41 12.84 24.7 7.1 0.2 65.8
“Load Average” begin/end值代表每個CPU的大致運行隊列大小。上例中快照開始到結束，平均 CPU負載增加了；與《2-5 Operating System Statistics》中的LOAD相呼應。
%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,該實例所使用的CPU占總CPU的比例 % of total CPU for Instance
%Busy CPU，該實例所使用的Cpu占總的被使用CPU的比例 % of busy CPU for Instance
例如共4個邏輯CPU，其中3個被完全使用，3個中的1個完全被該實例使用，則%Total CPU= ? =25%，而%Busy CPU= 1/3= 33%
當CPU高時一般看%Busy CPU可以確定CPU到底是否是本實例消耗的，還是主機上其他程序
% 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
3-1 SQL ordered by Elapsed Time ，按照SQL消耗的時間來排列TOP SQL
Elapsed Time (s): 該SQL累計運行所消耗的時間，
Executions : 該SQL在快照時間內 總計運行的次數 ； 注意， 對於在快照時間內還沒有執行完的SQL 不計為1一次，所以如果看到executions=0而 又是TOP SQL，則很有可能是因為該SQL 運行較舊還沒執行完，需要特別關注一下。
%Total 該SQL所消耗的時間占總的DB Time的百分比， 即 (SQL Elapsed Time / Total DB TIME)
% CPU 該SQL 所消耗的CPU 時間 占 該SQL消耗的時間里的比例， 即 (SQL CPU Time / SQL Elapsed Time) ，該指標說明了該語句是否是CPU敏感的
%IO 該SQL 所消耗的I/O 時間 占 該SQL消耗的時間里的比例， 即(SQL I/O Time/SQL Elapsed Time) ，該指標說明了該語句是否是I/O敏感的
SQL Id : 通過計算SQL 文本獲得的SQL_ID ，不同的SQL文本必然有不同的SQL_ID， 對於10g~11g而言 只要SQL文本不變那么在數據庫之間 該SQL 對應的SQL_ID應當不不變的， 12c中修改了SQL_ID的計算方法
3-2 SQL ordered by CPU Time
CPU TIME : 該SQL 在快照時間內累計執行所消耗的CPU 時間片，單位為s
Executions : 該SQL在快照時間內累計執行的次數
CPU per Exec (s) ：該SQL 平均單次執行所消耗的CPU時間 ， 即 ( SQL CPU TIME / SQL Executions )
%Total : 該SQL 累計消耗的CPU時間 占 該時段總的 DB CPU的比例， 即 ( SQL CPU TIME / Total DB CPU)
% CPU 該SQL 所消耗的CPU 時間 占 該SQL消耗的時間里的比例， 即 (SQL CPU Time / SQL Elapsed Time) ，該指標說明了該語句是否是CPU敏感的
%IO 該SQL 所消耗的I/O 時間 占 該SQL消耗的時間里的比例， 即(SQL I/O Time/SQL Elapsed Time) ，該指標說明了該語句是否是I/O敏感的
3-3 Buffer Gets SQL ordered by Gets
Buffer Gets : 該SQL在快照時間內累計運行所消耗的buffer gets，包括了consistent read 和 current read
Executions : 該SQL在快照時間內累計執行的次數
Gets per Exec : 該SQL平均單次的buffer gets ， 對於事務型transaction操作而言 一般該單次buffer gets小於2000
% Total 該SQL 累計運行所消耗的buffer gets占 總的db buffer gets的比率， (SQL buffer gets / DB total buffer gets)
3-4 Physical Reads SQL ordered by Reads
Physical reads : 該SQL累計運行所消耗的物理讀
Executions : 該SQL在快照時間內累計執行的次數
Reads per Exec : 該SQL 單次運行所消耗的物理讀， (SQL Physical reads/Executions) ， 對於OLTP transaction 類型的操作而言單次一般不超過100
%Total : 該SQL 累計消耗的物理讀 占 該時段總的 物理讀的比例， 即 ( SQL physical read / Total DB physical read )
3-7 SQL ordered by Sharable Memory
SQL ordered by Sharable Memory , 一般該部分僅列出Sharable Mem (b)為1 MB以上的SQL 對象 (Only Statements with Sharable Memory greater than 1048576 are displayed) 數據來源是 DBA_HIST_SQLSTAT.SHARABLE_MEM
Shareable Mem(b): SQL 對象所占用的共享內存使用量
Executions : 該SQL在快照時間內累計執行的次數
%Total : 該SQL 對象鎖占共享內存 占總的共享內存的比率
*************************************11011547*************************************
Oracle AWR報告指標全解析-11011552
免責聲明！
本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。