深入理解latch:cachebufferschains

事件背景:   
一个客户的数据库发生了宕机事件,查看了数据库的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后才能访问,整个访问的结构如图:深入理解latch: cache buffers chains 
用户内存中读数据的顺序:
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: cache buffers chains
显示存大量的latch等待;

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

深入理解latch: cache buffers chains 

深入理解latch: cache buffers chains

深入理解latch: cache buffers chains 深入理解latch: cache buffers chains

总结以上的特征:
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管理 )  

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


当前题目:深入理解latch:cachebufferschains
URL地址:http://scyanting.com/article/gigjgi.html