Oracle数据库性能优化-cache buffer chains解析

1 为什么需要cbc latch

• 搜索链表查找bh
• 修改bh中buffer pin锁的状态，buffer pin锁分为S和X模式
• (如果只是逻辑读，进程会将buffer pin锁BH中调整为S模式，如果是dml操作则设置为X独占模式）
• 1个cbc latch保护N个bucket，
• 将链表BH中的buffer pin锁设置完成后，CBC释放。持有cbc修改buffer pin锁。
• 

2 一个逻辑读过程

1 在共享cbc latch模式获取cbc latch。

2 在共享cbc latch的模式保护下，搜索链表，查询BH中的BA，不需要堆buffer pin锁的状态进行修改。

3 在共享cbc latch的模式保护下，根据BH中的BA地址，查询buffer中的数据。

1 索引唯一扫描 , 从索引的根开始到访问表块都是共享的CBC ,index unique scan
2 index range scan 还是根枝为共享的CBC, 叶块和表块仍然为独占模式.

3 以rowid方式直接逻辑读取表块（table access by user rowid）还是独占的cbc模式、

3 CBC相关查询

select dbms_rowid.rowid_relative_fno(rowid) file_id,
       dbms_rowid.rowid_block_number(rowid) block_id
  from t1
 where rownum = 1

########查询数据块被哪个hash latch保护###########

select hladdr from x$bh x where file#=1 and dbablk=104169

########还有哪些对象被这条hash lathch保护#########

select file#,dbablk,owner,object_name from x$bh x ,dba_objects b where obj=b.data_object_id and x.hladdr='000007FF0A661AD0'

备注：其中v$session对应的p1raw值为latch地址，p2raw为latch的编号（v$latch_children的latch#列）。

3 CBC latch分析

set lines 120
col owner for a10
col object_name for a30
col object_type for a10
select  distinct owner, object_name, object_type,file#, dbablk
  from x$bh a, dba_objects b, v$session c
 where a.hladdr = c.P1RAW
   and b.DATA_OBJECT_ID = a.obj （表id永远不变，data_object_id段id在truncate之后会改变）
   and p1raw= '0000000D42253178'
   and c.event like '%latch: cache buffers chains%' order by object_type;

4 产生原因

1）多个进程频繁地以不兼容模式申请某一cbc latch，访问此cbc latch保护的不同链表和不同的bh。（热链）

2）多个进程频繁地以不兼容模式申请某一cbc latch，访问此cbc latch保护的同一链表和同一bh。（热对象）

5 CBC解决方案

5.1 热块竞争

1 hash分区打散热块。

2 优化sql调整执行计划，提高执行效率，较少cbc占用时间。(sql执行计划不合理））

3 从热点来说在buffer中存在一个buffer header，简称bh，在x$bh中存在字段tch记录buffer被访问次数

5.2 热链竞争

1 增加sga

2 修改隐藏参数_db_block_hash_latches参数。

alter system set "_db_block_hash_latches=32768 scope=spfile;