buffer cache —— latch: cache buffers chains

为了使用高速缓冲区，要查询或修改hash chain的进程必须获取管理相应chain的cache buffers chains锁存器。在获取cache buffers chains锁存器过程中如果发生争用，则等待latch: cache buffers chains事件。从oracle 9i起，以只读为目的的查询chain时，可以将cache buffers chains锁存器以Shared模式共享，因此有助于减少争用。

SQL> select name,parameter1,parameter2,parameter3 from v$event_name where name like 'latch: cache buffers chains';  
  
NAME                           PARAMETER1           PARAMETER2           PARAMETER3  
------------------------------ -------------------- -------------------- --------------------  
latch: cache buffers chains    address              number               tries 

利用以下命令可以得到cache buffers chains 锁存器的数量：

[sql] view plain copy print ?

1. SQL> select count(*) from v$latch_children where name like 'cache buffers chains';  
2.   
3.   COUNT(*)  
4. ----------  
5.       4096  

hash bucket数可以利用_db_block_hash_buckets隐含参数查看：

[sql] view plain copy print ?

1. SQL> select ksppinm, ksppstvl from x$ksppi x, x$ksppcv y  
2.   2  where (x.indx = y.indx) and (translate(ksppinm, '_', '#')) like '_db_block_hash_buckets';  
3.   
4. KSPPINM                        KSPPSTVL  
5. ------------------------------ --------------------  
6. _db_block_hash_buckets         131072  

所以，一个cache buffers chains 锁存器管理的bucket数就是：

[sql] view plain copy print ?

1. SQL> select 131072/4096 from dual;  
2.   
3. 131072/4096  
4. -----------  
5.          32  

发生cache buffers chains锁存器争用的代表性情况如下：低效的SQL、hot block。

1、低效的sql

低效的sql语句是发生cache buffers chains锁存器争用的最重要的原因。多个进程同时扫描大范围的索引或表时，可能广泛的发生cache buffers chains锁存器争用。
在发生锁存器争用时，若有充分依据是sql引起的，就应该调优sql。若没有关于sql语句的信息，也有方法间接判断是热块引起的问题，还是低效sql语句引起的问题。v$latch_children视图中，比较子cache buffers chains锁存器相应的latch#,gets,misses值，以此判断特定子锁存器上使用的次数和争用是否集中。利用一下命令语句，获取sleeps次数高的子锁存器。
select * from  
 (select latch#,gets,misses from v$latch_children where name = 'cache buffers chains'
  order by misses desc) where rownum <= 20;

若特定子锁存器的gets、sleeps值比其他子锁存器高很多，则可以推测相应锁存器管辖的chain上有Hot Block。

SQL> select * from  
 (select latch#,gets,misses from v$latch_children where name = 'cache buffers chains' 
  order by misses desc) where rownum <= 20;  2    3  

    LATCH#	 GETS	  MISSES
---------- ---------- ----------
       150    8787962	 1021648
       150    7596074	  790815
       150    5734181	  374772
       150   43085353	  243288
       150    3581867	  106402
       150    3640112	  105750
       150    8953534	  102891
       150   10275745	   87877
       150   21056159	   76018
       150    4347725	   62174
       150   14675552	   61701

    LATCH#	 GETS	  MISSES
---------- ---------- ----------
       150   13423108	   59066
       150    2035685	   51577
       150   14286698	   43532
       150    4148996	   43487
       150    4826151	   41922
       150    5169412	   41587
       150   13963060	   32564
       150    7846405	   27956
       150    8401477	   24876

20 rows selected.

判断Hot Block与否的另一种的方法是v$session_wait视图获得锁存器地址后进行比较。例如cache buffers chains锁存器，v$session_wait.p1raw就相当于子锁存器地址。若从v$session_wait视图获得的锁存器地址过多重复出现，就意味着相对应锁存器发生次数偏多，此时可以解释为Hot Block引起的争用。
适当的使用Parallel Query也能成为减少cache buffers chains锁存器争用的方法。Parallel Query不经过SGA，而是直接读取数据文件上所需的数据，因此高速缓冲区的争用问题本身不存在。但是Parallel Query是为了处理大量数据使用的，所以不推荐为锁存器争用的一般解决方案。

2、Hot Block

sql语句即便是适当进程了调优，有时也无法解决cache buffers chains锁存器争用。若在编写sql语句时的sql工作方式，只是持续扫描少数特定块，则在多个会话同时执行此sql语句时，就会发生Hot Block引起的cache buffers chains锁存器争用。

关于这个争用，只要解除反复扫描相同块这一设计上问题，自然就得到解决。但遗憾的是无法修改应用程序的情况较多。迂回的解除Hot Block引起的cache buffers chains锁存器争用的方法是将属于Hot Block的行尽量分散到其它的块。一般推荐如下方法：

（1）通过赋予较高的PCTFREE值或使用小块，减少块争用。赋予较高的PCTFREE值和使用小块，可以减少一个块上所包含的行数，因此能避免块争用，就这一点来说基本上是相同的方法。次方法的确有减少块争用的效果，但是相应增加了需要管理的块数，因此可能招来负面效应。固块数增加，而使得相同的查询需要扫描更多的块，因此发生性能下降想象。即，Hot Block引起的锁存器争用虽然减少，但是增加的扫描次数可能伴随着锁存器争用的增加。因此，未经验证就应用时，可能得到与一般指南上内容完全不同的结果。

（2）使用partitioning方法尽量将行物理的插入到另外的块。使用这个方法，将成问题的行自然的、物理的分散到另外的块，因此能避免发生锁存器争用。
（3）只对有问题的块的行删除后再执行插入工作，此方法只对表可行。若能正确了解有问题的块和包括的相应块内行的行标识（rowid），在删除该行后再插入，可以将各行分散到另外的块。利用块转储和DBMS_ROWID程序包可以了解属于Hot Block的行标识。此方法可算是不修改表属性最理想的方法。但如果Hot Block不是固定的，随sql语句的条件（where ...）而每次都改变，则无法应用。还有对于索引不能使用这个方法。

（4）解决表的cache buffers chains锁存器争用相对比较容易，因为分散行的方法非常多。如果是索引上的Hot Block，可以使用反向索引。参考：http://blog.csdn.net/zq9017197/article/details/7321604