buffer cache实验10-buffer cache优化指标与总结

来源：互联网发布：中级java工程师面试题编辑：程序博客网时间：2024/05/01 02:01

标题吹的有点大了，buffer cache中的不同情况的解决内容其实在前面每一小篇里都有了，没重复粘贴了。

1.buffer cache的大小：

如16CPU,32G内存：
初步分配：
SGA_TARGET=16G --内存一半
BUFFER CACHE=12G ---SGA的40%起，可设置到70%-80%--保守点也可以设置到10G，后期可以根据系统运行情况结合buffer pool advisory进行修改。
shared_pool=3G

当参数：statistics_level为typical 或者all；或者db_cache_advice参数设置为ON，ORACLE会根据系统负载，自动估算出当前实例的buffer cache最佳大小 --通过v$db_cache_advice;或者ASR报告中：buffer pool advisory一栏。之后可以根据建议大小结合当前系统内存使用情况设置一个合理值。
以下为我虚拟机中环境数据：--SIZE_FOR_ESTIMATE单位为M，系统当前BUFFER_CACHE大小为32M。
SYS@ bys3>select SIZE_FOR_ESTIMATE,BUFFERS_FOR_ESTIMATE,ESTD_PHYSICAL_READ_FACTOR,ESTD_PHYSICAL_READS from v$db_cache_advice;
SIZE_FOR_ESTIMATE BUFFERS_FOR_ESTIMATE ESTD_PHYSICAL_READ_FACTOR ESTD_PHYSICAL_READS
----------------- -------------------- ------------------------- -------------------
                4                  496                    2.4576              527548
                8                  992                    2.3653              507728
               12                 1488                    2.2055              473442
               16                 1984                     1.887              405072
               20                 2480                    1.3526              290349
               24                 2976                    1.1332              243258
               28                 3472                    1.0613              227818
               32                 3968                         1              214661
               36                 4464                     .9342              200530
               40                 4960                     .8871              190428
               44                 5456                     .7987              171447
               48                 5952                     .7203              154614
               52                 6448                       .66              141675
               56                 6944                     .6248              134123
               60                 7440                     .5859              125766
               64                 7936                     .5529              118684
从此视图可以看到：系统当前BUFFER_CACHE大小为32M，ESTD_PHYSICAL_READS字段是物理读的块数，ESTD_PHYSICAL_READ_FACTOR字段是物理读/逻辑读的比值，越小越好。
可以看到，BUFFER_CACHE越大，物理读块数越少，物理读/逻辑读的比值越小，所以我这实验环境是要增大BUFFER_CACHE的。可以先增加到64M，然后运行一段时间，再继续结合v$db_cache_advice视图，最终设置一个最优值。

2.buffer cache的命中率

命中率高意味着服务器进程基本上都是从 buffer cache中获取数据块。
但是有的情况下命中率并不能说明性能问题，
如大表全表扫描时buffer cache命中率会下降；
热块问题严重时，虽然buffer cache命中率是100%，性能却不佳；
执行计划出错，所涉及的数据块都在buffer cache中，命中率100%，性能不佳；

3.buffer cache的争用

主要指标是：free buffer waits/buffer busy waits
原因主要也就是：
free buffer waits-找不到空闲 buffer--buffer cache空间不足
buffer busy waits--热块争用

其实在前面的等待事件的博文中，也已经提到过详细解决思路，这里不重新贴了。

DBWR：谁扣动了DBWR的扳机

（1）、三秒超时
I. 检查LRUW
II. 结合硬件能力，查看脏块数、Redo块数，判断恢复时间。如果恢复时间过长，开始增量检查点写。
（2）、关闭数据库或执行完全检查点
（3）、日志切换遇到检查点未完成等待
（4）、OFFLINE表空间或OFFLINE数据文件时
（5）、Truncate 某个对象时
（6）、直接读路径读前。
（7）、_db_block_max_scan_pct，free buffer waits
（8）、_db_large_dirty_queue 脏块数在BUFFER CACHE中比例：达到也要DBWR

OLTP中11G的直接路径读/自适应游标特性 --建议关闭

检查点写和LRUW写的比例

DBWR checkpoint buffers written：由增量检查点机制或日志切换触发，此资料记录所有从CKPT-Q中写到磁盘中的脏块数量。
physical writes from cache：总物理写（块数）
（physical writes from cache-physical writes non checkpoint）：纯增量检查点机制写（不包括日志切换等等）
physical writes from cache-DBWR checkpoint buffers written：从LRUW或其他链表中写出的脏块。
CKPT-Q：主要写脏块

检查点写：目的是为了实例恢复，不考虑脏块的冷、热。
检查点不频繁：
（1）、脏块数过多，增加扫描LRU链表的时间、增加LRU Latch的持有时间。
（2）、实例恢复时间较长。
LRUW写：LRUW写多，对于提升写效率有帮助。可以跳过热脏块，减少写IO块数因为：(1). 热脏块不会被移到LRUW (2). 从LRUW中写的脏块，后被移往辅助LRU。从CKPT-Q中写的脏块，不影响它在LRU中的位置。
MTTR参数：在保证LRU Latch竞争没有大幅度增加情况下，让检查点间隔时间尽量长。

DBWR写和db file parallel write的理解

写IO 等待 aiowait
db file parallel write：和写IO次数并没有对应关系，和batch有关
redo file size 500M ---> 2G，db file parallel write等待时间减少了

0 0