一朋友求助說他的ORACLE RAC伺服器負載不是很穩定，時高時低，且沒有任何規律。摘取負載高峰時間的一段日誌來分析，最大的等待如下：

^LTop SQL Statements       DB/Inst: BOSSCENT/bosscent1  (May 19 13:17 to 13:32)
 
       SQL ID    Planhash % Activity Event                             % Event
------------- ----------- ---------- ------------------------------ ----------
f9rf7a8cg40nt         N/A       9.14 gc buffer busy                       2.53
insert into test(id,user_id,point_num,time,point_gettype,sex) values(
:1,:2,:3,sysdate,:4,:5)
 
                      N/A       9.14 gc current block busy                2.22
insert into test(id,user_id,point_num,time,point_gettype,sex) values(
:1,:2,:3,sysdate,:4,:5)
 
                      N/A       9.14 gc current block 2-way               1.42
insert into test(id,user_id,point_num,time,point_gettype,sex) values(
:1,:2,:3,sysdate,:4,:5)
bs6z6hs8sum53  1007834728       8.09 gc buffer busy                       2.16
update test set id=:1 where id=:2

明顯看到出現大量gc buffer busy等待，與單例項不同，在RAC環境中，由於多節點的原因，會因為節點間的資源爭用產生GC類的等待，而這其中，GC Buffer Busy Waits又是最為常見的，我們看下ORACLE官方對這個等待事件的解釋：

gc buffer busy:
This wait event,also known as global cache buffer busy prior to Oracle 10g,specifies the time the remote instance locally spends accessing the requested data block. This wait event is very similar to the buffer busy waits wait event in a single-instance database 。

那麼如何解決gc buffer busy帶來的效能問題？一般有兩種方法：

一、分割應用
就是指把出現gc buffer busy等待的SQL，單獨配置一個資料來源，在執行的時候指定到叢集中的某一個例項。在執行產生gc buffer busy的SQL的時候，使用這個資料來源。

這樣的缺點是，如果指向一個單例項，這些操作負載太高的話，一個例項可能會抗不住。

二、修改表底層結構

在問題表上加入一個欄位inst_id，也就是例項編號，這個欄位作為主分割槽欄位，按照這個分割槽做範圍分割槽。並且每次插入的時候給這個欄位賦一個常量，也就是例項編號。

這樣的缺點是，需要修改表結構，風險很大，而且如果以後擴充套件節點的話，還需要重新改表結構。

兩種方法各有長短，需要根據實際情況選擇，不過我個人還是傾向於第一種方法。

本文轉自：

[@more@]

RAC遇到GC Buffer Busy的解決方法1

相關文章