latch:cache buffers chains
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/,如需轉載,請注明出處,否則將追究法律責任。
轉載于:http://blog.itpub.net/15412087/viewspace-2148426/
總結
以上是生活随笔為你收集整理的latch:cache buffers chains的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: ILI9881C-0D调试总结
- 下一篇: 配置zabbix管理账号