一次GC BUFFER BUSY處理

今天遠端幫同事處理了一個GC BUFFER BUSY，記錄一下

看到AWR報告是，gc buffer busy平均等待時間高達500ms，但是從負載來看，除了邏輯讀有1.5倍的增加，心跳流量，接受/傳送的塊數量都沒有正常時間點高。

第一個反應是心跳網路有問題，如光纖網線被門夾了，網路卡模式切換到了非全雙工模式，但是讓主機工程師檢查，以及用FTP測試，心跳網路是沒有問題的

仔細看AWR，同時的TX等待也很高，但是導致TX的語句，資源消耗很低，但是其執行時間中，98%都是叢集等待時間，也就是說起可能是受到GC等待的拖累

主機上，CPU空閒一直未0，這時想到一個問題，可能是由於部分SQL邏輯讀太高，消耗了幾乎所有的CPU，導致LMS請求不到足夠的CPU資源，導致LMS效率底下，拖累了其他應用

在AWR中，發現一組沒有使用繫結變數的SQL，消耗極多的邏輯讀，物理讀（但是其在TOP叢集等待SQL中不高，並且這些SQL主要等待也不是GC），其上的索引存在一定的問題，讓客戶重建後，該SQL的邏輯讀從5億個資料塊下降到5個資料塊。

重建後GC問題消失，TX等待也連同一起沒有了

由於客戶是內外網分離，只是通過AWR看了，深入還有什麼問題沒有研究

總結下GC相關等待的幾個可能原因
1.SQL效率低下，邏輯讀物理讀多
2.心跳網路出現問題
3.CPU利用率高導致LMS請求不到足夠的CPU資源，特別是HP系統上，LMS程式的優先順序也可能導致一些問題

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8242091/viewspace-736666/，如需轉載，請註明出處，否則將追究法律責任。