statspack報告數據結果解釋
2024-07-21 02:40:18
供稿：網友
statspack報告數據結果解釋
本人將最近在學習性能調優(yōu)時，所用筆記總結如下，歡迎批評指正
本文將不斷更新，歡迎補充。（所列數據僅用于便于說明，沒有實
際意義）
一、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、緩沖區(qū)等待(Buffer waits)
二、輸出結果解釋
1、報表頭信息
數據庫實例相關信息，包括數據庫名稱、ID、版本號及主機等信息
Quote:
STATSPACK report for
DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
PORMALS 3874352951 pormals 1 9.2.0.4.0 NO NJLT-SERVER1
Snap Id Snap Time sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 36 18-7月 -04 20:41:02 29 19.2
End Snap: 37 19-7月 -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、負載間檔
該部分提供每秒和每個事物的統計信息，是監(jiān)控系統吞吐量和負載變化的重要部分
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:每秒產生的日志大小(單位字節(jié))，可標志數據庫任務的繁重與否
Logical reads:平決每秒產生的邏輯讀，單位是block
block changes:每秒block變化數量，數據庫事物帶來改變的塊數量
Physical reads:平均每秒數據庫從磁盤讀取的block數
Physical writes:平均每秒數據庫寫磁盤的block數
User calls:每秒用戶call次數
Parses:每秒解析次數，近似反應每秒語句的執(zhí)行次數
軟解析每秒超過300次意味著你的"應用程序"效
率不高，沒有使用soft soft parse，調整session_cursor_cache
Hard parses:每秒產生的硬解析次數
Sorts:每秒產生的排序次數
Executes:每秒執(zhí)行次數
Transactions:每秒產生的事務數，反映數據庫任務繁重與否
3、實例命中率
該部分可以提前找出Oracle潛在將要發(fā)生的性能問題，很重要
Quote:
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 %:在緩沖區(qū)中獲取Buffer的未等待比率
Redo NoWait %:在Redo緩沖區(qū)獲取Buffer的未等待比率
Buffer Hit %:數據塊在數據緩沖區(qū)中得命中率，通常應在90%以上，否則，需要調整
In-memory Sort %:在內存中的排序率
Library Hit %:主要代表sql在共享區(qū)的命中率，通常在95%以上，否，需要要考慮加
大共享池，綁定變量，修改cursor_sharing等參數。
Soft Parse %:近似看作sql在共享區(qū)的命中率，小于<95%,需要考慮到綁定，假如低于80%，
那么就可能sql基本沒有被重用
Execute to Parse %:sql語句解析后被重復執(zhí)行的次數，假如過低，可以考慮設置
session_cached_cursors參數
Parse CPU to Parse Elapsd %:解析實際運行事件/(解析實際運行時間+解析中等待資源時間)
越高越好
% Non-Parse CPU:查詢實際運行時間/(查詢實際運行時間+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 %:共享池內存使用率，應該穩(wěn)定在75%-90%間，太小浪費內存，太大則內存不足。
% SQL with executions>1:執(zhí)行次數大于1的sql比率，若太小可能是沒有使用bind variables。
% Memory for SQL w/exec>1:也即是memory for sql with execution > 1:執(zhí)行次數大于1的sql
消耗內存/所有sql消耗的內存
4、首要等待事件
常見等待事件說明:
oracle等待事件是衡量oracle運行狀況的重要依據及指示，主要有空閑等待事件和非空閑等待事件
；空閑等待事件是oracle正等待某種工作，在診斷和優(yōu)化數據庫時候，不用過多注重這部分事件，
非空閑等待事件專門針對oracle的活動，指數據庫任務或應用程序運行過程中發(fā)生的等待，這些等待事件是我們在調整數據庫應該關注的。
比較影響性能常見等待事件
db file scattered read
該事件通常與全表掃描有關。因為全表掃描是被放入內存中進行的進行的，
通常情況下它不可能被放入連續(xù)的緩沖區(qū)中，所以就散布在緩沖區(qū)的緩存中。該指數的數量過大說明
缺少索引或者限制使用索引。這種情況也可能是正常的，因為執(zhí)行全表掃描可能比索引掃描效率更高。
當系統存在這些等待時，需要通過檢查來確定全表掃描是否必需的來調整。可以嘗試將較小的表放入
緩存keep中，避免反復讀取它們。
db file sequential read
該事件說明在單個數據塊上大量等待，該值過高通常是由于表間連接順序很糟糕，或者使用了非選
擇性索引。通過將這種等待與statspack報表中已知其它問題聯系起來(如效率不高的sql),通過檢查確
保索引掃描是必須的，并確保多表連接的連接順序來調整
buffer busy wait
當緩沖區(qū)以一種非共享方式或者如正在被讀入到緩沖時,就會出現該等待.該值不應該大于1%,確認
是不是由于熱點塊造成(假如是可以用反轉索引,或者用更小塊大小)
latch free
閂鎖是底層的隊列機制(更加準確的名稱應該是互斥機制)，用于保護系統全局區(qū)(SGA)共享內存結構
。閂鎖用于防止對內存結構的并行訪問。假如閂鎖不可用，就會記錄一次閂鎖丟失。絕大多數得閂鎖問題
都與使用綁定變量失敗(庫緩存閂鎖)、生成重作問題(重執(zhí)行分配閂鎖)、緩存的爭用問題(緩存LRU鏈) 以
及緩存的熱數據寬塊(緩存鏈)有關。當閂鎖丟失率高于0.5%時，需要調整這個問題。
log buffer space
日志緩沖區(qū)寫的速度快于LGWR寫REDOFILE的速度,可以增大日志文件大小，增加日志緩沖區(qū)的大小，或
者使用更快的磁盤來寫數據。
logfile switch
通常是因為歸檔速度不夠快,需要增大重做日志
log file sync
當一個用戶提交或回滾數據時，LGWR將會話得重做操作從日志緩沖區(qū)填充到日志文件中，用戶的進程
必須等待這個填充工作完成。為減少這個等待事件，須一次提交更多記錄，或者將重做日志REDO LOG 文件
訪在不同的物理磁盤上。
