statspack report分析 (zt)

statspack report分析

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


雖然不完整,但看看還是很有好處的

(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%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。
4.Shared Pool相關統計資料
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 60.45 62.42
% SQL with executions>1: 81.38 78.64
% Memory for SQL w/exec>1: 70.36 68.02 

Memory Usage %：正在使用的共享池的百分率。這個數字應該長時間穩定在75%～90%。如果這個百分率太低，就浪費記憶體。如果這個百分率太高，會使共享池外部的元件老 化，如果SQL語句被再次執行，這將使得SQL語句被硬解析。在一個大小合適的系統中，共享池的使用率將處於75%到略低於90%的範圍內。
% SQL with executions>1：這是在共享池中有多少個執行次數大於一次的SQL語句的度量。在一個趨向於迴圈執行的系統中，必須認真考慮這個數字。在 這個迴圈系統中，在一天中相對於另一部分時間的部分時間裡執行了一組不同的SQL語句。在共享池中，在觀察期間將有一組未被執行過的SQL語句，這僅僅是 因為要執行它們的語句在觀察期間沒有執行。只有系統連續執行相同的SQL語句組，這個數字才會接近100%。這裡顯示，在這個共享池中幾乎有80%的 SQL語句在18分鐘的觀察視窗中執行次數多於一次。剩下的20%的語句可能已經在那裡了--系統只是沒有理由去執行它。
% Memory for SQL w/exec>1：這是與不頻繁使用的SQL語句相比，頻繁使用的SQL語句消耗記憶體多少的一個度量。這個數字將在總體上與% SQL with executions>1非常接近，除非有某些查詢任務消耗的記憶體沒有規律。
在穩定狀態下，總體上會看見隨著時間的 推移大約有75%～85%的共享池被使用。如果Statspack報表的時間視窗足夠大到覆蓋所有的週期，執行次數大於一次的SQL語句的百分率應該接近 於100%。這是一個受觀察之間持續時間影響的統計數字。可以期望它隨觀察之間的時間長度增大而增大。