背景介紹：
ibm ds5020 光纖儲存。儲存上一共16塊fc硬碟，單盤容量600g。儲存前面板10號和13號硬碟亮***故障燈，儲存對映到redhat上的卷掛載不上，業務崩潰。
開始工作：
通過ibm storage manager連線到儲存檢視當前儲存狀態，儲存報告邏輯卷狀態失敗，再檢視物理磁碟狀態，發現6號盤報告「警告」，10號和13號盤報告「失敗」，通過ibm storage manager將當前儲存的完整日誌狀態備份下來，解析備份出來的儲存日誌獲得了關於邏輯卷結構的部分資訊。
將16塊fc盤貼上標籤，按照原始槽位號登記後從儲存中移除，使用北亞資料恢復的fc盤映象裝置「dell r510+sun3510」對16塊fc盤進行粗略測試，結果發現16塊盤均能正常識別，分別檢測16塊盤的smart狀態，結果6號盤的smart狀態為「警告」狀態和在ibm storage manager中報告一致。
在windows環境下首先將裝置識別出來的fc盤在磁碟管理器中標記為離線狀態，從而為原始磁碟提供了乙個寫保護功能，然後使用winhex軟體對原始磁碟進行扇區級別映象操作，將原始磁碟中的所有物理扇區映象到windows系統下的邏輯磁碟並以檔案形式儲存。在映象過程中發現6號磁碟的映象速度很慢，結合先前對硬碟smart狀態檢測時發現的問題綜合判斷，6號盤應該存在大量損壞以及不穩定扇區，導致在windows下的一般應用軟體無法對其進行操作。
使用專業壞道硬碟映象裝置對6號硬碟進行壞道映象操作，在映象過程中同時觀察鏡像的速度和穩定性，發現6號盤的壞道並不多，但是存在大量的讀取響應時間長等不穩定扇區，於是調整6號盤的拷貝策略，將遇到壞道跳過扇區數和響應等待時間等引數均作一些修改。繼續對6號盤進行映象操作。同時觀察剩餘盤在windows環境下使用winhex映象的情況。
經過映象操作後，在windows平台下使用winhex映象的磁碟已經全部映象完成，檢視winhex生成的日誌，發現在ibm storage manager和硬碟smart狀態中均沒有報錯的1號盤也存在壞道，10號和13號盤均存在大量不規律的壞道分布，根據壞道列表使用winhex定位到目標映象檔案分析發現，ext3檔案系統的一些關鍵源資料資訊有的已經被壞道所破壞，只能等待6號盤映象完畢後，通過同一條帶進行xor以及根據檔案系統上下文關係的方式手動修復被損壞的檔案系統。
壞道映象裝置報告6號盤映象完成，但是先前為了最大限度做出有效扇區以及為了保護磁頭設定的拷貝策略會自動跳過一些不穩定扇區，所以現在的映象是不完整的，於是調整拷貝策略，繼續映象被跳過的扇區，6號盤所有扇區全部映象完畢。
得到了所有硬碟的物理扇區映象，在windows平台下使用winhex將所有映象檔案全部展開，根據我們對ext3檔案系統的逆向以及日誌檔案的分析，得到了16塊fc盤在儲存中的盤序，raid的塊大小，raid的校驗走向和方式等資訊，於是嘗試通過軟體的方式虛擬重組raid，raid搭建完成後進一步解析ext3檔案系統，通過和使用者溝通提取出了一些oracle的dmp檔案，使用者嘗試進行恢復。
在dmp恢復的過程中，oracle報告為imp-0008錯誤，聯絡北亞的oracle工程師，通過仔細分析匯入dmp檔案的日誌檔案，發現恢復的dmp檔案存在問題而導致dmp匯入資料失敗。立刻重新分析raid結構，以及進一步確定ext3檔案系統被破壞的程度，又經過數小時的工作，重新恢復dmp檔案和dbf原始庫檔案，將恢復出來的dmp檔案移交給使用者進行資料匯入測試，結果測試順利沒有發現問題，說明這次的資料恢復是成功的，接著對恢復出來的dbf原始庫檔案進行校驗檢測，所有檔案均能通過測試。
北亞的資料庫工程師到達現場，和使用者溝通後決定使用恢復出來的dbf原始庫檔案進行操作，以確保能把資料恢復到最佳狀態。
資料庫恢復流程
1. 拷貝資料庫檔案到原資料庫伺服器，路徑為/home/oracle/tmp/syntong.
作為備份。在根目錄下建立了乙個oradata資料夾，並把備份的整個syntong資料夾拷貝到oradata目錄下。然後更改oradata資料夾及其所有檔案的屬組和許可權。
2. 備份原資料庫環境，包括oracle_home下product資料夾下的相關檔案。配置監聽，使用原機中的splplus連線到資料庫。嘗試啟動資料庫到nomount狀態。進行基本狀態查詢後，了解到環境和引數檔案沒有問題。嘗試啟動資料庫到mount狀態，進行狀態查詢沒有問題。啟動資料庫到open狀態。出現報錯：
ora-01122: databasefile 1 failed verification check
ora-01110: data file1: '/oradata/syntong/system01.dbf'
ora-01207: file ismore recent than control file - old control file
3. 經過進一步的檢測和分析，判斷此故障為控制檔案和資料檔案資訊不一致，這是一類因斷電或突然關機等引起的常見故障。
4. 對資料庫檔案進行逐個檢測，檢測到所有資料檔案沒有物理損毀。
5.在mount狀態下，對控制檔案進行備份，alter database backupcontrolfile to trace as ' /backup/controlfile'；對備份的控制檔案進行檢視修改，取得其中的重建控制檔案命令。把這些命令複製到乙個新建指令碼檔案controlfile.sql中。
6. 關閉資料庫，刪除/oradata/syntong/下的3個控制檔案。 啟動資料庫到nomount狀態，執行controlfile.sql 指令碼。
sql>startupnomount
sql>@controlfile.sql
7. 重建控制檔案完成後，直接啟動資料庫，報錯，需要進一步處理。
sql> alterdatabase open;
alter database open *
error at line 1:
ora-01113: file 1needs media recovery
ora-01110: data file1: '/free/oracle/oradata/orcl/system01.dbf'
然後執行恢復命令：
recover databaseusing backup controlfile until cancel;
recovery of onlineredo log: thread 1 group 1 seq 22 reading mem 0
mem# 0 errs 0:/free/oracle/oradata/orcl/redo01.log …
做介質恢復，直到返回報告，恢復完成。
8. 嘗試open資料庫。
sql> alterdatabase open resetlogs;
9. 資料庫啟動成功。把原來temp表空間的資料檔案加入到對應的temp表空間中。
10. 對資料庫進行各種常規檢查，沒有任何錯誤。
11. 進行emp備份。全庫備份完成，沒有報錯。將應用程式連線到資料庫，進行應用層面的資料驗證。
資料驗證結束，資料庫修復完成，資料恢復成功。
資料庫修復
sql2008資料庫 檢測資料庫 dbcc checkdb 單使用者和多使用者模式切換 alter database dbname資料庫 set single user 單使用者 alter database dbname資料庫 set multi user 多使用者 修復dbcc checktab...
SQL資料庫修復 資料庫置疑修復
sql資料庫修復的三大核心技術 1 磁碟陣列分析重組技術 2 資料庫恢復與修復技術 3 scsi盤物理故障開盤技術。至今已經成功恢復數百台伺服器的sql資料庫，使用者覆蓋全國。導致sql資料庫丟失的原因 1 各種原因 誤刪除 誤格式化 斷電等造成的ms sql server資料庫檔案破壞。2 ms ...
資料庫和資料庫物件
系統資料庫是指安裝完mysql伺服器後，會附帶的一些資料庫，系統資料庫會記錄一些必需的資訊，使用者不能直接修改這些系統資料庫。各個系統資料庫的作用如下 information schema 主要儲存系統中的一些資料庫物件資訊，如使用者表資訊 列資訊 許可權資訊 字符集資訊和分割槽資訊等。perfor...