服務(wù)器存儲數(shù)據(jù)恢復(fù)環(huán)境&故障：
一臺某品牌DS4700存儲中有14塊硬盤組建raid，存放的是oracle數(shù)據(jù)庫。存儲中有兩塊硬盤的指示燈亮黃色，raid崩潰，卷無法掛載，業(yè)務(wù)全部癱瘓。

服務(wù)器存儲故障檢測：
服務(wù)器數(shù)據(jù)恢復(fù)工程師通過IBM storage manager連接存儲查看服務(wù)器存儲的當(dāng)前狀態(tài)，發(fā)現(xiàn)邏輯卷狀態(tài)失敗。對物理磁盤狀態(tài)進行查看，發(fā)現(xiàn)13號磁盤狀態(tài)為“警告”，10號和11號磁盤狀態(tài)為“失敗”。通過IBM storage manager對當(dāng)前存儲的全部日志進行備份并解析邏輯卷結(jié)構(gòu)信息。

服務(wù)器存儲數(shù)據(jù)恢復(fù)過程：
1、將服務(wù)器存儲中全部磁盤編號后取出槽位，由硬件工程師進行物理故障檢測。經(jīng)過初步檢測，所有硬盤均可以正常識別，13號盤SMART狀態(tài)為“警告”，和在IBM storage manager中的狀態(tài)一致。
2、服務(wù)器數(shù)據(jù)恢復(fù)工程師在windows環(huán)境下的磁盤管理器中將可以識別的磁盤標(biāo)記為脫機狀態(tài)，使用工具將所有磁盤進行扇區(qū)級別鏡像操作（在鏡像過程中13號硬盤的鏡像速度極其緩慢，初步判斷該盤存在壞道或者不穩(wěn)定/損壞扇區(qū)，需要使用專業(yè)設(shè)備處理）。在使用專業(yè)設(shè)備對13號硬盤做鏡像的過程中觀察鏡像狀態(tài)，發(fā)現(xiàn)13號盤的壞道并不多，只是存在大量不穩(wěn)定扇區(qū)。調(diào)整該磁盤的鏡像策略后繼續(xù)鏡像。鏡像完成后將所有磁盤按照編號還原到原存儲中。后續(xù)的數(shù)據(jù)分析和數(shù)據(jù)恢復(fù)操作都基于鏡像文件進行，避免對原始磁盤數(shù)據(jù)造成二次破壞。
3、基于鏡像文件查看生成的日志，發(fā)現(xiàn)在IBM storage manager和硬盤SMART狀態(tài)中均沒有發(fā)現(xiàn)異常的1號盤、10號和11號盤均存在大量不規(guī)律的壞道分布。結(jié)合壞道列表情況進行分析，EXT3文件系統(tǒng)中的部分關(guān)鍵性源數(shù)據(jù)處于壞道區(qū)域，北亞企安數(shù)據(jù)恢復(fù)工程師通過13號硬盤的鏡像文件進行同一條帶的xor，
并根據(jù)文件系統(tǒng)的上下關(guān)系手動修復(fù)損壞的文件系統(tǒng)。
4、通過對ext3文件系統(tǒng)的逆向以及日志文件的分析獲取到盤序、raid校驗方向、raid塊大小、raid校驗方式等信息，利用獲取到的信息虛擬重組raid。重組完成后解析EXT3文件系統(tǒng)，將oracle數(shù)據(jù)庫中的dmp文件進行部分提取。
5、在恢復(fù)dmp的過程中出現(xiàn)內(nèi)容為“imp-0008”的報錯，經(jīng)過分析發(fā)現(xiàn)報錯原因是dmp文件有問題。再次重組raid并重新導(dǎo)出dmp文件和dbf原始庫文件進行測試，dbf原始庫文件均能通過測試。
6、把數(shù)據(jù)庫文件拷貝到原數(shù)據(jù)庫服務(wù)器中，路徑為“/home/oracle/tmp/syntong”。在根目錄下創(chuàng)建一個oradata文件夾，把整個syntong文件夾拷貝到oradata目錄下，更改oradata文件夾及其所有文件的屬組和權(quán)限。
7、備份原數(shù)據(jù)庫環(huán)境，包括ORACLE_HOME下product文件夾下的相關(guān)文件。配置監(jiān)聽，使用splplus連接到數(shù)據(jù)庫，嘗試啟動數(shù)據(jù)庫到nomount狀態(tài)。進行狀態(tài)查詢沒有發(fā)現(xiàn)環(huán)境和參數(shù)文件有問題。 嘗試啟動數(shù)據(jù)庫到mount狀態(tài)，進行狀態(tài)查詢沒有問題。啟動數(shù)據(jù)庫到open狀態(tài)。出現(xiàn)報錯：
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/oradata/syntong/system01.dbf'
ORA-01207: file is more recent than control file - old control file
經(jīng)過檢測和分析，判斷此故障為控制文件和數(shù)據(jù)文件信息不一致，這是一種常見的由于異常關(guān)機所引起的故障。
8、對數(shù)據(jù)庫文件進行逐個檢測，經(jīng)過檢測沒有發(fā)現(xiàn)有數(shù)據(jù)庫文件存在物理損毀的情況。
9、在mount狀態(tài)下備份控制文件，alter database backup controlfile to trace as ' /backup/controlfile'；對備份的控制文件進行查看修改，獲取到其中的重建控制文件命令。把這些命令復(fù)制到一個新建腳本文件controlfile.sql中。
10、關(guān)閉數(shù)據(jù)庫，刪除/oradata/syntong/下的3個控制文件。 啟動數(shù)據(jù)庫到nomount狀態(tài)，執(zhí)行controlfile.sql 腳本。
SQL>startup nomount
SQL>@controlfile.sql
11、重建控制文件后，直接啟動數(shù)據(jù)庫報錯，需要進一步處理。
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/free/oracle/oradata/orcl/system01.dbf'
然后執(zhí)行恢復(fù)命令：
recover database using backup controlfile until cancel;
Recovery of Online Redo Log: Thread 1 Group 1 Seq 22 Reading mem 0
Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log
…
做介質(zhì)恢復(fù)，直到返回報告，恢復(fù)完成。
12、嘗試open數(shù)據(jù)庫。
SQL> alter database open resetlogs;
13、數(shù)據(jù)庫啟動成功。把原來temp表空間的數(shù)據(jù)文件加入到對應(yīng)的temp表空間中。
14、對數(shù)據(jù)庫進行各種常規(guī)檢查，沒有發(fā)現(xiàn)任何錯誤。
15、進行emp備份，全庫備份完成，沒有報錯。將應(yīng)用程序連接到數(shù)據(jù)庫，進行應(yīng)用層面的數(shù)據(jù)驗證，一切正常，本次數(shù)據(jù)恢復(fù)工作完成。

審核編輯 黃宇