指标

指标说明

redo size

单位bytes，redosize可以用来估量update/insert/delete的频率，

大的redosize往往对lgwr写日志和arch归档造成I/O压力。

Logical Read

单位  次数*块数， 逻辑读耗CPU，主频和CPU核数都很重要，

逻辑读高则DBCPU往往高，也往往可以看到latch: cache buffer 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时间过多。