客戶數據庫版本為9208 RAC FOR AIX，客戶反應系統緩慢，檢查告警日志，發現大量Library cache lock和Library cache load lock等待。
由于客戶的原因，這個問題只是遠程協助的方式幫忙檢查了一下，因此沒有留下任何的操作記錄，這里只是簡單描述一下問題。
客戶反應數據庫操作響應變慢，平時一個執行很快的基于主鍵的UPDATE操作也變得異常緩慢，且執行計劃本身并未發生改變。
登錄數據庫后檢查兩個節點上的告警日志，并未發現任何異常報錯。分別檢查兩個實例的等待信息，發現除了上面提到的大量Library cache lock和Library cache load lock以外，還有明顯的gc等待。
但是隨后發現，查詢V$SESSION和GV$SESSION的結果居然沒有區別，接著查詢GV$INSTANTBCE視圖，發現只有當前的實例存在，而此時恰好連接另一個節點的工具出現了斷連，以至于我一度以為另外一個節點上的實例已經DOWN掉，但是隨后重新登錄到該節點上，發現數據庫實例仍然存在，而且登錄到數據庫實例中也可以進行任何正常的操作。不過發現在當前節點所有的GV$視圖都只會返回當前實例的信息，這與另外一個節點的情況完全一樣。顯然兩個節點間的通信出現了問題，當前節點已經不清楚另外一個節點的狀態的。
現在再去分析那些等待信息已經沒有太多的意義了，因為整個數據庫已經處于不正常的狀態。不難推斷，當前數據庫的異常是由于節點間的通信異常導致。由于9i使用的操作系統的CLUSTER，還沒有Oracle的clusterware，剩下只能由操作系統或硬件維護人員去進一步跟蹤了。
最終數據庫和系統在夜間閑時進行了重啟操作，重啟后數據庫恢復正常，GV$視圖的結果也恢復了正常。