cache buffers chain latch && cache buffers lru chain latch

以下情况需要拿到cache buffer chain latch：
1、服务器进程需要扫描hash chain的数据块时
2、服务器进程将数据挂载到hash chain时
oracle10g中在数据库中的持有cache buffers chains的对象：
select sid,p1raw,p2,p3,seconds_in_wait,wait_time,state from v$session_wait where event='cache buffers chains' order by p2,p1raw;

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='070000003469A7DB'
union select hladdr,file#,dbablk,tch,obj,null from x$bh
where obj in (select obj from x$bh where hladdr='070000003469A7DB'
minus select object_id from dba_objects
minus select data_object_id from dba_objects) and hladdr='070000003469A7DB'
order by 4;

检查隐含参数_db_block_hash_latches
column name format a30
column value format a25
select
x.ksppinm　name,
y.ksppstvl　value,
y.ksppstdf　isdefault,
decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE')　ismod,
decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE')　isadj
from
sys.x$ksppi x,
sys.x$ksppcv y
where
x.inst_id = userenv('Instance') and
y.inst_id = userenv('Instance') and
x.indx = y.indx and
x.ksppinm like '%_&par%'
order by
translate(x.ksppinm, ' _', ' ')
/ 
Enter value for par: db_block_hash_latches                                         
old  14: 　　x.ksppinm like '%_&par%'                                              
new  14: 　　x.ksppinm like '%_db_block_hash_latches%'                                                                                       NAME                           VALUE                     ISDEFAULT ISMOD      ISADJ
------------------------------ ------------------------- --------- ---------- -----
_db_block_hash_latches         2048                      TRUE      FALSE      FALSE
增大该隐含参数可以减少对latch的争用，但是不建议进行修改。
引起latch:cache buffer chains的等待事件原因主要有两个：
1）、低效的sql：如多个进程同时大范围扫描表和索引
当单条sql运行效率很快，而并发效率很慢，应用问题，在DB层面是无法进行优化的；
2）、hot block：多个并发进程同时访问一个数据块
从9i开始，若读取hash chain中某些类型的数据块（如唯一索引的块），可以通过shared模式获取cache buffer chain latch，从而在一定程度上减少latch的发生。

latch:cache buffers lru chain
LRU 链：连接的是干净块，连接的顺序是访问的频率，热端和冷端，Oracle用TCH表示该区域内数据块的访问频率
分为主列和辅助列
主列：已经使用的缓冲区列
辅助列：空闲缓冲区列；在chain上找挂载点的时候，先访问他，同时，LRUW上通过DBWR写进disk的也会挂回辅助列
LRUW 链：联接的是脏块，脏块就是在内存中已经下修改，但是还没有写入硬盘（换句话说：数据在内存和硬盘中的不一致） 
按照被脏的次数进行连接，脏缓冲区头由DBWR从LRU传递到LRUW（有时DBWR过忙，则不能执行这种移动），寻找空闲缓冲区的server process在LRU上发现了脏缓冲区头，则会将脏缓冲区头从LRU移动打LRUW上；也分为主列和辅助列
主列：已修改的缓冲区列
辅助列：正在被DBWR写到缓冲区列

LRU和LRUW总是成对出现，称为Working Set；
为了提高性能，Oracle会开启多个WORKING SET，有cache buffers chain latch 进行保护，基于性能上的考虑，当server process 去找空闲的缓冲区时会首先扫描LRU的辅助列，当辅助列没有的时候才回去访问主列的冷端，同时冷热是相对于nK buffer pool来说的，与recycle pool（使用频率较低的大表）和keep pool（使用频率较高的小表）无关；
数据块在nK buffer pool 中存放的位置和数量主要受以下两个参数的影响：
_db_percent_hot_default：默认值是50；表示当single block I/O（如唯一索引）时，读取的数据块进入buffer cache后，会将其放在nK buffer pool的LRU链的中间（热端的末尾），当multiply block I/O（如全表扫描）时，读取的数据库进入buffer cache后，会将其放在nK buffer pool的尾端，尽快被置换出去。

_db_percent_hot_keep和_db_percent_hot_recycle 默认值是0，表示数据进入到keep pool和recycle pool时，放在LRU的尾端。


NAME                           VALUE                     ISDEFAULT ISMOD      ISADJ
------------------------------ ------------------------- --------- ---------- -----
_db_percent_hot_default        50                        TRUE      FALSE      FALSE
_db_percent_hot_keep           0                         TRUE      FALSE      FALSE
_db_percent_hot_recycle        0                         TRUE      FALSE      FALSE

Enter value for par: db_block_lru_latches
old  14: x.ksppinm like '%_&par%'
new  14: x.ksppinm like '%_db_block_lru_latches%'

NAME                           VALUE                     ISDEFAULT ISMOD      ISADJ
------------------------------ ------------------------- --------- ---------- -----
_db_block_lru_latches          8                         TRUE      FALSE      FALSE

SQL> select count(*) from v$latch_children where name ='cache buffers lru chain';
  COUNT(*)
----------
         8

Oracle默认创建的cache buffers lru chain latch 的数量跟CPU个数和db_writer_processes 有关   
当DBWR数小于4，则创建4*CPU_COUNT个cache buffers chain latch,若DBWR大于4，则创建DBWR*CPU_COUNT个cache buffers chain latch；
因此，cache buffers chain latch总是大于dbwr的数量。
不同的working set可以出现在不同的buffer pool中，每一个buffer pool独立使用自己的cache buffers chain latch；


由于一个数据库实例可以配置8种不同类型的buffer pool（default,2k,4k,8k,16k,32k,keep,recycle buffer pool),因此cache buffers chain latch至少有8个；查询各个buffers pool中cache buffers LRU chain latch的使用情况：
select d.blk_size,c.CHILD#,p.bp_name,c.GETS,c.SLEEPS
from x$kcbwds d,v$latch_children c,x$kcbwbpd p
where d.set_latch=c.ADDR
and d.set_id between p.bp_lo_sid and p.bp_hi_sid
order by c.CHILD#;

  BLK_SIZE     CHILD# BP_NAME                    GETS     SLEEPS
---------- ---------- -------------------- ---------- ----------
      8192          1 KEEP                         20          0
      8192          2 RECYCLE                      20          0
      8192          3 DEFAULT                   28407          0
      2048          4 DEFAULT                      20          0
      4096          5 DEFAULT                      20          0
      8192          6 DEFAULT                      20          0
     16384          7 DEFAULT                      20          0
     32768          8 DEFAULT                      20          0  
从以上查询可以看出，目前8个latch只使用了1个，以下两种情况必须获得cache buffers lru chain latch；
1、数据库块读取buffer cache之前需要获得cache buffers lru chain latch来查找空闲缓冲区
2、DBWR为了获得脏数据块列表，扫描LRU-W列之前需要获取cache buffers lru chain latch 。此外空闲缓冲区移动到LRU辅助列，也需要获得。
当多个进程同时检索LRU或者LRU-W时，容易出现cache buffers lru chain latch,一般来讲，cache buffers lru chain latch是由低效SQL造成前台过多的请求空闲资源缓冲区，与cache buffers chain latch类似，不能通过简单的调整隐含参数来优化
cache buffer chain latch和cache buffers lru chain latch的区别
1、多个会话并发访问相同的表或者索引，则发生cache buffer chain latch的概率要高，因为相同的表和索引多集中于几条相同的hash chain中
2、多个会话并发访问不同的表或者索引，则发生cache buffer lru chain latch的概率要高，因为不同的数据块放在放在buffer cache中的概率较低，当发生物理读时需要更多的扫描LRU和LRU-W