原理:
當一個數據塊讀入到sga中時，該塊的塊頭(buffer header)會放置在一個hash bucket的鏈表(hashchain)中。
該內存結構由一系列cache buffers chains子latch保護（又名hash latch或者cbc latch）。對Buffer cache中的塊，
要select或者update、insert,delete等，都得先獲得cache buffers chains子latch，以保證對chain的排他訪問。
若在過程中發(fā)生爭用，就會等待latch:cache buffers chains事件。

產生原因:

?

1. 低效率的SQL語句（主要體現在邏輯讀過高）
在某些環(huán)境中，應用程序打開執(zhí)行相同的低效率SQL語句的多個并發(fā)會話，這些SQL語句都設法得到相同的數據集，
每次執(zhí)行都帶有高 BUFFER_GETS(邏輯讀取)的SQL語句是主要的原因。相反，較小的邏輯讀意味著較少的latch get操作，
從而減少鎖存器爭用并改善性能。注意v$sql中BUFFER_GETS/EXECUTIONS大的語句。
2.Hot block
當多個會話重復訪問一個或多個由同一個子cache buffers chains鎖存器保護的塊時，熱塊就會產生。
當多個會話爭用cache buffers chains子鎖存器時，就會出現這個等待事件。有時就算調優(yōu)了SQL，但多個會話同時執(zhí)行此SQL，
那怕只是掃描特定少數塊，也是也會出現HOT BLOCK的。???

解決方法:

?

1.優(yōu)化SQL，如優(yōu)化nested loop join，如果有可能使用hash join代替nested loop join。
2.可以利用對熱塊索引進行hash分區(qū)，或者使用hash簇的方式減緩熱塊現象。
3.調整表的pctfree值，將數據盡可能的分布到多個塊中，但相同的查詢要掃更多塊，有負面作用。
4.并行查詢是直接讀數據文件，不經過SGA，即direct path read,所以就不存在鎖存器爭用的情況了。
但其一般是為了大量數據讀取而使用的，不作為一般的解決方案。
5.等問題自己消失。有時當出現latch爭用時，故障時刻確實沒有較好的方式解決，找到病因才是關鍵。

總結

以上是生活随笔為你收集整理的等待事件 latch:cache buffers chains的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。