這兩天遇到客戶因爲誤操作，將RAC環境下的所有共享存儲格式化掉了，客戶只有一個最近的RMAN的0級全備（無數據文件，無控制文件，無歸檔日誌，無redo日誌），需要幫忙恢復。將大致的恢復過程記錄一下。
0.恢復共享存儲是第一步，給存儲原廠打電話，原廠推是os的問題，讓給os打電話，結果只能初始化了，最後只能恢復到被識別的狀態，一切從頭開始。
1.因爲集羣軟件是裝在本地的，所以恢復rac的集羣環境，只需要將ocr和vdisk重新配置一下，就可以了。可以執行root.sh腳本來進行重新的配置，如果中間報一個已經被配置過的提示，那就先用dd清除ocr和vdisk的信息，並刪除相應的目錄文件，如下:
rm -rf /usr/tmp/.oracle /var/tmp/.oracle /tmp/.oracle /etc/oracle/* /var/opt/oracle/*
rm -rf /etc/init.cssd /etc/init.crs* /etc/init.evmd /etc/init.d/init.cssd /etc/init.d/init.crs
rm -rf /etc/init.d/init.crsd /etc/init.d/init.evmd /etc/rc3.d/K96init.crs /etc/rc3.d/S96init.crs
rm -rf /etc/rc.d/rc2.d/K96init.crs /etc/rc.d/rc2.d/S96init.crs
2.恢復完集羣環境之後，開始恢復數據庫。因爲詢問到客戶有去年年底的一個RMAN的0級全備，以及控制文件的快照沒有放到共享存儲上，故可以採用重建控制文件+restore備份的方法來恢復。中途遇到很多問題，因爲所有的日誌備份均放到共享存儲下的，故這次恢復在recover的步驟時是沒有日誌用來補充的。所以restore databse until 時間後，再recover，再alter database open resetlogs後，會報一個需要恢復數據文件的錯誤提示，操作的時候運氣不好，剛好遇到的是需要恢復datafile 1，再折騰了幾個小時候，終於發現按照正常的手段是行不通的.
3.因爲沒有日誌，無法使得數據庫達到一致性，所以只有採取修改隱藏參數的辦法來忽略數據庫的不一致，來強行打開數據庫.先將數據庫打到mount狀態，在做完restore，recover之後，將隱藏參數修改 alter system set "_allow_resetlogs_corruption"=true scope=spfile;再shutdown數據庫，啓動到mount狀態之後，alter database open resetlogs; resetlogs打開數據庫後，運氣仍然不是太好，又遇到了ORA-00600 2662號的錯誤.
4. 當使用修改_allow_resetlogs_corruption ，再打開數據庫時遇到了ORA-00600 2662號的錯誤， 如果SCN相差不多，可以通過多次重起數據庫解決 ，但是這次遇到的SCN相差很大(通過查v$datafile和v$datafile_header的CHECKPOINT_CHANGE#來判斷)，這個時候只有再修改另外一個隱藏參數 _minimum_giga_scn來解決問題._minimum_giga_scn的作用是推進SCN號，該參數值的單位是billion，也就是說設置了該參數後，SCN號會變成XX* (1024*1024*1024) ，XX可以通過2662的幾個參數來確定. 2662後的參數[2662],[a],[b],[c],[d],[e]…[a] Current SCN WRAP，[b] Current SCN BASE，[c] dependent SCN WRAP，[d] dependent SCN BASE，[e] Where present this is the DBA where the dependent SCN came from.
5.當修改了2個隱藏參數之後，數據庫終於能啓動了，但是alert日誌還是會報一些600的錯誤，暫時忽略.用exp(expdp可能會報錯)將數據全部導出，重建新的實例，再用imp導入數據到新的庫中.exp的時候需要注意一個參數compress，這個參數可以降低HWM，使的imp的時候，時間相對儘量少一些.