超融合硬件損壞導致Oracle RAC異常恢復實錄

　　墨墨導讀：一套Oracle RAC環境運行在HW超融合環境中，由于硬件問題導致數據庫crash，期間出現了不少數據壞塊，本文詳述整個恢復過程，希望對大家有幫助。

　　前幾天某客戶遇到一個棘手問題：其一套Oracle RAC環境運行在HW超融合環境中，由于硬件問題導致數據庫crash，期間出現了不少數據壞塊，不過還好客戶有RMAN物理備份，因此客戶提前進行了全庫Restore。

　　首先我們來看下相關日志信息：

　　上述類似的大量壞塊信息，最終導致數據庫掛掉。

　　我們可以看到客戶這里asm diskgroup為normal冗余；當primary extent數據有問題時，Oracle會嘗試從mirror extent去獲取；如果mirror extent是正常的，那么Oracle會自動進行修復，否則會導致數據丟失，嚴重的話會導致數據庫宕機。

　　因為部分文件需要介質恢復（因為primary和mirror 數據都異常），而數據庫強行終止了實例。

　　數據庫實例重啟后則開始出現大量錯誤：

　　不難看出數據庫控制文件和system都出現了異常，這也難怪數據庫無法正常打開。

　　期間還出現了ora-00600 [4193]等常見錯誤：

　　對于此次恢復case總體來講比較簡單，這里提供一下處理思路：

　　首先利用客戶的歸檔和Redo(Redo log客戶已copy到了本地進行備份)，進行正常的recover database using backup controlfile until cancel操作；

　　由于恢復過程中出現了ora-00600 [3020]錯誤，因此需要通過recover database allow xx corruption的方式進行；

　　完成恢復之后嘗試打開數據庫；

　　打開數據庫時仍然提示ora-01113和ora-01110錯誤，即system文件還需要進行恢復；這種情況下只能先強制拉庫；通過加入*._allow_resetlogs_corruption=TRUE *._allow_error_simulation=true 等隱含參數即可；

　　若上述參數后仍然提示undo 存在壞塊，由于該數據庫版本在報錯時不會直接提示具體是哪個回滾段有問題，在alter database open resetlogs之前通過10046 event定位error cursor，找到回滾段名稱即可；

　　使用_corrupted_rollback_segments參數屏蔽回滾段；

　　open resetlogs數據庫成功；

　　最后就是重建undo以及處理相關壞塊等善后工作。

　　恢復完成之后，由于客戶擔心HW超融合環境再次出現故障因此進行了全庫備份并進行數據遷移到新平臺，到這里這個case告一段落。

　　再次叮囑大家，注意數據庫備份、注意數據容災環境建設！

　　推薦閱讀：144頁！分享珍藏已久的數據庫技術年刊

　　數據和云

　　ID：OraNews

　　如有收獲，請劃至底部，點擊“在看”，謝謝！

　　點擊下圖查看更多 ↓

　　云和恩墨大講堂 | 一個分享交流的地方

　　長按，識別二維碼，加入萬人交流社群

　　請備注：云和恩墨大講堂 點個“在看”