statspack分析

Load Profile
~~~~~~~~~~Per Second Per Transaction
--------------- ---------------
Redo size: 22,007.09 2,921.10 --很重要的引數，表示你資料變更頻率
Logical reads: 22,890.62 3,038.38
Block changes: 95.88 12.73
Physical reads: 5,413.37 718.54
Physical writes: 5.67 0.75
User calls: 750.85 99.66
Parses: 183.20 24.32 ----軟解析每秒超過300次意味著你的"應用程式"效率不高，
沒有使用soft soft parse，調整session_cursor_cache
Hard parses: 20.41 2.71 --每秒超過100次，就可能說明你繫結使用的不好
Sorts: 5.17 0.69
Logons: 0.03 0.00
Executes: 185.17 24.58
Transactions: 7.53

% Blocks changed per Read: 0.42 Recursive Call %: 21.95 --如果有很多PLSQL，那麼他就會比較高
Rollback per transaction %: 0.01 Rows per Sort: 159.13 --看回滾率是不是很高，因為回滾很耗資源

Instance Efficiency Percentages (Target 100%)
--這一部分透過可以提前找出ORACLE潛在將要發生的效能問題（所以很重要哦）
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.71 Redo NoWait %: 100.00
--Buffer Nowait<99%說明，有可能是有熱塊(查詢x$bh的 tch和v$latch_children的cache buffers chains)
Buffer Hit %: 76.54 In-memory Sort %: 100.00
--Buffer Hit<95%,重要的引數,小於95%可能是要加db_cache_size,但是大量的非選擇的索引也會造成該值很高（大量的db file sequential read）
Library Hit %: 97.07 Soft Parse %: 88.86
--Library Hit<95%,要考慮加大共享池，繫結變數，修改cursor_sharing等
Execute to Parse %: 1.06 Latch Hit %: 99.76
--Soft Parse<95%,需要考慮到繫結，如果低於80%，那麼就可能sql基本沒有被重用
Parse CPU to Parse Elapsd %: 89.28 % Non-Parse CPU: 91.37
--Latch Hit<99%,要確保>99%，否則存在嚴重的效能問題，比如繫結等會影響該引數

如果一個經常訪問的列上的索引被刪除，可能會造成buffer hit 顯著的下降
如果增加了索引，但是他影響了ORACLE正確的選擇表連線時的驅動順序，那麼可能會導致buffer hit 顯著增高
如果你的命中率變化幅度很大，說明你要改變SQL模式


Shared Pool Statistics
Begin End
------ ------
Memory Usage %: 89.18 85.56 --共享記憶體使用情況 70%-98%都在正常範圍
% SQL with executions>1: 36.31 36.10 --
% Memory for SQL w/exec>1: 38.86 38.33


Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 2,913 32.01
db file sequential read 2,142,279 2,820 30.99
db file scattered read 1,724,832 1,183 13.00
buffer busy waits 198,624 1,042 11.44
log file sync 22,857 915 10.06

TIMED_STATISTICS = TRUE 那麼等待事件按等待的時間排序
TIMED_STATISTICS = FALSE那麼事件按等待的數量排序

常見事件
LOG FILE SYNC: 在每次提交時都出現，如果這個等待事件影響到資料庫效能，那麼就需要修改應用程式的提交頻率

db file sequential read: 在單個資料塊上大量等待，該值過高通常是由於表間連線順序很糟糕，或者使用非選擇性的索引

DB_CACHE_SIZE: 可以決定該事件出現的頻率

db file scattered read : 意味著等待於全表掃描有關係,通常全表掃描表資料放入記憶體中,但是被申請到的記憶體高速緩衝的每個區可能不連續,該值過大說明缺少索引或者限制了索引的使用(也可以調整optimizer_index_cost_adj) ,如果經常必須進行全表掃描,而且表比較小, 把該表存人keep池.如果是大表經常進行全表掃描,那麼應該是olap系統,而不是oltp的

buffer busy wait: 當緩衝區以一種非共享方式或者如正在被讀入到緩衝時,就會出現該等待.該值不應該大於1%,確認是不是由於熱點塊造成(如果是可以用反轉索引,或者用更小塊大小)

latch free: 常跟應用沒有很好的應用繫結有關

Enqueue : 最有可能是多個使用者同時修改同一個塊,如果沒有空閒的ITL空間,就會出現資料庫塊級鎖

logfile switch: 通常是因為歸檔速度不夠快,需要增大重做日誌

log buffer space: 日誌緩衝區寫的速度快於LGWR寫REDOFILE的速度,可以增大日誌檔案大小

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
......
......
大家來補充，最好結合例項進行分析,我在資源中心裡放上了statspack的一些資料，有興趣可以看看。[@more@]