Oralce 資料庫的災難恢復(轉)

Oralce 資料庫的災難恢復(轉)[@more@]

　　隨著辦公自動化和電子商務的飛速發展，企業對資訊系統的依賴性越來越高，資料庫作為資訊系統的核心擔當著重要的角色。尤其在一些對資料可靠性要求很高的行業如銀行、證券、電信等，如果發生意外停機或資料丟失其損失會十分慘重。為此資料庫管理員應針對具體的業務要求制定詳細的資料庫備份與災難恢復策略，並透過模擬故障對每種可能的情況進行嚴格測試，只有這樣才能保證資料的高可用性。資料庫的備份是一個長期的過程，而恢復只在發生事故後進行，恢復可以看作是備份的逆過程，恢復的程度的好壞很大程度上依賴於備份的情況。此外，資料庫管理員在恢復時採取的步驟正確與否也直接影響最終的恢復結果，本文主要針對Oracle資料庫可能遇到的各種故障提供了相應的恢復的方法，僅供大家參考。

　　要對Oracle資料庫備份與恢復有清晰的認識，首先有必要對資料庫的幾種執行狀態有充分的瞭解。Oracle資料庫的執行狀態主要分為3種，他們依次為：

　　l Nomount（非安裝）Oracle只是讀取ini檔案中的配置資訊，並初始化SGA區。

　　l Mount（安裝）Oracle除了需要讀取ini檔案還要讀取控制檔案，並從中獲取有關資料庫的物理結構等資訊。

　　l Open（開啟）資料庫要檢查所有檔案處於同一時間點，對錯誤進行恢復對未完成事務回滾，並最終可以允許使用者訪問。

　　資料庫的備份主要分為三種型別：冷備份；熱備份；邏輯備份；

　　資料庫的備份不是本文討論的重點，在這裡只作一個概要的介紹，Oracle資料庫備份主要有：

　　l Cold Backup（冷備份） 主要指在關閉資料庫的狀態下進行的資料庫完全備份，備份內容包括所有資料檔案、控制檔案、聯機日誌檔案、ini檔案。

　　l Hot Backup（熱備份） 指在資料庫處於執行狀態下，對資料檔案和控制檔案進行備份，要使用熱備份必須將資料庫執行在(Archive Log)歸檔方式下。

　　l Export（邏輯備份）這是最簡單的備份方法，可按資料庫中某個表、某個使用者或整個資料庫來匯出，並且支援全部、累計、增量三種方式。使用這種方法，資料庫必須處於開啟狀態，而且如果資料庫不是在restrict狀態將不能保證匯出資料的一致性。

　　資料庫的恢復可分為兩大類：完全恢復；不完全恢復；

　　完全恢復指將資料庫恢復到發生故障的時間點，不丟失任何資料。不完全恢復指將資料庫恢復到發生故障前的某一個時間點，此時間點以後的所有改動將會丟失。如果沒有特殊需求，我們建議應儘量使用完全恢復。

　　Oracle資料庫的恢復過程分兩步進行，首先將把存放在重做日誌檔案中的所有重做運用到資料檔案，之後對重做中所有未提交的事務進行回滾，這樣所有資料就恢復到發生災難那一時刻了。資料庫的恢復只能在發生故障之前的資料檔案上運用重做，將其恢復到故障時刻，而不能將資料檔案反向回滾到之前的某一個時刻。舉個例子，我們有一個2001/1/1的資料庫備份，當2001/5/1使我們發現資料庫中資料發生混亂，希望將資料庫恢復到2001/4/30時的狀態，我們只能先恢復2001/1/1的資料庫備份然後在其上運用重做記錄使其前滾到2001/4/30時的狀態，而不能將2001/5/1的資料庫向後回滾到2001/4/30。

　　為了系統的設計資料庫的恢復方案，我們先對可能遇到的錯誤進行分類，Oracle資料庫錯誤主要分為5大類：

　　l SQL語句失敗

　　l 執行緒失敗

　　l 例項失敗

　　l 使用者操作失敗

　　l 儲存裝置失敗

　　如果發生前三種失敗，不需要我們人為干涉，Oracle系統會自動進行恢復。對於使用者操作型的失敗（如誤刪除資料），我們採取的補救措施主要有匯入最新的邏輯備份或進行到某一時間點的不完全恢復。從Oracle 8之後的新版本中引入了基於表空間的時間點恢復(TSPITR)，可以單獨將包含錯誤操作的表空間恢復到指定時間，而不必對整個資料庫進行不完全恢復。當錯誤操作發現比較及時而且資料量不大的情況下也可以考慮使用logminer生成反向SQL。

