1、背景描述：

       

        某客戶反饋在 18 點 30 分左右出現效能問題，活動會話飆升，業務卡頓。

2、問題分析 

         透過awr 可以看到大量的索引分裂等待，和併發的事務槽等待，事務槽的併發等待是由於索引分裂阻塞大量會話導致的併發加劇的問題，所以我們主要看索引分裂的問題。

          透過ASH 資訊進行分析，活動會話飆升時刻在18 點32 分，當時阻塞者一直是節點2 的8442 會話，隨後被阻塞會話不斷飆升，被阻塞會話都是在等待TX – index contention 索引分裂。

          根據ASH 繼續分析8442 這個會話的活動情況，可以看到8442 從18 點32 分開始一直到19 點32 分持續1 小時一直在執行一個update 語句，等待事件上看是在等待單塊讀。

從執行計劃上看這個語句執行計劃沒有發生改變，邏輯讀明顯增大，在 IO 上等待嚴重，執行次數為 0

                 

         那麼問題就比較明顯了，8442 會話執行更新操作，由於該會話一直等待單塊讀，阻塞了大量會話去等待索引分裂，而實際上8442 正在執行的操作就是索引分裂，那麼為什麼索引分裂需要持續這麼久，掃描這麼多的單塊讀，下面我們在awr 中檢視failed probes on index block reclamation 這個指標，總共出現105w 次，平均每秒1152 次

下圖將最近時間段的該指標都列出來，可以看出節點2 上，在問題出現的時刻該指標出現了明顯的異常，該指標的含義是索引分裂的時候需要分配可用塊，在分配可用塊的過程中需要檢查該塊是否可用，failed 就是指檢查過程中出現了失敗的情況，這裡也就說明了索引在分裂的時候掃描大量塊都不可用，導致分裂一直在等待單塊讀，持續很長時間，阻塞大量會話。

select 
    a.INSTANCE_NUMBER,
    a.BEGIN_INTERVAL_TIME,
    b.STAT_NAME,b.VALUE,
    b.value-lag(b.value,1)over(order by a.begin_interval_time) as intervalvalue
 from 
     dba_hist_snapshot a,
     DBA_HIST_SYSSTAT b 
 where 
     a.instance_number=2 
 and a.INSTANCE_NUMBER=b.INSTANCE_NUMBER 
 and a.SNAP_ID=b.SNAP_ID 
 and b.STAT_NAME='failed probes on index block reclamation' 
 and a.BEGIN_INTERVAL_TIME>sysdate-1 order by 2;

          那麼問題鎖定到為什麼會掃描大量塊不可用呢，這種問題一般在兩種場景較為突出

         一種是插入的表正在執行批次DELETE 操作，DELETE 導致出現了大量的空塊，但是空塊上還存在著事務未提交，當索引分裂時這些被釋放的空塊會被掃描並檢查，當發現上面還有事務沒有提交時就會發生failed 。

        另外一種是索引存在大量的碎片，段空間自動管理使用點陣圖去管理段內的空閒空間，  這些Free Block 的要求是status 是75%-100% Free 的， server process 會掃描這些75%-100% Free 的block  並確認這些block  實際上是100% 空的，  如果找到100% Free Block 則使用；如果沒有則繼續搜尋，  直到所有候選block 都被檢查過，這個行為叫做 probes on index block reclamation 。每次尋找空塊並failed  ，oracle 就會增加這個統計指標

3、結論與建議

        經過分析本次效能故障是由於索引分裂長時間未結束阻塞大量會話等待索引分裂，索引分裂時間長的原因是由於索引存在較多的碎片導致分裂時出現大量的空塊掃描失敗failed probes on index block reclamation 。

3.1 建議如下

1.       透過建立hash 索引降低索引分裂的發生頻率

2.       定期清理碎片，降低failed probes on index block reclamation 發生頻率

3.       避免業務高峰期大批次刪除資料