latch：cache buffers chains的优化思路

标签：

 数据块在buffer cache存放是以linked list方式存放的。当一个session想要访问/修改buffer cache的block,首先需要通过hash算法检查该block是否存在于buffer cache中，检查相同的SQL语句是否存在于library cache中也是通过hash算法实现的。要判断block是否存在于buffer cache中，就需要扫描linked list(此处都是串行的，不能并发)，获取block的信息。而扫描linked list必须获得一个latch，防止并发对linked list照成破坏，如果未能获得该latch，就会在数据库中标记一个latch: cache buffers chains这个等待事件。如果该block存在于buffer cache中就不需要物理读，如果不存在，就需要从磁盘读取该block到buffer cache中。为了能够读取，并修改该block，我们就需要pin住该block,防止并发对于该block造成破坏，所以如果别的session不能获得pin，同时会标记一个buffer busy waits等待事件。

一般产生CACHE BUFFERS CHAINS的原因有几个方面:1、buffer cache太少(也说明SQL语句效率低);2、热块挣用。(从oracle9i开始，对latch:cache buffer chains支持只读共享访问，这可以减少部分争用，但并不能完全消除争用。)

一、buffer cache太少(也说明SQL语句效率低)

应用程序执行多个相同的低效率SQL语句并发会话，这些SQL语句都设法得到相同的数据集。较多的逻辑读意味着较多的latch get操作，从而增加了锁存器争用。多个进程同时扫描大范围的索引或表时，可能广泛地发生cache buffers chains 锁存器争用。每次执行都带有高 BUFFER_GETS(逻辑读取)的SQL语句是主要的原因。

1、查看当前的等待事件 （ latch: cache buffers chains）

SQL> select event, count(*) from v$session

 where wait_class <> ‘Idle‘ group by event order by 2;

2、查看 latch: cache buffers chains事件相关的会话信息

SQL> select sid,username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event=‘latch: cache buffers chains‘;

二、热块挣用

当多个会话重复访问一个或多个由同一个子cache buffers chains锁存器保护的块时，就会产生热块挣用。当多个会话争用cache buffers chains锁存器时，找出是否有热块的最好的方法是检查latch free等待事件的P1RAW参数值。

判断热块挣用的另一种方法是从 v$session_wait 视图获得锁存器地址后进行比较。v$session_wait的P1RAW就相当于子锁存器地址，若从 v$session_wait 视图获得的锁存器地址过多重复出现，就意味着对相应锁存器发生次数偏多，此时可解释为热快引起的争用。如果会话正在相同的锁存器地址上等待，就是热块。

SQL> select sid,p1raw,p2,p3,seconds_in_wait,wait_time,state from v$session_wait

where event=‘latch: cache buffers chains‘ order by 3,2;

查看热块的对象：

根据TCH值确认热块。注意块从LRU列表的冷端移动到热端时，TCH值将重置为0,所以判断的时候，要注意TCH为0的块不一定是冷块。

使用P1RAW=00000300DA316800为例子进行关联热快对象。

SQL> select a.hladdr,a.file#,a.dbablk,a.tch,a.obj,b.object_name from x$bh a, dba_objects b

where (a.obj = b.object_id or a.obj = b.data_object_id) and a.hladdr = ‘00000300DA316800‘

union select hladdr,file#,dbablk,tch,obj,null from x$bh

where obj in (select obj from x$bh where hladdr = ‘00000300DA316800‘ minus select object_id from dba_objects minus select data_object_id from dba_objects) and hladdr = ‘00000300DA316800‘ order by 4;

若没有关于SQL语句的信息，也有方法间接判断是热块引起的问题，还是低效SQL语句引起的问题。v$latch_children视图中，比较子cache buffers chains锁存器相应的 child#、gets、sleeps值， 以此判断特定子锁存器上使用的次数和争用是否集中，利用以下语句，获取sleeps次数高的子锁存器。

