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