【筆記】statspack（三） report分析 摘錄

yellowlee發表於2010-01-31
筆記

一、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 %:解析實際執行事件/(解析實際執行時間

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16179598/viewspace-626470/，如需轉載，請註明出處，否則將追究法律責任。

相關文章