~~~~~~~~~~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 那么等待事件按等待的時間排序
= 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
