解決過程
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）。要是下次遇到類似的問題，我能解決的話，那真是再熬一兩個晚上都是值得的。
給我自己切身的感受是，書到用時方恨少；山外青山樓外樓；學無止境。