事件背景：   
一个客户的数据库发生了宕机事件，查看了数据库的awr报告，原来是由于出现大量的latch: cache buffers chains等待事件导致系统消耗量大量的CPU，最终导致系统hang住；

说明：   
要理解latch: cache buffers chains并解决这个问题，就需要深入的了解Buffer Cache及其原理。
1、Buffer Cache概述：   
Buffer Cache是SGA的一部分，Oracle利用Buffer Cache来管理data block，Buffer Cache的最终目的就是尽可能的减少磁盘I/O。Buffer Cache中主要有3大结构用来管理Buffer Cache：Hash Bucket、Hash Chain List、LRU List；   
Hash Bucket & Hash Chain List ：Hash Bucket与Hash Chain List用来实现data block的快速定位。   
LRU List ：挂载有指向具体的free buffer, pinned buffer以及还没有被移动到 write list的dirty buffer 等信息。所谓的free buffer就是指没有包含任何数据的buffer，所谓的pinned buffer，就是指当前正在被访问的buffer。   
Write(Dirty)List ：挂载有指向具体的 dirty block的信息。所谓的dirty block，就是指在 buffer cache中被修改过但是还没有被写入到磁盘的block。

2、Hash Bucket的原理：   
如果所有的Buffer Cache中所有的Buffer都通过同一个结构管理，当需要确定某个Block在Buffer中是否存在时，将需要遍历整个结构，性能会相当低下；   
为了提高效率，Oracle引入了Bucket的数据结构，Oracle把管理所有的Buffer通过一个内部的Hash算法运算后，存放到不同Hash Bucket中，这样通过Hash Bucket进行分割之后，众多的Buffer被分布到一定数量的Bucket之中，当用户需要在Buffer中定位数据是否存在是，只需要通过同样的算法获得Hash值，然后到相应的Bucket中查找少量的Buffer即可确定。每个Buffer存放的Bucket由Buffer的数据块地址运算决定；（这个算法从ORACLE官方得到的信息很少，可以用索引的知识去理解）Bucket内部，通过Cache Buffer Chain将所有的Buffer通过Buffer Header信息联系起来； 
为了保护Bucket中的数据，每次访问的时候都需要先在内存中获取latches后才能访问，整个访问的结构如图： 
用户内存中读数据的顺序：
a) 对该Block运用Hash算法，得到Hash值。
b）获得获得cache buffers chains latch

c) 到相应的Hash Bucket中搜寻相应Buffer Header
b）获得cache buffers chains latch；
d) 如果找到相应的Buffer Header，然后判断该Buffer的状态，看是否需要构造CR Block，或者Buffer处于pin的状态，最后读取。e) 如果找不到，就从磁盘读入到Buffer Cache中。

3、latch:cache buffers chains等待事件     
在Oracle9i以前，如果其它用户进程已经获得了这个latch，那么新的进程就必须等待，直到该用户进程搜索完毕(搜索完毕之后就会释放该latch)。从Oracle9i开始 cache buffers chains latch可以只读共享，也就是说用户进程A以只读(select)的方式访问Block，这个时候获得了该latch，同时用户进程B也以只读的方式访问Block，那么这个时候由于是只读的访问，用户进程B也可以获得该latch。但是，如果用户进程B要以独占的方式访问Block，那么用户进程B就会等待用户进程A释放该latch，这个时候Oracle就会对用户进程B标记一个latch:cache buffers chains的等待事件。

4、latch:cache buffers chains出现的原因   
4.1 不够优化的SQL。   
大量逻辑读的SQL语句就有可能产生非常严重的latch:cache buffers chains等待，因为每次要访问一个block，就需要获得该latch，由于有大量的逻辑读，那么就增加了latch:cache buffers chains争用的机率。   对于正在运行的SQL语句，产生非常严重的latch:cache buffers chains争用，可以利用下面SQL查看执行计划，并设法优化SQL语句。
select * from table(dbms_xplan.display_cursor('sql_id',sql_child_number));   
如果SQL已经运行完毕，我们就看AWR报表里面的SQL Statistics->SQL ordered by Gets->Gets per Exec，试图优化这些SQL。

4.2热点块争用  
 1）查找数据库是否存在latch的争用
select sid,event,p1text,p1raw from v$session_wait where event='latch: cache buffers chains';   

2)下面查询查出Top 5 的争用的latch address。
select * from( select CHILD#,ADDR,GETS ,MISSES,SLEEPS from v$latch_children where name = 'cache buffers chains' and misses>0 and sleeps>0 order by 5 desc, 1, 2, 3) where rownum<6; 

3)然后利用下面查询找出Hot block。    
 select /*+ RULE */       e.owner ||'.'|| e.segment_name  segment_name,       e.extent_id  extent#,       x.dbablk - e.block_id + 1  block#,       x.tch, /* sometimes tch=0,we need to see tim */x.tim ,l.child#     from       v$latch_children  l,       x$bh  x,       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 ;       e.owner ||'.'|| e.segment_name  segment_name,       e.extent_id  extent#,       x.dbablk - e.block_id + 1  block#,       x.tch, /* sometimes tch=0,we need to see tim */x.tim ,l.child#     from       v$latch_children  l,       x$bh  x,       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 ; 

4.3 Hash Bucket太少   需要更改_db_block_hash_buckets隐含参数。其实在Oracle9i之后，我们基本上不会遇到这个问题了，除非遇到Bug。所以这个是不推荐的，记住，在对Oracle的隐含参数做修改之前一定要咨询Oracle Support。 

5、latch:cache buffers chains的模拟测试
5.1 创建表
SQL> create table john (no int,object_name varchar2(50)); 

5.2  插入数据S
QL> declare i int;beginfor i in 1..5 loopinsert into john  select  rownum as no,object_name from dba_objects;end loop;end;/ 

5.3 创建存储过程SQL> create or replace procedure p_john isi int;icount int;beginfor i in 1..1000 loopselect count(*) into icount from john;end loop;end;/ 

5.4 模拟20并发全表扫描
SQL> var job_no number;S
QL> beginfor idx in 1..20 loopdbms_job.submit(:job_no,'p_john;');commit;end loop ;end;/ 

5.5查看争用情况
SQL> select sid,event,p1text,p1raw from v$session_wait where event='latch: cache buffers chains';
显示存大量的latch等待；

 5.6  latch: cache buffers chains等待事件在awr报告中的特征  

 

 

总结以上的特征：
a)  占用大量的CPU资源；
b)  逻辑读比正常情况要多很多；
c)  等待事件里面肯定有latch: cache buffers chains
d)  Latch的命中率一般在95%以下，严重的在90%以下；

6、latch:cache buffers chains的个人解决方法很多时候应用的问题，其实是由于SQL质量导致的，很多DBA吐槽：DBA和开发是不同的部门，所以要让开发配合起来进行SQL调优难度较大，可行性较小。对于这种观点本人表示不赞同：当系统出现大的问题的时候，会导致系统性能下降，甚至宕机，那么如果这个系统重要的话，那么DBA完全可以把问题的原因及解决方法发送给开发人员，并抄送公司领导，并说明原因及解决的方法，由于这个时候DBA是唯一知道问题的根源及解决方法的，所以领导也会支持你的；另外：SQL调优是最有效的调优方法，建议DBA别从系统的角度去进行处理，避免填了一个坑又冒出一个坑；

 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

本文作者：JOHN

ORACLE技术博客：ORACLE 猎人笔记               数据库技术群：367875324 （请备注ORACLE管理 ）  

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++