4.2 buffer cache的统计信息

   为了对buffer cache进行性能的诊断，oracle提供了很多有关buffer cache的统计信息。这些统计信息大致可以分成三类：1）有关用户发出的对内存数据块的请求相关的统计信息；2）有关DBWR后台进程对内存数据块处理相关的统计信息；3）RAC相关的统计信息。

      我们在诊断buffer cache时，不需要关注所有的统计信息。这里主要介绍几个重要的统计信息，其他的统计信息都可以到《Oracle9i Database Reference: Appendix C》中找到。如下所示：

SQL> SELECT name, value FROM v$sysstat  WHERE name in (
  2      'session logical reads',
  3      'physical reads',
  4      'physical reads direct',
  5      'physical reads direct (lob) ',
  6      'consistent gets',
  7      'db block gets',
  8      'free buffer inspected')
  9  /
NAME                                                                  VALUE
---------------------------------------------------------------- ----------
session logical reads                                                 73797
db block gets                                                           498
consistent gets                                                       73299
physical reads                                                        29017
free buffer inspected                                                     0
physical reads direct                                                    40

  这里做些简单的解释。
     1) session logical reads：所有的逻辑读的数据块的数量。注意，其中包括先从硬盘上读数据块到内存里，再从内存里读数据块。
    2) consistent gets：在一致性（consistent read）读模式下读取的内存里的数据块数量。包括从rollback segment里读取的数据块数量以及从data block buffer里读取的数据块数量。主要是通过select产生的。Update/delete也能产生很少量的此类数据块。注意：如果oracle的运行时间过长，由于oracle的bug导致consistent gets大大超过实际的数量。因此建议使用‘no work - consistent read gets’, ‘cleanouts only - consistent read gets’,‘rollbacks only - consistent read gets’, ‘cleanouts and rollbacks - consistent read gets’之和来代替consistent gets的值。
    3) db block gets：在当前（current）模式下读取的内存里的数据块的数量。不是读取过去某个时点的数据块，而必须是当前最新的数据块。主要是通过update/delete/insert来产生的，因为DML需要当前最新的数据块才能对之进行改变。在字典管理表空间下，一些获得当前可用扩展空间的select语句也会产生此类数据块，因为必须得到当前最新的空间使用信息才能扩展。逻辑上，session logical reads = consistent gets + db block gets。
    4) physical reads：从硬盘里读取的数据块的数量。注意，这个数量大于实际从硬盘里读取的数量，因为这部分block也包括了从操作系统缓存里读取的数据块数量。
    5) physical reads direct：有些数据块不会先从硬盘读入内存再从内存读入PGA再传给用户，而是绕过SGA直接从硬盘读入PGA。比如并行查询以及从临时表空间读取数据。这部分数据块由于不缓存使得hit ratio不会被提高。
    6) physical reads direct (lob)：与physical reads direct一样。
    7) free buffer inspected：这个值表示为了找到可用数据块而跳过的数据块的数量。这些被跳过的数据块就是脏的或被锁定的数据块。明显，这个值如果持续增长或很高，就需要增加buffer cache的大小了。

   在获得了这些统计信息以后，我们可以计算buffer cache的命中率：

1Hit Ratio = 1 – (physical reads – physical reads direct
- physical reads direct (lob) ) / session logical reads
2Miss ratio = (physical reads – physical reads direct-
physical reads direct (lob) ) / session logical reads

   通常在OLTP下，hit ratio应该高于0.9。否则如果低于0.9则需要增加buffer cache的大小。在考虑
 调整buffer cache hit ratio时，需要注意以下几点。
    1) 如果上次增加buffer cache的大小以后，没有对提高hit ratio产生很大效果的话，不要盲目增加buffer cache的大小以提高性能。因为对于排序操作或并行读，oracle是绕过buffer cache进行的。
    2) 在调整buffer cache时，尽量避免增加很多的内存而只是提高少量hit ratio的情况出现。
我们还可以查询每种buffer cache的统计信息，主要关注的还是consistent_gets和db_block_gets以及
 physical_reads的值。

SQL> SELECT name, block_size,physical_reads, db_block_gets,consistent_gets
  2  FROM v$buffer_pool_statistics;
NAME                 BLOCK_SIZE PHYSICAL_READS DB_BLOCK_GETS CONSISTENT_GETS
-------------------- ---------- -------------- ------------- ---------------
DEFAULT                    8192          28978           719           77591
DEFAULT                   16384              2            80              11

      v$sysstat中名称以DBWR开头的都是有关DBWR后台进程相关的统计信息。当DBWR进程写完脏数据块以后或者扫描完LRU链表以后更新这些统计信息。DBWR会基于被触发的频率以及所处理的内存数据块的数量与总内存数据块的数量的比例，来进行自我调整。我们可以通过这些统计信息得到一些对当前DBWR运行情况的认识。