今天是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。可以确定目前数据库负载相对严重。