背景
某銀行客戶，RAC 11.2.0.4 Linux環境在7月14日進行跑批業務，平時20分鍾左右完成，今日將近2個小時才完成，客戶反饋，跑批任務一直在1節點進行，現給出4份AWR報告，希望分析故障原因。（報告包含2份正常時段和2份異常時段）
問題分析
1、對比4份報告--正常時段
根據2份正常時段的報告抬頭，跑批任務確實在1節點運行，26分鍾完成跑批任務，與客戶反饋相符
2、對比4份報告--異常時段
再觀察2份異常時段的報告抬頭，發現RAC 雙節點的DB運行時間均在2個半小時，與客戶之前反饋，任務只在一節點跑，不相符，由此我們大概可以判斷問題的方向，1）可能是任務被負載均衡到2個節點，2）可能任務直接就在2節點運行
3、分析4份報告Load Profile
因正常時段主要在1節點，我們可以注重分析1節點報告，進而和異常時段的兩份報告做對比。
- 正常時段
- 異常時段
根據跑批時段產生的redo size 大小，我們可以判斷，正常時段節點1和異常時段節點2，產生redo size 大小一致，對此，我們可以斷定，異常時段的跑批任務肯定是在2節點運行。
4、異常時段在2節點跑批驗證
僅僅根據redo size如果不能說服，我們可以進一步分析，執行跑批的具體SQL。和客戶溝通后，我們在正常時段節點1找到跑批的主SQL語句，同樣的，我們在異常時段的2節點發現執行跑批SQL，且運行時間較長，這就進一步驗證異常時段跑批任務是在2節點進行。
- 正常時段
- 異常時段
5、結論
由於本次跑批任務，由於某種原因，在2節點執行，所以導致跑批較慢？？？
如果只給客戶一個這樣的回復，相信是沒有說服力，畢竟是RAC環境，數據是一樣，為什么在2節點，就會變慢，且看下面分析。
問題深入分析
1、異常時段AWR等待事件
通過分析異常時段AWR，可以發現，在1、2節點，均有大量的GC相關的等待事件，gc buffer busy acquire、gc buffer busy release、gc cr block busy等，而正常時段也有類似的等待事件，但遠遠沒有異常時段的嚴重。
關於GC，在網上都有比較詳細的說明，我們在此簡單提下，在RAC環境，有Cache Fusion（內存融合）機制，可以實現多節點的緩存數據共享，如果比較頻繁，就會有大量的GC相關等待事件，類似今天處理的故障AWR中一樣，說白了就是跨節點訪問內存數據，針對本案例，此事件的發生是比較正常，因為平時數據都緩存在1節點，突然在2節點執行任務，就會有過多的GC，而GC的處理方法，基本都是分割應用，或者分割表，盡量避免頻繁的多節點數據訪問。
問題總結
對於本案例中，問題的本源比較容易發現，這也依賴前期與客戶溝通的結果，提前預知跑批任務主要在1節點，給接下來的問題分析帶來了極大的幫助，另外客戶同時提供正常和異常時段的報告，也有助於進行的事件對比，所以，我們在以后的問題處理中，可遵循以下幾點。
- 事先和客戶溝通故障情況（本次溝通結果，正常時段1節點執行 20分鍾完成，異常時段2個小時）
- 故障前是否有變更操作（本次溝通結果，無此步，但應該是其他原因造成的跑批任務漂移）
- 采取正常和異常對比快速定位（本次客戶直接提供正常和異常的AWR）
- 交付客戶結果（本次案例，通過定位在節點2執行，產生大量GC）
當然，處理問題的方式不是一成不變，針對不同情況還需不同對待，但整體先后流程不能少，比如一上去就敲鍵盤的工程師是不可能真正處理問題。