如何鉴别在数据库Buffer Cache中热块

适用于：
-------
Oracle Server - Enterprise Edition
本文信息适用于所有平台。

目标
------
如何鉴别造成'cache buffers chains'latch争用的热块。
如何鉴别数据库Buffer Cache中的热块。

解决方案
---------
发生或急剧增加大量CACHE BUFFERS CHAINS的latch等待事件，通常可能是由于热块引起的。
该latch的获得需要通过搜索buffer cache中cache的数据块。因为Buffer Cache由数据块的chain的总和构成，当需要扫描时，每个chain被该latch的child保护。这可能要求重新检查应用：
Note 42152.1 LATCH:CACHE_BUFFERS_CHAINS(该文档为内部文档)
解决热块问题，可能需要从应用方面考虑。

通过检查该等待发生的latch，可以通过下面的查询获得segment和特定block的信息。

首先要确定那些sleep次数较多的latch的latch id(ADDR)，越高的sleep次数，越应该关注：
SQL> select CHILD#  "cCHILD"
     ,      ADDR    "sADDR"
     ,      GETS    "sGETS"
     ,      MISSES  "sMISSES"
     ,      SLEEPS  "sSLEEPS"
     from v$latch_children
     where name = 'cache buffers chains'
     order by 5, 1, 2, 3;

上面的查询可能会运行一段时间，确定存在大量争用导致sleep的id(ADDR)。一旦找到了最高sleep次数的id(ADDR)，通过该latch地址可以获得在buffer cache中该latch保护的数据块的更多详

细信息。

下面这个查询可以在确定了最高sleep次数的ADDR之后运行：
SQL> column segment_name format a35
     select /*+ RULE */
       e.owner ||'.'|| e.segment_name  segment_name,
       e.extent_id  extent#,
       x.dbablk - e.block_id + 1  block#,
       x.tch,
       l.child#
     from
       sys.v$latch_children  l,
       sys.x$bh  x,
       sys.dba_extents  e
     where
       x.hladdr  = 'ADDR' and
       e.file_id = x.file# and
       x.hladdr = l.addr and
       x.dbablk between e.block_id and e.block_id + e.blocks -1
     order by x.tch desc ;

由于查询内部视图，会查询较久的时间，以下是输出的例子:
SEGMENT_NAME                     EXTENT#      BLOCK#       TCH    CHILD#
-------------------------------- ------------ ------------ ------ ----------
SCOTT.EMP_PK                       5            474          17     7,668
SCOTT.EMP                          1            449           2     7,668

可以根据TCH列(块被SQL语句命中的次数总数)来决定热块。较高的TCH值，说明块被SQL语句频繁地访问。

为了减少在该对象上的争用，可以通过以下几种方式：
1)检查应用，查看是否有DML和SELECT语句可以改进，消除对象的争用。
2)减少buffer cache，虽然这只能在较少数系统中有用。
3)DBWR吞吐量也是一个重要要素，如果可以，增加多个DBWR。
4)通过ALTER TABLE或重建，增大PCTFREE的表存储参数，这样可以让每个块存在更少的行。
5)考虑使用反向索引(如果范围扫描并不常见)

相关BUG：
Bug 3611471 : High latch waits for "cache buffers chain" latch possible originating from "kcbgtcr: kslbegin .."

30 min statspack shows
NoWait Waiter
Latch Name           Where                      Misses  Sleeps     Sleeps
-------------------- -------------------------- ------- ---------- --------
cache buffers chains kcbgtcr: kslbegin excl        0      206,281   280,674

Bug 1967363 "CACHE BUFFERS CHAINS" LATCH CONTENTION AFTER UPGRADE
TO 8.1.7 FROM 8.0.6

下面这个查询结合了DBA_OBJECTS。

SQL> with bh_lc as
       (select /*+ ORDERED */
          lc.addr, lc.child#, lc.gets, lc.misses, lc.immediate_gets,
          lc.immediate_misses, lc.spin_gets, lc.sleeps,
          bh.hladdr, bh.tch tch, bh.file#, bh.dbablk, bh.class,
          bh.state, bh.obj
        from
          x$kslld ld,
          v$session_wait sw,
          v$latch_children lc,
          x$bh bh
        where lc.addr =sw.p1raw
          and sw.p2= ld.indx
          and ld.kslldnam='cache buffers chains'
          and lower(sw.event) like '%latch%'
       -- and state='WAITING'
          and bh.hladdr=lc.addr
       )
     select bh_lc.hladdr, bh_lc.tch, o.owner, o.object_name, o.object_type,
            bh_lc.child#, bh_lc.gets,
            bh_lc.misses, bh_lc.immediate_gets,
            bh_lc.immediate_misses, spin_gets, sleeps
     from
       bh_lc,
       dba_objects o
     where bh_lc.obj = o.object_id(+)
   union
     select bh_lc.hladdr, bh_lc.tch, o.owner, o.object_name, o.object_type,
            bh_lc.child#, bh_lc.gets, bh_lc.misses, bh_lc.immediate_gets,
            bh_lc.immediate_misses, spin_gets, sleeps
     from
       bh_lc,
       dba_objects o
     where bh_lc.obj = o.data_object_id(+)
  order by 1,2 desc;

相关信息：
BUG:3611471 - FPFACCEP: APPS PERFORMANCE ISSUE(CACHE BUFFERS CHAIN WAITS) - BUG#3608873