本案例詳細(xì)介紹了數(shù)據(jù)庫恢復(fù)的過程，包括RAID重組和數(shù)據(jù)庫數(shù)據(jù)的修復(fù)與驗(yàn)證。

　　故障設(shè)備

　　IBM DS5020 光纖存儲

　　故障描述

　　存儲上一共16塊FC硬盤，單盤容量600G。存儲前面板10號和13號硬盤亮***故障燈，存儲映射到redhat上的卷掛載不上，業(yè)務(wù)崩潰。

　　存儲恢復(fù)流程

　　通過IBM storage manager連接到存儲查看當(dāng)前存儲狀態(tài)，存儲報(bào)告邏輯卷狀態(tài)失敗，再查看物理磁盤狀態(tài)，發(fā)現(xiàn)6號盤報(bào)告“警告”，10號和13號盤報(bào)告“失敗”，通過IBM storage manager將當(dāng)前存儲的完整日志狀態(tài)備份下來，解析備份出來的存儲日志獲得了關(guān)于邏輯卷結(jié)構(gòu)的部分信息。

　　將16塊FC盤粘貼標(biāo)簽，按照原始槽位號登記后從存儲中移除，使用我們的FC盤鏡像設(shè)備“DELL R510+SUN3510”對16塊FC盤進(jìn)行粗略測試，結(jié)果發(fā)現(xiàn)16塊盤均能正常識別，分別檢測16塊盤的SMART狀態(tài)，結(jié)果6號盤的SMART狀態(tài)為“警告”狀態(tài)和在IBM storage manager中報(bào)告一致。

　　在windows環(huán)境下首先將設(shè)備識別出來的FC盤在磁盤管理器中標(biāo)記為脫機(jī)狀態(tài)，從而為原始磁盤提供了一個寫保護(hù)功能，然后使用winhex軟件對原始磁盤進(jìn)行扇區(qū)級別鏡像操作，將原始磁盤中的所有物理扇區(qū)鏡像到windows系統(tǒng)下的邏輯磁盤并以文件形式保存。在鏡像過程中發(fā)現(xiàn)6號磁盤的鏡像速度很慢，結(jié)合先前對硬盤SMART狀態(tài)檢測時發(fā)現(xiàn)的問題綜合判斷，6號盤應(yīng)該存在大量損壞以及不穩(wěn)定扇區(qū)，導(dǎo)致在windows下的一般應(yīng)用軟件無法對其進(jìn)行操作。

　　使用專業(yè)壞道硬盤鏡像設(shè)備對6號硬盤進(jìn)行壞道鏡像操作，在鏡像過程中同時觀察鏡像的速度和穩(wěn)定性，發(fā)現(xiàn)6號盤的壞道并不多，但是存在大量的讀取響應(yīng)時間長等不穩(wěn)定扇區(qū)，于是調(diào)整6號盤的拷貝策略，將遇到壞道跳過扇區(qū)數(shù)和響應(yīng)等待時間等參數(shù)均作一些修改。繼續(xù)對6號盤進(jìn)行鏡像操作。同時觀察剩余盤在windows環(huán)境下使用winhex鏡像的情況。

　　經(jīng)過鏡像操作后，在windows平臺下使用winhex鏡像的磁盤已經(jīng)全部鏡像完成，查看winhex生成的日志，發(fā)現(xiàn)在IBM storage manager和硬盤SMART狀態(tài)中均沒有報(bào)錯的1號盤也存在壞道，10號和13號盤均存在大量不規(guī)律的壞道分布，根據(jù)壞道列表使用winhex定位到目標(biāo)鏡像文件分析發(fā)現(xiàn)，ext3文件系統(tǒng)的一些關(guān)鍵源數(shù)據(jù)信息有的已經(jīng)被壞道所破壞，只能等待6號盤鏡像完畢后，通過同一條帶進(jìn)行xor以及根據(jù)文件系統(tǒng)上下文關(guān)系的方式手動修復(fù)被損壞的文件系統(tǒng)。

　　壞道鏡像設(shè)備報(bào)告6號盤鏡像完成，但是先前為了最大限度做出有效扇區(qū)以及為了保護(hù)磁頭設(shè)置的拷貝策略會自動跳過一些不穩(wěn)定扇區(qū)，所以現(xiàn)在的鏡像是不完整的，于是調(diào)整拷貝策略，繼續(xù)鏡像被跳過的扇區(qū)，6號盤所有扇區(qū)全部鏡像完畢。

　　得到了所有硬盤的物理扇區(qū)鏡像，在windows平臺下使用winhex將所有鏡像文件全部展開，根據(jù)我們對ext3文件系統(tǒng)的逆向以及日志文件的分析，得到了16塊FC盤在存儲中的盤序，RAID的塊大小，RAID的校驗(yàn)走向和方式等信息，于是嘗試通過軟件的方式虛擬重組RAID，RAID搭建完成后進(jìn)一步解析ext3文件系統(tǒng)，通過和用戶溝通提取出了一些oracle的dmp文件，用戶嘗試進(jìn)行恢復(fù)。

