服務器存儲數(shù)據(jù)恢復環(huán)境：
某品牌光纖存儲上共有16塊FC硬盤。存儲上的卷映射到Linux操作系統(tǒng)上。Linux操作系統(tǒng)上運行Oracle數(shù)據(jù)庫。

服務器存儲故障&檢測：
存儲上2塊硬盤故障燈亮起，存儲映射到linux操作系統(tǒng)上的卷掛載不上，業(yè)務中斷。
使用storage manager連接到存儲查看存儲目前狀態(tài)，發(fā)現(xiàn)邏輯卷狀態(tài)失?。?號盤報告“警告”，10號盤和13號盤報告“失敗”；通過storage manager將當前存儲的完整日志狀態(tài)備份下來，解析備份的日志獲取關(guān)于邏輯卷結(jié)構(gòu)的部分信息。
將16塊FC盤標記后從存儲中取出，使用專業(yè)設備檢測后發(fā)現(xiàn)16塊盤均能正常識別，6號盤的SMART狀態(tài)為“警告”，和在storage manager中的報告結(jié)果一致。
將所有磁盤以只讀方式進行扇區(qū)級全盤鏡像。在鏡像過程中觀察鏡像的速度和穩(wěn)定性，發(fā)現(xiàn)6號盤的鏡像速度異常，結(jié)合之前檢測結(jié)果，基本上可以判斷6號盤應該存在損壞或者不穩(wěn)定扇區(qū)。經(jīng)過觀察發(fā)現(xiàn)6號盤的壞道并不多，但是存在大量的讀取響應時間長的不穩(wěn)定扇區(qū)。調(diào)整鏡像策略繼續(xù)對6號盤做鏡像。
所有磁盤鏡像完成后，查看日志，發(fā)現(xiàn)在storage manager和硬盤SMART狀態(tài)檢測中均沒有發(fā)現(xiàn)問題的1號盤也存在壞道，10號和13號盤均存在大量不規(guī)律的壞道。根據(jù)壞道列表定位到目標鏡像文件，分析后發(fā)現(xiàn)ext3文件系統(tǒng)的部分關(guān)鍵源數(shù)據(jù)信息已經(jīng)被壞道破壞。只能等所有磁盤鏡像完畢后，
通過同一條帶進行xor以及根據(jù)文件系統(tǒng)上下文關(guān)系手動修復被損壞的文件系統(tǒng)。
雖然通過調(diào)整鏡像策略完成6號盤的鏡像，但是調(diào)整后的鏡像策略會自動跳過一些不穩(wěn)定扇區(qū)，所以做出來的鏡像是不完整的。再次調(diào)整鏡像策略，繼續(xù)鏡像被跳過的扇區(qū)，直到全部鏡像完成。
基于鏡像文件分析所有磁盤底層數(shù)據(jù)。通過對ext3文件系統(tǒng)的逆向分析以及對日志文件的分析，獲取到16塊FC盤在存儲中的盤序、RAID的塊大小、RAID的校驗走向和方式等重組RAID所需要的信息。嘗試使用上述獲取到的信息重組RAID，重組完成后解析ext3文件系統(tǒng)。和用戶溝通后，提取出一些oracle的dmp文件，用戶嘗試使用這些dmp文件恢復Oracle數(shù)據(jù)庫數(shù)據(jù)。
在使用dmp文件恢復Oracle數(shù)據(jù)庫的過程中，數(shù)據(jù)庫報告imp-0008錯誤。對導入dmp文件的日志文件進行分析，發(fā)現(xiàn)恢復出來的dmp文件存在問題。重新分析raid結(jié)構(gòu)，進一步確定ext3文件系統(tǒng)被破壞的程度，重新恢復dmp文件和dbf原始庫文件。將恢復出來的dmp文件進行導入測試，這次沒有發(fā)現(xiàn)問題。對恢復出來的dbf原始庫文件進行校驗檢測，所有文件均能通過檢測。

Oracle數(shù)據(jù)庫恢復過程：
1、拷貝數(shù)據(jù)庫文件到原數(shù)據(jù)庫服務器，目標路徑為/home/oracle/tmp/syntong。
在根目錄下創(chuàng)建一個oradata文件夾，將備份的syntong文件夾拷貝到oradata目錄下。更改oradata文件夾及其所有文件的屬組和權(quán)限。
2、備份原數(shù)據(jù)庫環(huán)境，包括ORACLE_HOME下product文件夾下的相關(guān)文件。配置監(jiān)聽，使用原機中的splplus連接到數(shù)據(jù)庫。嘗試啟動數(shù)據(jù)庫到nomount狀態(tài)，查詢基本狀態(tài)，確認環(huán)境和參數(shù)文件均沒有問題。 嘗試啟動數(shù)據(jù)庫到mount狀態(tài)，查詢狀態(tài)沒有問題。啟動數(shù)據(jù)庫到open狀態(tài)時報錯。

北亞企安數(shù)據(jù)恢復—光纖存儲數(shù)據(jù)恢復

3、進一步檢測和分析后基本上可以判斷此故障發(fā)生原因是控制文件和數(shù)據(jù)文件信息不一致，這一類問題通常是因為斷電或異常關(guān)機導致的。
4、逐個檢測數(shù)據(jù)庫文件，沒有發(fā)現(xiàn)有文件存在物理損壞。
5、在mount狀態(tài)下備份控制文件：alter database backup controlfile to trace as ' /backup/controlfile'。查看&修改備份的控制文件，獲取重建控制文件命令。將這些命令復制到一個新建腳本文件controlfile.sql中。
6、關(guān)閉數(shù)據(jù)庫，刪除/oradata/syntong/下的3個控制文件。 啟動數(shù)據(jù)庫到nomount狀態(tài)，執(zhí)行controlfile.sql 腳本。

北亞企安數(shù)據(jù)恢復—光纖存儲數(shù)據(jù)恢復

7、完成控制文件的重建后，啟動數(shù)據(jù)庫。仍然報錯，需要進一步處理。

北亞企安數(shù)據(jù)恢復—光纖存儲數(shù)據(jù)恢復

執(zhí)行恢復命令：

北亞企安數(shù)據(jù)恢復—光纖存儲數(shù)據(jù)恢復

做介質(zhì)恢復，直到返回報告。
8、嘗試open數(shù)據(jù)庫。
SQL> alter database open resetlogs;
9、數(shù)據(jù)庫啟動成功。把原temp表空間的數(shù)據(jù)文件加入到對應的temp表空間中。
10、對數(shù)據(jù)庫進行各種常規(guī)檢查，沒有發(fā)現(xiàn)任何問題
11、進行emp備份。全庫備份完成，沒有報錯。將應用程序連接到數(shù)據(jù)庫驗證數(shù)據(jù)。
12、經(jīng)過仔細驗證，用戶方確認數(shù)據(jù)庫數(shù)據(jù)沒有問題，認可數(shù)據(jù)恢復結(jié)果。

審核編輯 黃宇