處理rac資料庫一個節點監聽異常

 

處理rac資料庫一個節點監聽異常

環境
linux 5.5
oracle 10.2.0.4 rac
asm

發現

2013年7月29日客戶上午打電話給我，發現rac資料庫的一個節點連不上了，因為從客戶端無法載入資料了；要求馬上去現場處理，聽對方的描述，我初步分析應該是監聽或網路出現了問題。

現象

打的到達現場後，檢查了一圈關於系統、資料庫的資訊，記憶體、cpu、網路等資源都正常，告警日誌和監聽日誌均沒有報錯，例項看起來也正常，程式都在，也能查詢資訊；

資料庫叢集crs_stat -t，該節點有兩個應用inst和lsnr狀態為offline，lsnrctl status|start|stop等命令都執行不成功，超時最後報錯，srvctl start listener -n db01 CRS-0215無法啟動資源，不正常；另一個節點crs_stat -t對方節點應用inst和lsnr狀態為offline；tnsping不通監聽異常的節點，其他正常；

還發現一個問題，兩個節點時間相差了近9分鐘，監聽不正常的那個節點比另一個正常的節點慢9分鐘；

分析

可能之一：

時間不同步導致叢集通訊異常，監聽異常

可能之二：

檢查叢集日誌，發現crsd.log日誌有報錯，另有一個日誌有報錯“timeout killed the spawned process”

    上網google搜尋，有幾個文章都說是某個時間點資源不足導致程式分配失敗，通常重啟節點就能恢復正常。

處理

調整時間為同步，重啟監聽看看情況:

在監聽不正常的節點上操作，將時間調整為和另一個節點一致

date 0729144013.00

時間調整成功，但還是無法對監聽做任何操作，啟動、停止、看狀態都不響應

故排除該種可能性，應該是第二種情況

重啟節點，看看情況：

和客戶方溝通後，同意重啟機器；

以oracle使用者身份關掉crs及相關服務，/etc/init.dinit.crs stop，檢查發現程式不復存在，操作成功；

uptime發現該機器已有300多天沒有重啟過，reboot重啟，等待幾分鐘，檢查一切正常，包括兩個節點crs狀態、監聽情況等；

結果

檢查一圈，發現一切正常，通知客戶開啟應用，載入資料，正常，問題處理完畢。