　　在dmp恢復(fù)的過程中，oracle報(bào)告為imp-0008錯誤，聯(lián)系北亞的oracle工程師，通過仔細(xì)分析導(dǎo)入dmp文件的日志文件，發(fā)現(xiàn)恢復(fù)的dmp文件存在問題而導(dǎo)致dmp導(dǎo)入數(shù)據(jù)失敗。立刻重新分析raid結(jié)構(gòu)，以及進(jìn)一步確定ext3文件系統(tǒng)被破壞的程度，又經(jīng)過數(shù)小時的工作，重新恢復(fù)dmp文件和dbf原始庫文件，將恢復(fù)出來的dmp文件移交給用戶進(jìn)行數(shù)據(jù)導(dǎo)入測試，結(jié)果測試順利沒有發(fā)現(xiàn)問題，說明這次的數(shù)據(jù)恢復(fù)是成功的，接著對恢復(fù)出來的dbf原始庫文件進(jìn)行校驗(yàn)檢測，所有文件均能通過測試。

　　北亞的數(shù)據(jù)庫工程師到達(dá)現(xiàn)場，和用戶溝通后決定使用恢復(fù)出來的dbf原始庫文件進(jìn)行操作，以確保能把數(shù)據(jù)恢復(fù)到最佳狀態(tài)。

　　數(shù)據(jù)庫恢復(fù)流程

　　1.?拷貝數(shù)據(jù)庫文件到原數(shù)據(jù)庫服務(wù)器，路徑為/home/oracle/tmp/syntong.

　　作為備份。在根目錄下創(chuàng)建了一個oradata文件夾，并把備份的整個syntong文件夾拷貝到oradata目錄下。然后更改oradata文件夾及其所有文件的屬組和權(quán)限。

　　2.?備份原數(shù)據(jù)庫環(huán)境，包括ORACLE_HOME下product文件夾下的相關(guān)文件。配置監(jiān)聽，使用原機(jī)中的splplus連接到數(shù)據(jù)庫。嘗試啟動數(shù)據(jù)庫到nomount狀態(tài)。進(jìn)行基本狀態(tài)查詢后，了解到環(huán)境和參數(shù)文件沒有問題。 嘗試啟動數(shù)據(jù)庫到mount狀態(tài)，進(jìn)行狀態(tài)查詢沒有問題。啟動數(shù)據(jù)庫到open狀態(tài)。出現(xiàn)報(bào)錯：

　　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

　　3.?經(jīng)過進(jìn)一步的檢測和分析，判斷此故障為控制文件和數(shù)據(jù)文件信息不一致，這是一類因斷電或突然關(guān)機(jī)等引起的常見故障。

　　4.?對數(shù)據(jù)庫文件進(jìn)行逐個檢測，檢測到所有數(shù)據(jù)文件沒有物理損毀。

　　5.??在mount狀態(tài)下，對控制文件進(jìn)行備份，alter database backup controlfile to trace as ' /backup/controlfile'；對備份的控制文件進(jìn)行查看修改，取得其中的重建控制文件命令。把這些命令復(fù)制到一個新建腳本文件controlfile.sql中。

　　6.??關(guān)閉數(shù)據(jù)庫，刪除/oradata/syntong/下的3個控制文件。 啟動數(shù)據(jù)庫到nomount狀態(tài)，執(zhí)行controlfile.sql 腳本。

　　SQL>startup nomount

　　SQL>@controlfile.sql

　　7.?重建控制文件完成后，直接啟動數(shù)據(jù)庫，報(bào)錯，需要進(jìn)一步處理。

　　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ù)，直到返回報(bào)告，恢復(fù)完成。

　　8.?嘗試open數(shù)據(jù)庫。

　　SQL> alter database open resetlogs;

　　9.? 數(shù)據(jù)庫啟動成功。把原來temp表空間的數(shù)據(jù)文件加入到對應(yīng)的temp表空間中。

　　10.?對數(shù)據(jù)庫進(jìn)行各種常規(guī)檢查，沒有任何錯誤。

　　11. 進(jìn)行emp備份。全庫備份完成，沒有報(bào)錯。將應(yīng)用程序連接到數(shù)據(jù)庫，進(jìn)行應(yīng)用層面的數(shù)據(jù)驗(yàn)證。

　　數(shù)據(jù)驗(yàn)證結(jié)束，數(shù)據(jù)庫修復(fù)完成，數(shù)據(jù)恢復(fù)成功。

?

轉(zhuǎn)載于:https://blog.51cto.com/zhangyu/1738696

總結(jié)

以上是生活随笔為你收集整理的某大学数据恢复报告的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。