oracle 10.2.0.1 rac發現sql查詢hang之gc cr request

背景：

   在學習oracle 10.2.0.1 rac時，發現RAC出現明顯的GC CR REQUEST事件，導致select查詢hang住，分析處理如下：

分析處理：

含義：
   本地節點需要一致性讀的UNDO資料不在本地節點，需要到遠端節點獲取，等待返回的過程。


先用下述SQL，查查本地節點一致性資料塊獲取的平均時間
select b1.inst_id,
       b2.value "GCS CR BLOCKS RECEIVED",--總的資料塊個數
       b1.value "GCS CR BLOCK RECEIVE TIME",--總的獲取時間
       ((b1.value / b2.value) * 10) "AVG CR BLOCK RECEIVE TIME (ms)"
from gv$sysstat b, 
     gv$sysstat b2
where b1.name = 'global cache cr block receive time'
and b2.name = 'global cache cr blocks received'
and b1.inst_id = b2.inst_id;




如果超過15ms,原因有幾方面：
1，SQL編寫不佳，引發不必要的資料訪問，最佳化SQL即可
2，如果SQL沒有明顯問題，可能是網路的原因，請在告警日誌檢視cluster interconnect,想辦法去最佳化或診斷網路
   說白了，就是減少RAC節點之間的網路延遲（私網）
3，LMS是負責RAC節點之間的鎖請求，如果發現OS對於LMS的排程有延遲或者OS負載極高時，可以考慮增加lms程式個數（由_lm_lms控制），或者提升lms程式的最佳化級，以優先獲取CPU時間片
4，當然你也可以重布應用，儘量減少資料的跨節點的訪問
5，如果你發現另一等待事件gc null to x，平均響應時間少於15ms,這很可能是一個關於統計資訊出錯的BUG，具體請見243593.1以及 Note: 181489.1

思考：

1,rac一些指標之間是有非常密切的聯絡的
2,lmd及lms的效能可能由一些v$sysstat指標進行評估，進而進行針對性的診斷與分析
3,還要對rac的機制及程式進行測試，方會有進一點的理解和思路