今天是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————————