buffer cache的优化指标

1）、buffer cache的命中率

命中率高说明sql基本都可以从buffer cache中拿到数据，要比从磁盘快的多

但是也有例外

a、大表全表扫描

如果大表的数据块不在buffer cache中，则对大表进行全表扫描就会产生大量的物理读，进而导致buffer cache的命中率下降，但是业务依然是正常的，多见于OLAP系统中。可见，基线的作用。

b、执行计划错

考虑到极端情况，两张大表，他们所占的数据块全部在buffer cache中，他们等值连接走的是nested loop join执行计划，所以在取值的时候，buffer cache的命中率是100%，但是效率依然低下。

c、热块争用

多个进程同时访问同一个数据块时，会产生热块（热块肯定在buffer cache中），此时buffer cache的命中率会很高，但是会出现latch:cache buffer chain等等待事件。性能依然不好。

以上事件说明，buffer cache的命中率和数据库的性能没有绝对的关系，当然在OLTP系统中还是希望buffer cache越高越好！

在RAC环境中，数据块的传输主要依靠cache fusion，就是说在server process进程发现数据块不在本节点时，会去访问远程节点的buffer cache，若存在且满足传输条件（没有锁等），则由LMS进程将数据块读取到本地的buffer cache中，因此，为了减少传递的次数，在RAC环境中增大本地的local buffer cache命中率显得非常重要，在AWR报告中也有体现。

 

2）、awr报告中buffer cache的一些争用指标

引起buffer cache争用的原因主要有两方面：

a、buffer cache内存不足

b、buffer cache中数据块的争用

在AWR的buffer pool statistics中清晰的描述了buffer cache的争用指标free buffer wait和buffer busy wait

 

P：D  表示是nk buffer pool，若有K则为keep pool，若为R，则为recycle pool

在AWR的buffer wait statistics中显示等待的块的类型

 

除了数据块容易引起争用外，在MSSM的模式下，段头也容易引起争用，当然undo等等会争用

在AWR的 Segments by Buffer Busy Waits中可以看到buffer busy wait的具体对象

 

3）buffer cache的建议值

当数据库参数statistics_level被设置为typical、all，或者db_cache_advice参数被设置为on时，数据库会根据系统负载，自动估算buffer cache的最佳大小

SQL> show parameter db_cache_advice

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

db_cache_advice                      string      ON

SQL> show parameter statistics_level

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

statistics_level                     string      TYPICAL

当然在AWR中也可以看到对buffer cache的建议值

Buffer Pool Advisory中

 

在size Factor=1.0时即为建议值