本案例詳細介紹了伺服器存儲資料庫恢複的過程，包括RAID重組和資料庫資料的修複與驗證。
背景介紹：
S5020 光纖存儲。存儲上一共16塊FC硬碟，單盤容量600G。存儲前面闆10号和13号硬碟亮故障燈，存儲映射到redhat上的卷挂載不上，業務崩潰。
開始工作：
通過storage manager連接配接到存儲檢視目前存儲狀态，存儲報告邏輯卷狀态失敗，再檢視實體磁盤狀态，發現6号盤報告“警告”，10号和13号盤報告“失敗”，通過storage manager将目前存儲的完整日志狀态備份下來，解析備份出來的存儲日志獲得了關于邏輯卷結構的部分資訊。
圖一：
将16塊FC槽粘貼标簽，按照原始槽位号登記後從存儲中移除，使用FC槽鏡像裝置“R510+SUN3510”對16塊FC槽進行粗略測試，結果發現16塊盤均能正常識别，分别檢測16塊盤的SMART狀态，結果6号盤的SMART狀态為“警告”狀态和在IBM storage manager中報告一緻。
在windows環境下首先将裝置識别出來的FC槽在磁盤管理器中标記為脫機狀态，進而為原始磁盤提供了一個寫保護功能，然後使用軟體對原始磁盤進行扇區級别鏡像操作，将原始磁盤中的所有實體扇區鏡像到邏輯磁盤并以檔案形式儲存。在鏡像過程中發現6号磁盤的鏡像速度很慢，結合先前對硬碟SMART狀态檢測時發現的問題綜合判斷，6号盤應該存在大量損壞以及不穩定扇區，導緻一般應用軟體無法對其進行操作。
使用壞道硬碟鏡像裝置對6号硬碟進行壞道鏡像操作，在鏡像過程中同時觀察鏡像的速度和穩定性，發現6号盤的壞道并不多，但是存在大量的讀取響應時間長等不穩定扇區，于是調整6号盤的拷貝政策，将遇到壞道跳過扇區數和響應等待時間等參數均作一些修改。繼續對6号盤進行鏡像操作。同時觀察剩餘盤鏡像的情況。
經過鏡像操作後，磁盤已經全部鏡像完成，檢視日志，發現在storage manager和硬碟SMART狀态中均沒有報錯的1号盤也存在壞道，10号和13号盤均存在大量不規律的壞道分布，根據壞道清單使用軟體定位到目标鏡像檔案分析發現，ext3檔案系統的一些關鍵源資料資訊有的已經被壞道所破壞，隻能等待6号盤鏡像完畢後，通過同一條帶進行xor以及根據檔案系統上下文關系的方式手動修複被損壞的檔案系統。
壞道鏡像裝置報告6号盤鏡像完成，但是先前為了最大限度做出有效扇區以及為了保護磁頭設定的拷貝政策會自動跳過一些不穩定扇區，是以現在的鏡像是不完整的，于是調整拷貝政策，繼續鏡像被跳過的扇區，6号盤所有扇區全部鏡像完畢。
得到了所有硬碟的實體扇區鏡像，在平台下使用軟體将所有鏡像檔案全部展開，根據我們對ext3檔案系統的逆向以及日志檔案的分析，得到了16塊FC槽在存儲中的盤序，RAID的塊大小，RAID的校驗走向和方式等資訊，于是嘗試通過軟體的方式虛拟重組RAID，RAID搭建完成後進一步解析ext3檔案系統，通過和使用者溝通提取出了一些oracle的dmp檔案，使用者嘗試進行恢複。
在dmp恢複的過程中，資料庫報告為imp-0008錯誤，通過仔細分析導入dmp檔案的日志檔案，發現恢複的dmp檔案存在問題而導緻dmp導入資料失敗。立刻重新分析raid結構，以及進一步确定ext3檔案系統被破壞的程度，又經過數小時的工作，重新恢複dmp檔案和dbf原始庫檔案，将恢複出來的dmp檔案移交給使用者進行資料導入測試，結果測試順利沒有發現問題，說明這次的資料恢複是成功的，接着對恢複出來的dbf原始庫檔案進行校驗檢測，所有檔案均能通過測試。
資料庫恢複流程
1.拷貝資料庫檔案到原資料庫伺服器，路徑為/home/oracle/tmp/syntong.
作為備份。在根目錄下建立了一個oradata檔案夾，并把備份的整個syntong檔案夾拷貝到oradata目錄下。然後更改oradata檔案夾及其所有檔案的屬組和權限。
2.備份原資料庫環境，包括ORACLE_HOME下product檔案夾下的相關檔案。配置監聽，使用原機中的splplus連接配接到資料庫。嘗試啟動資料庫到nomount狀态。進行基本狀态查詢後，了解到環境和參數檔案沒有問題。 嘗試啟動資料庫到mount狀态，進行狀态查詢沒有問題。啟動資料庫到open狀态。出現報錯：
圖二：
3.經過進一步的檢測和分析，判斷此故障為控制檔案和資料檔案資訊不一緻，這是一類因斷電或突然關機等引起的常見故障。
4.對資料庫檔案進行逐個檢測，檢測到所有資料檔案沒有實體損毀。
5.在mount狀态下，對控制檔案進行備份，alter database backup controlfile to trace as ' /backup/controlfile'；對備份的控制檔案進行檢視修改，取得其中的重建控制檔案指令。把這些指令複制到一個建立腳本檔案controlfile.sql中。
6.關閉資料庫，删除/oradata/syntong/下的3個控制檔案。 啟動資料庫到nomount狀态，執行controlfile.sql 腳本。
圖三：
7.重建控制檔案完成後，直接啟動資料庫，報錯，需要進一步處理。
圖四：
然後執行恢複指令：
圖五：
做媒體恢複，直到傳回報告，恢複完成。
8.嘗試open資料庫。
SQL> alter database open resetlogs;
9.資料庫啟動成功。把原來temp表空間的資料檔案加入到對應的temp表空間中。
10.對資料庫進行各種正常檢查，沒有任何錯誤。
進行emp備份。全庫備份完成，沒有報錯。将應用程式連接配接到資料庫，進行應用層面的資料驗證。
資料驗證結束，資料庫修複完成，資料恢複成功。
本文轉自 宋國建 51CTO部落格，原文連結：http://blog.51cto.com/sun510/2054361，如需轉載請自行聯系原作者