SQL> select * from (select addr, child#, gets, sleeps from v$latch_children where name = ‘cache buffers chains‘ order by sleeps desc)

where rownum < =20;

当结果中sleeps的值倾斜较大的时候就说明是热块挣用。

根据sleeps较高的addr确定哪些块是热块。

SQL> select hladdr,obj,(select object_name from dba_objects where (data_object_id is null and object_id = x.obj) or data_object_id = x.obj and rownum = 1) as object_name,dbarfil,dbablk,tch from x$bh x where hladdr =‘&p1raw‘ order by hladdr, obj;

 数据块在buffer cache存放是以linked list方式存放的。当一个session想要访问/修改buffer cache的block,首先需要通过hash算法检查该block是否存在于buffer cache中，检查相同的SQL语句是否存在于library cache中也是通过hash算法实现的。要判断block是否存在于buffer cache中，就需要扫描linked list(此处都是串行的，不能并发)，获取block的信息。而扫描linked list必须获得一个latch，防止并发对linked list照成破坏，如果未能获得该latch，就会在数据库中标记一个latch: cache buffers chains这个等待事件。如果该block存在于buffer cache中就不需要物理读，如果不存在，就需要从磁盘读取该block到buffer cache中。为了能够读取，并修改该block，我们就需要pin住该block,防止并发对于该block造成破坏，所以如果别的session不能获得pin，同时会标记一个buffer busy waits等待事件。 一般产生CACHE BUFFERS CHAINS的原因有几个方面:1、buffer cache太少(也说明SQL语句效率低);2、热块挣用。(从oracle9i开始，对latch:cache buffer chains支持只读共享访问，这可以减少部分争用，但并不能完全消除争用。) 一、buffer cache太少(也说明SQL语句效率低) 应用程序执行多个相同的低效率SQL语句并发会话，这些SQL语句都设法得到相同的数据集。较多的逻辑读意味着较多的latch get操作，从而增加了锁存器争用。多个进程同时扫描大范围的索引或表时，可能广泛地发生cache buffers chains 锁存器争用。每次执行都带有高 BUFFER_GETS(逻辑读取)的SQL语句是主要的原因。 1、查看当前的等待事件 （ latch: cache buffers chains） SQL> select event, count(*) from v$session  where wait_class <> ‘Idle‘ group by event order by 2; 2、查看 latch: cache buffers chains事件相关的会话信息 SQL> select sid,username,machine,program,p1raw,sql_id,logon_time,last_call_et from v$session where event=‘latch: cache buffers chains‘; 二、热块挣用 当多个会话重复访问一个或多个由同一个子cache buffers chains锁存器保护的块时，就会产生热块挣用。当多个会话争用cache buffers chains锁存器时，找出是否有热块的最好的方法是检查latch free等待事件的P1RAW参数值。 判断热块挣用的另一种方法是从 v$session_wait 视图获得锁存器地址后进行比较。v$session_wait的P1RAW就相当于子锁存器地址，若从 v$session_wait 视图获得的锁存器地址过多重复出现，就意味着对相应锁存器发生次数偏多，此时可解释为热快引起的争用。如果会话正在相同的锁存器地址上等待，就是热块。 SQL> select sid,p1raw,p2,p3,seconds_in_wait,wait_time,state from v$session_wait where event=‘latch: cache buffers chains‘ order by 3,2; 查看热块的对象： 根据TCH值确认热块。注意块从LRU列表的冷端移动到热端时，TCH值将重置为0,所以判断的时候，要注意TCH为0的块不一定是冷块。 使用P1RAW=00000300DA316800为例子进行关联热快对象。 SQL> select a.hladdr,a.file#,a.dbablk,a.tch,a.obj,b.object_name from x$bh a, dba_objects b where (a.obj = b.object_id or a.obj = b.data_object_id) and a.hladdr = ‘00000300DA316800‘ union select hladdr,file#,dbablk,tch,obj,null from x$bh where obj in (select obj from x$bh where hladdr = ‘00000300DA316800‘ minus select object_id from dba_objects minus select data_object_id from dba_objects) and hladdr = ‘00000300DA316800‘ order by 4; 若没有关于SQL语句的信息，也有方法间接判断是热块引起的问题，还是低效SQL语句引起的问题。v$latch_children视图中，比较子cache buffers chains锁存器相应的 child#、gets、sleeps值， 以此判断特定子锁存器上使用的次数和争用是否集中，利用以下语句，获取sleeps次数高的子锁存器。 SQL> select * from (select addr, child#, gets, sleeps from v$latch_children where name = ‘cache buffers chains‘ order by sleeps desc) where rownum < =20; 当结果中sleeps的值倾斜较大的时候就说明是热块挣用。 根据sleeps较高的addr确定哪些块是热块。 SQL> select hladdr,obj,(select object_name from dba_objects where (data_object_id is null and object_id = x.obj) or data_object_id = x.obj and rownum = 1) as object_name,dbarfil,dbablk,tch from x$bh x where hladdr =‘&p1raw‘ order by hladdr, obj;

latch：cache buffers chains的优化思路

标签：

原文地址：http://www.cnblogs.com/travel6868/p/5010727.html