指標

指標說明

redo size

單位bytes，redosize可以用來估量update/insert/delete的頻率，

大的redosize往往對lgwr寫日誌和arch歸檔造成I/O壓力。

Logical Read

單位  次數*塊數， 邏輯讀耗CPU，主頻和CPU核數都很重要，

邏輯讀高則DBCPU往往高，也往往可以看到latch: cache buffers chains等待。 

Block changes

單位次數*塊數 ， 描繪資料變化頻率

Physical Read

單位次數*塊數， 物理讀消耗IO，體現在IOPS和吞吐量等不同維度上；但減少物理讀可能意味著消耗更多CPU。

physical read包含了physical reads cache和physical reads direct

Physical writes

單位次數*塊數，主要是DBWR寫datafile，也有direct path write。

dbwr長期寫出慢會導致定期log file switch(checkpoint no complete) 檢查點無法完成的前臺等待。 

physical write 包含了physical writes direct +physical writes from cache

User Calls

單位次數，使用者呼叫數

Parses

解析次數，包括軟解析+硬解析；

軟解析每秒超過300次意味著”應用程式”效率不高，調整session_cursor_cache。

Hard Parses

萬惡之源，Cursor pin s on X， library cache: mutex X ， latch: row cache objects /shared pool…

 硬解析最好少於每秒20次，每秒超過100次，說明繫結使用的不好，也可能共享池設定不合理。

W/A MB processed

單位MB  W/A workarea  workarea中處理的資料數量結合 In-memory Sort%， sorts (disk) PGA Aggr一起看

Transactions

每秒事務數，是資料庫層的TPS，可以看做壓力測試或比對效能時的一個指標，孤立看無意義。

% Blocks changed per Read

每次邏輯讀導致資料塊變化的比率；如果’redo size’, ‘block changes’ ‘pct of blocks changed per read’,三個指標都很高，說明系統正執行大量insert/update/delete;

Rollback per transaction %

事務回滾比率。  Rollback per transaction %= (rollback)/(transactions)
回滾率過高,說明資料庫經歷了太多的無效操作 ,過多的回滾還會帶來Undo Block的競爭。

Rows per Sort

平均每次排序涉及到的行數 ;  Rows per Sort= ( sorts(rows) ) / ( sorts(disk) + sorts(memory))

Buffer Nowait %

session申請一個buffer(相容模式)不等待的次數比例，需要訪問buffer時立即可以訪問的比率；
一般大於99%，否則可能存在爭用。

buffer HIT%

快取記憶體命中率，反映物理讀和快取命中間的糾結，這個指標即便99% 也不能說明物理讀等待少了；
小於90%，可能要加db_cache_size；
db_cache_size過小引起大量的db file sequential /scattered read等待事件；
與 buffer HIT%相關的指標有 table scans(long tables) 大表掃描，
此外相關的還有Buffer Pool Statistics 、Buffer Pool Advisory等。

 Redo nowait%

session在生成redo entry時不用等待的比例，redo相關的資源爭用，小於90%,考慮增加log buffer；
redo space request爭用可能造成生成redo時需求等待，需要關注是否有十分頻繁的 log switch ；
過小的redo logfile size 如果配合較大的SGA和頻繁的commit提交都可能造成該問題；
考慮增大redo logfile : 1~4G 每個，7~10組都是合適的，同時考慮優化redo logfile和datafile 的I/O。

In-memory Sort%

在記憶體中完成的排序比率 ；In-memory Sort% =  sort(memory) / ( sort(disk)+ sort(memory) )
低於95%，通過適當調大初始化引數PGA_AGGREGATE_TARGET或SORT_AREA_SIZE。

library cache命中率，合理值：>95% ，否則加大共享池，使用繫結變數，修改cursor_sharing等引數；
保持shared pool有足夠的Free Memory，且沒有過多的記憶體碎片；
保證SQL語句繫結變數和遊標可以共享。

快照時間內軟解析次數和總解析次數 (soft+hard 軟解析次數+硬解析次數)的比值；
若指標很低，說明可能存在大量的hard parse硬解析；
大量的硬解析會消耗更多的CPU併產生解析爭用(此時可以考慮使用cursor_sharing=FORCE)；
通過設定 session_cached_cursors引數和反覆重用遊標可以讓解析更輕量級；
小於<95%,需要考慮繫結，低於80%，可以認為sql基本沒有被重用。

執行解析比 ，公式為 1-(parse/execute)，目標為100%；
Execute to Parse和soft parse% 都很低 說明確實沒有繫結變數 ；
如果 soft parse% 接近99% 而Execute to Parse 不足90% 說明沒有執行；
解析比低， 需要通過靜態SQL、動態繫結、session_cached_cursor、open cursors等減少軟解析。

(Execute次數 - Parse次數)/Execute次數 x 100%
如偏小，說明解析(硬解析和軟解析)的比例過大，快速軟解析比例小。
根據實際情況，適當調整引數session_cursor_cache，提高會話中sql執行的命中率。
如為負數，通常說明shared pool設定或者語句效率存在問題，造成反覆解析，reparse可能較嚴重,
或者是可能同snapshot有關，通常說明資料庫效能存在問題。

申請不要等待的比率，Latch Hit%:=  (1 – (Sum(misses) / Sum(gets)))
Latch Hit>99%，否則Shared Pool latch爭用，可能未共享的SQL，或Library Cache太小，
可使用繫結變數或增大Shared Pool。

shared pool的空間使用率，穩定在75%-90%
太低，表明共享池設定過大，
一直很高，關注sga breakdown中的shared pool free memory，
推薦free memroy 至少300~500MB ，以避免隱患。

複用的SQL佔總的SQL語句的比率，
如太小，在應用中更多使用繫結變數，避免過多SQL解析

 % Memory for SQL

w/exec>1 

% Non-Parse CPU

CPU非分析時間在整個CPU時間的百分比，查詢實際執行時間/(查詢實際執行時間+sql解析時間)
太低，表示解析消耗CPU時間過多。