一次難忘的協助解決Oracle RAC恢複過程

解決過程

1）瞭解基本狀況

   前一天晚上18點左右關閉RAC，重啟小型機，重啟 RAC，發現兩個RAC組4個執行個體啟動正常，另一個RAC，兩個執行個體無法正常啟動。

2) 小型機工程師，診斷Oracle 裸裝置所在的datavg和archvg是正常的。

2) 請求一個朋友遠程建立VPN協助，經過二小時左右的診斷，初步確定可能是OCR（OCR---Oracle Cluster Registry）有問題, 建議恢複前面使用正常的OCR

   他無法這樣實施，風險很大，弄得不好，會把正常啟動的RAC宕掉。他建議請求上海神碼的人解決。

3) 經許言聯絡，晚上１０點多與上海神碼的DBA聯絡上。

　將基本狀況作一溝通，經過２個多小時的診斷，也無法確定問題的所在。

　最後他建議重新建立資料庫，客戶的要求，原RAC組名orcl最好不要變，經嘗試修改orcl在叢集裡的資訊，發現無法實施。

　所以從這一點看，我那朋友的判斷是正確的。最後只得重新建立新的RAC組DZJC和資料庫執行個體。建立資料庫執行個體需要很多資訊。

　由於Oracle執行個體的後台警告記錄檔極大２５０Ｍ左右，基本無法從中提取關於ORACLE資料表空間的建立資訊，只能根據原始的資料庫配置文檔來做，再加上

　應用程式供應商工程師的回憶，基本確定了資料庫的組成,並且在建立時都要求盡量大。

　這個過程是漫長的，大約到淩晨４點半鐘解決。至此所有相關的人都鬆了一口氣。

 

４) Import　Oracle DMP檔案，持續半小時。查看資料庫倒入的資料是否正確，發現丟失一個Database Link（不知道是真的丟了，還是原來就沒有）

　重建立立Database Link。重新編譯無效的資料庫物件，一切正常。

5）客戶類比RAC的容錯移轉功能。故意關掉某台小型機上的所有執行個體。發現應用程式一切正常。

 此過程大約持續了10幾分鐘。至此，大功告成。

6）趕回蘇州家裡，已經是淩晨6點多了。

這一次解決問題的過程，讓我在正常環境下，無法學到的很多東西。包括協調相關工程師（不是我做的），IBM AIX 叢集相關的（lslv/lsvg  clstat 啟動/關閉smitty clstart/clstop），Oracle 叢集執行個體的建立（也只是知道一個大概），ORACLE 叢集軟體的使用（srvctl/crs_stat/crsctl/ocrconfig）。要是下次遇到類似的問題，我能解決的話，那真是再熬一兩個晚上都是值得的。

給我自己切身的感受是，書到用時方恨少；山外青山樓外樓；學無止境。