1.产生原理

当一个数据块读入到sga中时，该块的块头(buffer header)会放置在一个hash bucket的链表(hash chain)中。该内存结构由一系列cache buffers chains子latch保护（又名hash latch或者cbc latch）。对Buffer cache中的块，要select或者update、insert,delete等，都得先获得cache buffers chains子latch，以保证对chain的排他访问。若在过程中发生争用，就会等待latch:cache buffers chains事件。

2.产生原因：

(1). 低效率的SQL语句（主要体现在逻辑读过高） 在某些环境中，应用程序打开执行相同的低效率SQL语句的多个并发会话，这些SQL语句都设法得到相同的数据集，每次执行都带有高 BUFFER_GETS(逻辑读取)的SQL语句是主要的原因。相反，较小的逻辑读意味着较少的latch get操作，从而减少锁存器争用并改善性能。注意v$sql中BUFFER_GETS/EXECUTIONS大的语句。

(2).Hot block 当多个会话重复访问一个或多个由同一个子cache buffers chains锁存器保护的块时，热块就会产生。当多个会话争用cache buffers chains子锁存器时，就会出现这个等待事件。有时就算调优了SQL，但多个会话同时执行此SQL，那怕只是扫描特定少数块，也是也会出现HOT BLOCK的。

3.解决方法

(1).优化SQL，如优化nested loop join，如果有可能使用hash join代替nested loop join。

(2).可以利用对热块索引进行hash分区，或者使用hash簇的方式减缓热块现象。

(3).调整表的pctfree值，将数据尽可能的分布到多个块中，但相同的查询要扫更多块，有负面作用。

(4).并行查询是直接读数据文件，不经过SGA，即direct path read,所以就不存在锁存器争用的情况了。但其一般是为了大量数据读取而使用的，不作为一般的解决方案。

(5).等问题自己消失。有时当出现latch争用时，故障时刻确实没有较好的方式解决，找到病因才是关键。

4.查找热点快对象

是从当前等待latch:cache buffers chains事件的会话出发。通过v$session_wait视图，获得P1RAW即子锁存器的地址。通过重复观察v$session_wait视图，发现某个子锁存器地址较多地出现，那么该子锁存器管辖的chain可能有热块。

select p1,p1raw from v$session_wait where event='latch: cache buffers chains';

所以v$session的p1raw与x$bh的laddr，以及v$latch_children的addr是同样的东西，都是子锁存器的地址。大概思路是，通过子锁存器的热度来找到所管辖的对象，以及对象的热度。

通过子锁存器地址，即v$latch_children的addr字段，来获取这些子锁存器所管理的对象的文件号块号与热度。 注意到x$bh字典表中的tch字段表示的就是block的touch count,一般来说这个值越高那么这个块就越热，我们称这样的块就叫做热点块。

根据FILE#,dbablk来找出对应对象。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15412087/viewspace-2148426/，如需转载，请注明出处，否则将追究法律责任。