statspack report分析

雖然不完整,但看看還是很有好處的,關鍵是中文滴:em11:

(1) 調整的先后次序 

1. Tune the design. -- Application designers 

2. Tune the application. -- Application developers 

3. Tune memory. 

4. Tune I/O. 

5. Tune contention. 

6. Tune the operating system. 



Statspack分析報告詳解： 

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 
------------ ----------- ------------ -------- ----------- ------- ------------ 
BLISSDB 4196236801 blissdb 1 9.2.0.4.0 NO BLISS 
Snap Id Snap Time Sessions Curs/Sess Comment 
------- ------------------ -------- --------- ------------------- 
Begin Snap: 4 23-6月 -05 17:43:32 10 3.3 
End Snap: 5 23-6月 -05 18:01:32 12 6.1 
Elapsed: 18.00 (mins) 
Cache Sizes (end) 
~~~~~~~~~~~~~~~~~ 
Buffer Cache: 24M Std Block Size: 8K 
Shared Pool Size: 48M Log Buffer: 512K 

2.負載間檔
該部分提供每秒和每個事物的統計信息，是監控系統吞吐量和負載變化的重要部分。
Load Profile 
~~~~~~~~~~~~ 
Per Second Per Transaction
--------------- ---------------
Redo size: 431,200.16 18,627,847.04z
Logical reads: 4,150.76 179,312.72
Block changes: 2,252.52 97,309.00
Physical reads: 23.93 1,033.56
Physical writes: 68.08 2,941.04
User calls: 0.96 41.36
Parses: 1.12 48.44
Hard parses: 0.04 1.92
Sorts: 0.77 33.28
Logons: 0.00 0.20
Executes: 2.36 102.12
Transactions: 0.02 

Redo size：每秒產生的重做日志大小(單位字節)，可標志數據變更頻率, 數據庫任務的繁重與否。本例中平均每秒產生了430K左右的重做，每個事務品均產生了18M的重做。
Logical reads：平次每秒產生的邏輯讀，單位是block。
block changes：每秒block變化數量，數據庫事物帶來改變的塊數量。
Physical reads：平均每秒數據庫從磁盤讀取的block數。
Logical reads和Physical reads比較：大約有0.55%的邏輯讀導致了物理I/O，平均每個事務執行了大約18萬個邏輯讀，在這個例子中，有一些大的事務被執行，因此很高的讀取數目是可以接受的。
Physical writes：平均每秒數據庫寫磁盤的block數。
User calls：每秒用戶call次數。
Parses和Hard parses：每秒大約1.12個解析，其中有4%為硬解析，系統每25秒分析一些SQL，都還不錯。對于優化好的系統，運行了好幾天后，這一列應該達到0，所有的sql在一段時間后都應該在共享池中。
Sorts：每秒產生的排序次數。
Executes：每秒執行次數。
Transactions：每秒產生的事務數，反映數據庫任務繁重與否。
% Blocks changed per Read: 54.27 Recursive Call %: 86.94
Rollback per transaction %: 12.00 Rows per Sort: 32.59 

% Blocks changed per Read：說明46%的邏輯讀是用于那些只讀的而不是可修改的塊，該系統只更新54%的塊。
Rollback per transaction %：事務回滾的百分比。計算公式為：Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%。本例中每8.33個事務導致一個回滾。如果回滾率過高，可能說明數據庫經歷了太多的無效操作。過多的回滾可能還會帶來Undo Block的競爭。
3.實例命中率
該部分可以提前找出ORACLE潛在將要發生的性能問題，很重要。
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 99.42 In-memory Sort %: 100.00
Library Hit %: 98.11 Soft Parse %: 96.04
Execute to Parse %: 52.57 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 11.40 % Non-Parse CPU: 99.55
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）。如果一個經常訪問的列上的索引被刪除，可能會造成buffer hit 顯著下降。如果增加了索引，但是它影響了ORACLE正確的選擇表連接時的驅動順序，那么可能會導致buffer hit 顯著增高。如果命中率變化幅度很大，說明需要改變SQL模式。
In-memory Sort %：在內存中的排序率。
Library Hit %：主要代表sql在共享區的命中率，通常在95%以上，否則需要要考慮加大共享池，綁定變量，修改cursor_sharing等參數。
Soft Parse %：近似看作sql在共享區的命中率，小于<95%,需要考慮到綁定，如果低于80%，那么就可能sql基本沒有被重用。
Execute to Parse %：一個語句執行和分析了多少次的度量。在一個分析，然后執行語句，且再也不在同一個會話中執行它的系統中，這個比值為0。計算公式為：Execute to Parse =100 * (1 - Parses/Executions)。所以如果系統Parses > Executions，就可能出現該比率小于0的情況。本例中，對于每個分析來說大約執行了2.1次。該值<0通常說明shared pool設置或效率存在問題，造成反復解析，reparse可能較嚴重,或者可是同snapshot有關，如果該值為負值或者極低，通常說明數據庫性能存在問題。
Latch Hit %：要確保>99%，否則存在嚴重的性能問題，比如綁定等會影響該參數。
Parse CPU to Parse Elapsd %：計算公式為：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析實際運行時間/(解析實際運行時間+解析中等待資源時間)。此處為11.4%，非常低，用于解析花費的每個CPU秒花費了大約8.77秒的wall clock時間，這說明花了很多時間等待一個資源。如果該比率為100%，意味著CPU時間等于經過的時間，沒有任何等待。
% Non-Parse CPU：計算公式為：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。太低表示解析消耗時間過多。與PARSE_CPU相比，如果TOT_CPU很高，這個比值將接近100%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。

原文轉自：http://www.anti-gravitydesign.com