　　針對儲存裝置的失敗的情況比較複雜也是本文討論的重點，儲存裝置的失敗必然會使放置在其上的檔案變為不可用，我們先將Oracle資料庫所涉及到的檔案進行一個劃分，主要可分為：

　　l Oracle的系統檔案，指Oracle的執行檔案，各種應用程式

　　l 資料庫控制檔案

　　l 資料庫聯機重做日誌檔案

　　l 資料檔案

　　l 歸檔日誌檔案

　　避免第一種檔案失敗主要依賴系統管理員進行作業系統級的備份，當發生事故後只能依靠作業系統備份將其恢復。

　　控制檔案中記錄著整個資料庫的結構、每個資料檔案的狀況、系統SCN、檢查點計數器等重要資訊，在建立資料庫時會讓使用者指定三個位置來存放控制檔案，他們之間互為映象，當其中任何一個發生故障，只需將其從ini檔案中註釋掉故障資料檔案就可重新將資料啟動。當所有控制全部失效時，可以在Nomount模式下執行create controlfile來重新生成控制檔案，但必須提供redo log，data file，檔名和地址以及MAXLOGFILES，MAXDATAFILES，MAXINSTANCES等資訊。如果失敗之前執行過alter database backup controlfile to trace或alter database backup controlfile to ‘xxx’對控制檔案作備份，恢復時可使用生成的指令碼來重建或用備份檔案覆蓋，如果使用了舊的控制檔案在恢復時要使用recover xxx using backup controlfile選項來進行恢復，並使用resetlogs選項來開啟資料庫。

　　如果丟失的是聯機日誌檔案，分兩種情況處理1、丟失的是非活動的日誌檔案；2、丟失的是當前啟用的日誌檔案。

　　如果是第一種情況，而發生故障的日誌檔案組又具有多個成員，可以先將資料庫shutdown，然後用作業系統命令將損壞日誌檔案組中好的日誌成員檔案把損壞的成員檔案覆蓋（在同一個日誌成員組中的所有日誌檔案的各為鏡象的），如果其物理位置不可用可將其複製到新的驅動器上，使用alter database rename file ‘xxxx’ to ‘xxxx’改變檔案位置，之後啟動資料庫，如果正常馬上進行一個冷備份。如果損壞的日誌組中只有一個日誌成員，先mount上資料庫，將其轉換為noarchivelog模式，執行alter database add logfile member ‘xxx’ to group ‘x’給相關組增加一個成員，再執行alter database drop logfile member ‘bad_file’將損壞的日誌檔案刪除，由於資料庫的結構發生變動需要備份控制檔案，之後將資料庫改回archivelog模式，做一個冷備份。

　　如果丟失的是當前啟用的日誌檔案，資料庫又沒有映象而且當前日誌組中所有成員均變為不可用。首先將資料庫shutdown abort，從最近的一次全備份中恢復所有的資料檔案，將資料庫啟動到mount狀態。如果原來的日誌檔案物理位置不可用，使用alter database rename file ‘xxx’ to ‘xxx’改變檔案的存放位置。然後，使用recover database until cancel命令來恢復資料庫，直到提示最後一個歸檔日誌運用完之後，輸入cancel。之後用alter database open resetlogs開啟資料庫，如果沒有問題，立即進行一個冷備份。注意！所有包含在損壞的redo log中的資訊將會丟失，也就是說資料庫崩潰前已經提交的資料有可能會丟失。這對於某些要求很高的應用將會損失慘重，因此應儘量使每個日誌組具有多個日誌成員，並且放置在不同的驅動器上一防止發生介質故障。

　　資料檔案發生故障的情況也分為多種情況，1、丟失包含在SYSTEM表空間的資料檔案；2、丟失沒有回滾段的非SYSTEM資料檔案；3、丟失有回滾段的非SYSTEM資料檔案。

　　如果損壞的是系統表空間的資料檔案。唯一的辦法是從上一次備份中恢復受損的資料檔案，（如果原位置不可用使用alter database rename命令改變新檔案的位置），之後在資料庫mount的狀態下執行recover database/datafile對資料庫進行回覆，才能將資料庫開啟。注意：當SYSTEM表空間或其中的資料檔案離線，資料庫是無法被開啟的，因此必須在mount狀態下將所有的恢復工作完成。

