Cache Buffers Chains的解決思路是什么

這篇文章將為大家詳細講解有關(guān)Cache Buffers Chains的解決思路是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

 Latch free相對來說是Oracle性能調(diào)優(yōu)的一個難點，主要是定位造成CBC的語句，國外數(shù)據(jù)庫專家對latch造詣比較深的是andreynikolaev，Tanel Poder等。
以下是解決該問題的一個思路：

1、查看v$event_name中l(wèi)atch: caches buffers chain中p1,p2和p3值

      p1: address;  p2: number; p3: tries

2、通過ASH查看發(fā)生CBC最多的latch地址

select * from (
    select  event,
                 trim(to_char(p1, 'xxxxxxxxxx')) latch_addr,
                 trim(round(ratio_to_report(count(*)) over ()*100, 1)) ||' % '  PCT,
                 count(*)
     from v$active_session_history
     where
         event = 'latch: cache buffers chains'
      and session_state =' WAITING'
      group by event, p1
      order by count(*) desc
     )
 where rownum <10;

輸出結(jié)果關(guān)注等待latch的LATCH_ADDR地址。

3、tanlepoder提供了latchprofx腳本，見附件
        （將附件latchprox.jpg改成latchprox.sql)

SQL>@latchprofx.sql sid, name,sqlid, object % "&latch_addr' 10000  --采樣率

腳本內(nèi)使用視圖：

x$ksuprlat   :關(guān)于當前l(fā)atch holder信息，
                        Kernel Service, User ,Process LATch holder

x$ksuse: 關(guān)于session信息： Kernel Service User SEssion

x$ksllw: latch 內(nèi)容： Kernel Service Latch context Where

輸出結(jié)果中，我們關(guān)注object地址，可以知道是哪個對象，SQLID可以知道是什么語句。

4、查找文件和數(shù)據(jù)塊對象

select dbms_utility.data_block_address_file(to_number('&object', 'xxxxxxx') file#,
        dbms_utility.data_block_address_block(to_number('&object', 'xxxxxxx') blk#
from dual

知道了文件和數(shù)據(jù)塊，我們一種方法用dump block方式知道具體是哪個對象，或者用傳統(tǒng)的dba_extents (但該方法查詢速度非常慢），或者使用x$BH等方式。查出對應(yīng)的對象名是什么。

5、通過SQLID查看v$sqlarea，或v$SQL方法獲得完整的SQL語句

select sql_fulltext from v$sqlarea where sql_id='&sqlid';

6、通過dbms_xplan.display_cursor腳本（參看前面文章“Oracle 10中如何使用
dbms_xplan分析執(zhí)行計劃”）

列出完整的執(zhí)行計劃。我們通過執(zhí)行計劃重點關(guān)注步驟4查出的對象名稱
大部分情況下,CBC是改變SQL執(zhí)行計劃，通常造成該問題執(zhí)行計劃顯現(xiàn)NL，filter問題。優(yōu)化該語句基本能解決該問題。

關(guān)于Cache Buffers Chains的解決思路是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。