Oracle 内存性能指标

1、报表的目的#

通过几个关键的内存指标，检查当前内存组件配置的合理性，并结合数据库的Advice视图，给出合理的建议值。

2、实现方法与基本逻辑#

通过foglight agent 连接数据库获取相关指标数据，无需额外配置。

二、报表各字段释义#

1、报表各字段的含义#

1.1 共享池大小（Shared_pool size）：当前Shared_pool的大小，单位M

1.2 共享池推荐大小：从v$shared_pool_advice中获取，判断条件是，如果shared增加10%，可以减少2%左右的解析时间，取最大的一个点。Sql语句见下表

select max(shared_pool_size_for_estimate)   from (select shared_pool_size_for_estimate,                nvl((estd_lc_time_saved_factor -                    lag(estd_lc_time_saved_factor, 1)                     over(order by shared_pool_size_factor)),                    estd_lc_time_saved_factor - 1) * 100  as time_save_factor
          from v$shared_pool_advice
         where estd_lc_time_saved_factor > 1.005)  where time_save_factor > 2

1.3 Library cache命中率：library cache命中率定义为(1-reloads/pins)*100%。Reload和Pin的次数的比值，应该小于1%。如果超出了这些数值范围，就说明库缓存的使用有问题。问题的原因主要有两个，没有使用绑定变量或是库缓存太小。不过Reload和Pin的比例过高，也可能是在繁忙时执行了DDL所导致的。

select round((sum(PINS) - sum(RELOADS)) / sum(PINS) * 100,2) Hit_Ratio from v$librarycache

1.4 执行次数大于1的SQL占比：该比值越高越好，如果该比值过低，说明数据库中大部分应用的sql都没有使用绑定变量，应该让开发进行优化。

select round(sum(decode(executions,1,0,1))/count(1)*100,2)  from v$sqlarea

1.5 数据缓存大小（Buffer cache size）：当前Buffer cache的大小，单位M

1.6 数据缓存推荐大小：从v$db_cache_advice获取的DEFAULT cache的建议值。如果数据库参数db_cache_advice是OFF，则该字段显示为OFF，否则判断条件为，如果buffer cache每增加10%的大小，可以减少25%的物理读时间，则进入候选队列，取候选队列中的最大值。Sql语句如下

select max(size_for_estimate)   from (select size_for_estimate,                nvl((lag(estd_physical_read_factor, 1)                     over(order by size_factor) -estd_physical_read_factor ),                    0) * 10 as time_save_factor
          from v$db_cache_advice
         where estd_physical_read_factor <= 1            and name = 'DEFAULT')  where time_save_factor > 0.5

1.7 Buffer命中率：DEFAULT Buffer的命中率，定义为（1-物理读/逻辑读）*100%，逻辑读由两部分组成consistent_gets 和 db_block_gets。一般OLTP系统，buffer命中率应该在95%以上，最严重也不应该低于90%。

select round(((consistent_gets + db_block_gets) - physical_reads) / (consistent_gets + db_block_gets) * 100,2) "Hit Ratio%" from v\$buffer_pool_statistics
where physical_reads > 0 and name = 'DEFAULT'

1.8 PGA大小：当前PGA的大小，单位M

1.9 PGA推荐大小：从v$pga_target_advice视图中获取。重点讲这个视图的estd_pga_cache_hit_percentage是评估的pga命中率，计算公式BYTES_PROCESSED / (BYTES_PROCESSED + ESTD_EXTRA_BYTES_RW)，这个值越大越好。ESTD_OVERALLOC_COUNT字段的值应该为0，如果不为0，说明PGA不足。

select min(pga_target_for_estimate / 1024 / 1024)    from v$pga_target_advice
  where ( estd_pga_cache_hit_percentage,          estd_overalloc_count) in         (select max(estd_pga_cache_hit_percentage),                 min(estd_overalloc_count)            from v$pga_target_advice)

1.10 optimal比例: 使用optimal mode完成排序的比例。
首先需要理解的一个概念是，Oracle在排序的时候要维护一个二叉树，如果这个二叉树很大的话，那么会很消耗CPU资源，因此并非所有东西都在内存排序就是最好的。Oracle完成排序有3种模式
optimal模式：当一个排序进程读取数据源，写到workarea_size_policy 的时候，incoming data和tree没有被填充满就结束了排序的情况，就是optimal模式，这种是性能最好的情况。
one-pass模式：当一个排序吧incoming data和tree填充满以后，如果再继续填充，那么会把工作区里面的数据进行分片，叫sort runs，这个排序运行片归档至临时表空间。那么如果排序很大，就会有很多的sort runs，归档到临时表空间的sort runs还的重新进行一次merge，这里有一个基于排序区的宽度（max intermediate merge width），也就是一次merge的宽度，可以通过10032和10033查看这些内容，比如这里有50个sort runs，这个宽度是100，那么我们merge一次就可以完成，这里就叫做one-pass。
multi-pass模式：如果merge一次，不够，需要多次merge。多次merge，肯定增加IO压力。所以这种是效率最差的。PGA优化主要是消除multi-pass。

SELECT 
       ROUND(optimal_count / total_count * 100, 2) "optimal_pct",        ROUND(onepass_count / total_count * 100, 2) "onepass_pct",        ROUND(multipass_count / total_count * 100, 2) "multipass_pct"   FROM (SELECT SUM(a.total_executions) total_count,                SUM(a.optimal_executions) optimal_count,                SUM(a.onepass_executions) onepass_count,                SUM(a.multipasses_executions) multipass_count
          FROM v\$sql_workarea_histogram a
         WHERE a.total_executions <> 0)

1.11 1-pass比例: 使用one-pass mode完成排序的比例。具体解析见1.10。

1.12 m-pass比例: 使用multi-pass mode完成排序的比例。具体解析见1.10。

2、报表监控的阀值#

共享池推荐大小	Library命中率	执行次数大于1的SQL占比	数据缓存推荐大小	Buffer命中率	PGA推荐大小	optimal比例
有值	<99	<70	有值	<80	有值	<95

三、报表异常处理方法#

1、超过阀值异常处理#

1.1 推荐值非空：系列主管DBA应根据主机资源，数据库的业务类型合理的调整相应的内存组件。

1.2 执行次数大于1的SQL占比低于阀值：系列主管DBA应推动开发使用绑定变量。

1.3 m-pass值过高: 系列主管DBA应根据数据库的业务类型判断是否合理，是否存在sql过量使用排序（不合理的hash join）。