statspack report分析(轉) 一、statspack 輸出結果中必須檢視的十項内容
1、負載間檔(Load profile)
2、執行個體效率點選率(Instance efficiency hit ratios)
3、首要的5個等待事件(Top 5 wait events)
4、等待事件(Wait events)
5、闩鎖等待
6、首要的SQL(Top sql)
7、執行個體活動(Instance activity)
8、檔案I/O(File I/O)
9、記憶體配置設定(Memory allocation)
10、緩沖區等待(Buffer waits)
二、輸出結果解釋
1、報表頭資訊
資料庫執行個體相關資訊，包括資料庫名稱、ID、版本号及主機等資訊
STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
---------- --------- ---------- --------- --------- ------- ----------
Allen 3874352951 allen 1 9.2.0.4.0 NO ALLEN_WANG
Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- --------------
Begin Snap: 36 18-11月 -04 20:41:02 29 19.2
End Snap: 37 18-11月 -04 08:18:27 24 15.7
Elapsed: 697.42 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 240M Std Block Size: 8K
Shared Pool Size: 96M Log Buffer: 512K
2、負載間檔
該部分提供每秒和每個事物的統計資訊，是監控系統吞吐量和負載變化的重要部分
Quote:
Load Profile
~~~~~~~~~~~~ Per Second(秒) Per Transaction事物
--------------- ---------------
Redo size: 148.46 3,702.15
Logical reads: 1,267.94 31,619.12
Block changes: 1.01 25.31
Physical reads: 4.04 100.66
Physical writes: 4.04 100.71
User calls: 13.95 347.77
Parses: 4.98 124.15
Hard parses: 0.02 0.54
Sorts: 1.33 33.25
Logons: 0.00 0.02
Executes: 2.46 61.37
Transactions: 0.04
% Blocks changed per Read: 0.08 Recursive Call %: 30.38
Rollback per transaction %: 0.42 Rows per Sort: 698.23
說明:
Redo size:每秒産生的日志大小(機關位元組)，可标志資料變更頻率, 資料庫任務的繁重與否
Logical reads:平決每秒産生的邏輯讀，機關是block
block changes:每秒block變化數量，資料庫事物帶來改變的塊數量
Physical reads:平均每秒資料庫從磁盤讀取的block數
Physical writes:平均每秒資料庫寫磁盤的block數
User calls:每秒使用者call次數
Parses: 每秒解析次數，近似反應每秒語句的執行次數, 軟解析每秒超過300次意味着你的"應 用程式"效率不高，沒有使用soft soft parse，調整session_cursor_cache
Hard parses:每秒産生的硬解析次數, 每秒超過100次，就可能說明你綁定使用的不好
Sorts:每秒産生的排序次數
Executes:每秒執行次數
Transactions:每秒産生的事務數，反映資料庫任務繁重與否
Recursive Call %: 如果有很多PLSQL，那麼他就會比較高
Rollback per transaction %:看復原率是不是很高，因為復原很耗資源
如果復原率過高，可能說明你的資料庫經曆了太多的無效操作，過多的復原可能還會帶來Undo Block的競争 該參數計算公式如下:
Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%
3、執行個體命中率
該部分可以提前找出ORACLE潛在将要發生的性能問題，很重要
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.96 In-memory Sort %: 99.14
Library Hit %: 99.53 Soft Parse %: 99.57
Execute to Parse %: -102.31 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 81.47 % Non-Parse CPU: 96.46
說明:
Buffer Nowait %:在緩沖區中擷取Buffer的未等待比率, Buffer Nowait<99%說明，有可能是有熱, 塊(查找x$bh的 tch和v$latch_children的cache buffers chains)
Redo NoWait %:在Redo緩沖區擷取Buffer的未等待比率
Buffer Hit %:資料塊在資料緩沖區中得命中率，通常應在90%以上，否則，需要調整, 小于 95%,重要的參數,小于90%可能是要加db_cache_size,但是大量的非選擇的索引也會造成該值很高（大量的db file sequential read）
In-memory Sort %:在記憶體中的排序率
Library Hit %:主要代表sql在共享區的命中率，通常在95%以上，否，需要要考慮加大共享池，綁定變量，修改cursor_sharing等參數。
Soft Parse %:近似看作sql在共享區的命中率，小于<95%,需要考慮到綁定，如果低于80%，
那麼就可能sql基本沒有被重用
Execute to Parse %:sql語句解析後被重複執行的次數，如果過低，可以考慮設定
session_cached_cursors參數, 公式為100 * (1 - Parses/Executions) = Execute to Parse是以如果系統Parses > Executions,就可能出現該比率小于0的情況, 該值<0通常說明shared pool設定或效率存在問題造成反複解析，reparse可能較嚴重,或者可是同snapshot有關如果該值為負值或者極低,通常說明資料庫性能存在問題
Latch Hit %: Latch Hit<99%,要確定>99%，否則存在嚴重的性能問題，比如綁定等會影響該參數
Parse CPU to Parse Elapsd %:解析實際運作事件/(解析實際運作時間+解析中等待資源時間)越高越好
% Non-Parse CPU:查詢實際運作時間/(查詢實際運作時間+sql解析時間)，太低表示解析消耗時間過多。100*（parse time cpu / parse time elapsed）= Parse CPU to Parse Elapsd %
如果一個經常通路的列上的索引被删除，可能會造成buffer hit 顯著的下降
如果增加了索引，但是他影響了ORACLE正确的選擇表連接配接時的驅動順序，那麼可能會導緻buffer hit 顯 著增高
如果你的命中率變化幅度很大，說明你要改變SQL模式
Quote:
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 33.79 57.02
% SQL with executions>1: 62.62 73.24
% Memory for SQL w/exec>1: 64.55 78.72
Shared Pool相關統計資料
Memory Usage %:共享池記憶體使用率，應該穩定在70%-90%間，太小浪費記憶體，太大則記憶體不足。
% SQL with executions>1:執行次數大于1的sql比率，若太小可能是沒有使用bind variables。
% Memory for SQL w/exec>1:也即是memory for sql with execution > 1:執行次數大于1的sql消耗記憶體/所有sql消耗的記憶體
4、首要等待事件
常見等待事件說明:
oracle等待事件是衡量oracle運作狀況的重要依據及訓示，主要有空閑等待事件和非空閑等待事件, TIMED_STATISTICS = TRUE 那麼等待事件按等待的時間排序= FALSE那麼事件按等待的數量排序.運作statspack期間必須session上設定TIMED_STATISTICS = TRUE.
空閑等待事件是oracle正等待某種工作，在診斷和優化資料庫時候，不用過多注意這部分事件，非空閑等待事件專門針對oracle的活動，指資料庫任務或應用程式運作過程中發生的等待，這些等待事件是我們在調整資料庫應該關注的。
比較影響性能常見等待事件
＊db file scattered read
該事件通常與全表掃描有關。因為全表掃描是被放入記憶體中進行的進行的，通常情況下它不可能被放入連續的緩沖區中，是以就散布在緩沖區的緩存中。該指數的數量過大說明缺少索引或者限制了索引的使用(也可以調整optimizer_index_cost_adj) 。這種情況也可能是正常的，因為執行全表掃描可能比索引掃描效率更高。當系統存在這些等待時，需要通過檢查來确定全表掃描是否必需的來調整。如果經常必須進行全表掃描,而且表比較小, 把該表存人keep池.如果是大表經常進行全表掃描,那麼應該是olap系統,而不是oltp的.
＊db file sequential read
該事件說明在單個資料塊上大量等待，該值過高通常是由于表間連接配接順序很糟糕，或者使用了非選擇性索引。通過将這種等待與statspack報表中已知其它問題聯系起來(如效率不高的sql),通過檢查確定索引掃描是必須的，并確定多表連接配接的連接配接順序來調整, DB_CACHE_SIZE可以決定該事件出現的頻率.
＊buffer busy wait
當緩沖區以一種非共享方式或者如正在被讀入到緩沖時,就會出現該等待.該值不應該大于1%,确認是不是由于熱點塊造成(如果是可以用反轉索引,或者用更小塊大小)
＊latch free
常跟應用沒有很好的應用綁定有關. 闩鎖是底層的隊列機制(更加準确的名稱應該是互斥機制)，用于保護系統全局區(SGA)共享記憶體結構闩鎖用于防止對記憶體結構的并行通路。如果闩鎖不可用，就會記錄一次闩鎖丢失。絕大多數得闩鎖問題都與使用綁定變量失敗(庫緩存闩鎖)、生成重作問題(重執行配置設定闩鎖)、緩存的争用問題(緩存LRU鍊) 以及緩存的熱資料寬塊(緩存鍊)有關。當闩鎖丢失率高于0.5%時，需要調整這個問題。
＊log buffer space
日志緩沖區寫的速度快于LGWR寫REDOFILE的速度,可以增大日志檔案大小，增加日志緩沖區的大小，或者使用更快的磁盤來寫資料。
＊logfile switch
通常是因為歸檔速度不夠快,需要增大重做日志.
＊log file sync
當一個使用者送出或復原資料時，LGWR将會話得重做操作從日志緩沖區填充到日志檔案中，使用者的程序必須等待這個填充工作完成。在每次送出時都出現，如果這個等待事件影響到資料庫性能，那麼就需要修改應用程式的送出頻率, 為減少這個等待事件，須一次送出更多記錄，或者将重做日志REDO LOG 檔案訪在不同的實體磁盤上。
Enqueue 最有可能是多個使用者同時修改同一個塊,如果沒有空閑的ITL空間,就會出現資料庫塊級鎖.
TOP SQL
調整首要的25個緩沖區讀操作和首要的25個磁盤讀操作做的查詢,将可對系統性能産生5%到5000%的增益.
Instance Activity Stats for DB: CRMTEMP Instance: crmtemp Snaps: 3 -11
Statistic Total per Second per
Trans
--------------------------------- ---------- ------------ --------
CPU used by this session 291,318 98.1 13.0
CPU used when call started 291,318 98.1 13.0
CR blocks created 1,784 0.6 0.1
Cached Commit SCN referenced 0 0.0 0.0
Commit SCN cached 0 0.0 0.0
DBWR buffers scanned 985,112 331.6 44.0
DBWR checkpoint buffers written 948 0.3 0.0
DBWR checkpoints 0 0.0 0.0
dirty buffers inspected 483 0.2 0.0 --髒緩沖的個數free buffer inspected 8,154 2.7 0.4 --如果數量很大,說明
緩沖區過小
sorts (disk) 0 0.0 0.0 --不應當大于1-5%
sorts (memory) 15,365 5.2 0.7
sorts (rows) 1,445,018 823.0 109.2
summed dirty queue length 24,667 8.3 1.1
[@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/66932/viewspace-916002/，如需轉載，請注明出處，否則将追究法律責任。
轉載于:http://blog.itpub.net/66932/viewspace-916002/