　　當丟失的資料檔案不屬於系統表空間而且也不包含回滾段時，有可選擇在資料庫的兩種狀態下進行恢復---在資料庫open的狀態或者在資料庫mount的狀態。如果使用者急於訪問資料庫中未受損部分的資料或對損壞的資料檔案進行恢復需要很長時間，可以先使受損的資料檔案離線，將資料庫開啟給使用者訪問，再恢復受損的資料檔案最後將其聯機。步驟如下：先在資料庫mount時，將相關的資料檔案或表空間進行離線alter database datafile xxx offline，然後將資料庫open，這樣就能使資料庫未受損的部分先供使用者訪問，之後再進行recover datafile/tablespace，完成後用alter database datafile/tablespace ‘xxx’ online使其恢復聯機就可被訪問了。 當然使用者也可以選擇在資料庫mount狀態下，用recover database/datafile將所有的恢復工作做完，將所有資料檔案一起開啟供使用者訪問。

　　如果丟失的資料檔案是最後一種情況，即包含有回滾段的非系統表空間資料檔案。也可以選擇是在資料庫先open的狀態還是在mount狀態下恢復。不過與上一種情況不同的是當包含回滾段的資料檔案損壞時，如果使其先offline將資料庫開啟，那麼所有資料庫崩潰前未提交的事務涉及到的表將無法訪問，也就是說在回滾段恢復前其中涉及的物件都不允許被訪問。而且當所有包含回滾段的資料檔案都在offline狀態時，資料庫無法進行任何DML操作，因此在資料庫open狀態恢復包含回滾段的資料檔案時，可以先建立幾個臨時回滾段供資料使用create rollback segment temp1 tablespace system; alter rollback segment temp1 online;，當資料檔案恢復後再將他們刪除alter rollback segment temp1 offline; drop rollback segment temp1;。注意：當用這種方法使恢復的資料檔案online之後，所有的原有回滾段將處於offline狀態，必須手工使用alter rollback segment RBSxx online;使他們恢復聯機狀態，這樣才能被資料庫正常使用。如果在資料庫mount狀態下完成所有恢復，則不需要上述步驟。

　　如果丟失資料檔案後，使用者發現沒有故障前的資料檔案的備份，而且自從丟失的資料檔案最早建立之後一直沒有使用過resetlogs選項開啟過資料庫。也就是說使用者的控制檔案是在損壞的資料檔案建立前建立的，歸檔日誌中包括對損壞資料檔案的所有重做記錄。使用者就還有一種恢復方法，使用者可以先將損壞的資料檔案或表空間離線alter database datafile / tablespace xxx offline，之後執行alter database create datafile ‘new/xxx.dbf’ as ‘old/xxx.dbf’，資料庫會根據儲存在控制檔案中的資訊重建一個空的資料檔案，之後再執行recover tablespace / datafile將所有重做記錄運用到資料檔案，使其完全恢復到當前狀態，之後便可再將其恢復聯機。

　　如果丟失的是最後一種檔案---歸檔檔案或歸檔檔案所處的物理位置不可用，首先shutdown資料庫，立即作一個冷備份。然後修改ini檔案中的歸檔日誌檔案目的路徑，重新啟動資料庫。以後再發生災難只需從最新的備份中將相關檔案恢復，資料庫作recover時就不需要備份之前丟失的歸檔檔案了。在Oracle 8之後的新版本中提供了log_archive_duplex_dest和log_archive_dest_1...5等引數允許保留多份歸檔檔案到不同位置，甚至到遠端伺服器從而保證歸檔檔案的可靠性。

　　最後再說幾點資料庫恢復時的注意事項：

　　1.本文討論所有情況的預設前提是資料庫執行在歸檔(ARCHIVELOG)方式下，並只涉及到一般常見的情況和最基本的恢復方法。使用Oracle提供的恢復管理器RMAN也能完成上述任務，如果執行環境比較複雜建議使用RMAN來做備份和恢復。

　　2.一旦資料庫發生災難，最好在進行恢復之前做一次完全的冷備份，以便在進行恢復時產生差錯還可以進行補救。很大一部分資料丟失是由於不正確的恢復操作所引起的。

　　3.當資料庫完成恢復之後，尤其是使用resetlogs選項開啟資料庫之後，要馬上關閉資料庫進行一次完全的冷備份。因為，為防止放棄的重做日誌被下次恢復時再次運用，resetlogs選項會重新建立redo log檔案並將其的計數清零，這將使之前做的所有備份將變為不可用（一般情況下）。

　　4.要特別注意當進行資料庫完全恢復，從發生故障的時間點前的備份中恢復損壞檔案時，一定不要使備份中的redo log檔案覆蓋了當前的redo log檔案，否則就只能進行不完全恢復並且要丟失一部分資料了。