latch:cache buffers chain等待事件。

   今天是2014-01-07，今天总结一下latch:cache buffer chain等待事件内容。

之前我记录过关于cache buffer chain的相关笔记，如下：

http://blog.csdn.net/xiaohai20102010/article/details/12587489

 

我自认为这张在网络上广泛流传的图，太有内容价值了。

什么是latch：cache buffers chain？

 当我们需要从cache buffer 中获得数据的时候，需要读取内存中的buffer header信息以此来获得data blocks数据，知道oracle为了提高性能将buffer cache划分了很多bucket，在8i之后每隔latch管理32个bucket，其中bucket中就存在buffer header信息，而bucket为了管理buffer header就有一个链条来穿起这个buffer header信息，这个链条就是cache buffer chain，当一个会话需要获得data blocks信息时候，必须首先获得latch，进而获得data block信息。如果只是查看一下这个buffer header那么latch就可以共享，但是如果独自获得这个buffer header的datablocks，而当有大量用户去征用这个latch的时候，就出现了latch：cache buffer chain。

官方介绍：

The cache buffers chains latches are used to protect a buffer list in the buffer cache. These latches are used when searching for, adding, or removing a buffer from the buffer cache.

Blocks in the buffer cache are placed on linked lists (cache buffer chains) which hang off a hash table. The hash chain that a block is placed on is based on the DBA and CLASS of the block. Each hash chain is protected by a single child latch. Processes need to get the relevant latch to allow them to scan a hash chain for a buffer so that the linked list does not change underneath them.

Contention on this latch usually means that there is a block that is in great contention (known as a hot block).

出现latch:cache buffers chain的原因有哪些？

目前我知道的原因有如下三种：

1、bug，根据每个版本的不同，可以通过support进行查看是否因bug引起。

2、Sequence number generation code that updates a row in a table to generate the number, rather than using a sequence number generator

3、Index leaf chasing from very many processes scanning the same unselective index with very similar predicate

Identify the segment the hot block belongs to

当产生latch：cache buffers chain等待事件如何去分析？

当产生该等待事件，说明了有热块的产生。（除bug）

一、查看v$session_wait_history;

该视图记录了最近等待事件的详细信息，只有新的等待事件出现，才会 刷新该视图。

另外还可以查看v$session视图获得当前等待事件信息。

二、获得latch信息；

根据touch获得热块信息，进而通过x$bh的hladdr与v$latch_children中的latch地址关联获得latch信息：

select name,
       gets,
       misses,
       sleeps,
       immediate_gets,
       immediate_misses,
       spin_gets,
       wait_time
  from v$latch_children a,
       (select *
          from (select ts#,
                       file#,
                       dbarfil,
                       dbablk,
                       state,
                       tch,
                       nxt_hash,
                       hladdr,
                       prv_hash,
                       nxt_repl,
                       prv_repl
                  from x$bh
                 order by tch desc)
         where rownum < 20) b
 where a.ADDR = b.hladdr
   and a.name = 'cache buffers chains'
 order by gets desc;

二、获得热快对象信息：

select a.owner,
       a.segment_name,
       a.tablespace_name,
       a.extent_id,
       a.file_id,
       a.block_id,
       a.bytes,
       a.blocks,
       a.relative_fno
  from dba_extents a,
       (select *
          from (select addr, ts#, dbarfil, dbablk, tch
                  from x$bh
                 order by tch desc)
         where rownum < 20) b
 where a.relative_fno = b.dbarfil
   and a.block_id + a.blocks > b.dbablk
   and a.block_id < b.dbablk;

三、获得导致热块相关的sql信息。

从目前来看x$bh没有与sql id或是hash value相关的字段，可是我们获得了object，那么可以通过模糊查询找到涉及到该征用object的sql语句信息。

如下：

select sql_text
  from v$sqltext a,
       (select distinct a.owner, a.segment_name, a.segment_type
          from dba_extents a,
               (select dbarfil, dbablk
                  from (select dbarfil, dbablk from x$bh order by tch desc)
                 where rownum < 11) b
         where a.RELATIVE_FNO = b.dbarfil
           and a.BLOCK_ID <= b.dbablk
           and a.block_id + a.blocks > b.dbablk) b
 where a.sql_text like '%' || b.segment_name || '%'
   and b.segment_type = 'TABLE'
 order by a.hash_value, a.address, a.piece;

四、找到sql查看sql相关信息，如执行计划获得索引信息啊，是否需要频繁获得数据啊，进而与应用进行沟通。

下面是之前我一个同事给我的关于该等待事件的一个awr，下面进行分析一下：

db time所有前天session花费在database的时间，包括db cputime，i/0 time,非空闲等待时间，cpu on queue time。可以确定目前数据库负载相对严重。

从load profile中看到，逻辑读相对很高，反应出消耗 db cpu time很高，进而有可能出现latch：cache buffers chain等待事件。林外从executes看出sql执行频率相对较高。

从top 5中可以看到目前latch：cache buffers chains是主要的问题等待事件。

sql 执行时间消耗很大，db cpu相对很高，看到这里，我们就可以直接查看sql 逻辑读信息，热点对象信息，latch堵塞信息、

可以 看出存有大量的逻辑读，且sql涉及对象相同，在这个地方，就应该查看一下sql信息了。

对比一下，可以看到globalid存在差异，需要进一步看一下执行计划，获得敏感谓词信息。（因为该awr已经长久，没办法获得执行计划了。但问题却表现出来了。）和应用开发人员进行sql沟通处理了。

查看segment 统计信息；

敏感segment是索引，至此产生了问题关键index：

查看：Instance Activity Stats如下：

顺便在看一下latch statistics：

index scans kdiix1：估计是sql执行计划出现了问题，出现了b 树到位图的转换。需要收集一下该索引的统计信息，使用dbms_stats.gather_index_stats估计问题解决了。

 

这是我处理该问题的一个思路。

 

#############################################################################——————Rhys————————