Oralce 資料庫的災難恢複

來源:互聯網
上載者:User

隨著辦公自動化和電子商務的飛速發展,企業對資訊系統的依賴性越來越高,資料庫作為資訊系統的核心擔當著重要的角色。尤其在一些對資料可靠性要求很高的行業如銀行、證券、電信等,如果發生意外停機或資料丟失其損失會十分慘重。為此資料庫管理員應針對具體的業務要求制定詳細的Database Backup與災難恢複策略,並通過類比故障對每種可能的情況進行嚴格測試,只有這樣才能保證資料的高可用性。資料庫的備份是一個長期的過程,而恢複只在發生事故後進行,恢複可以看作是備份的逆過程,恢複的程度的好壞很大程度上依賴於備份的情況。此外,資料庫管理員在恢複時採取的步驟正確與否也直接影響最終的恢複結果,本文主要針對Oracle資料庫可能遇到的各種故障提供了相應的恢複的方法,僅供大家參考。
要對OracleDatabase Backup與恢複有清晰的認識,首先有必要對資料庫的幾種運行狀態有充分的瞭解。Oracle資料庫的運行狀態主要分為3種,他們依次為:
l Nomount(非安裝)Oracle只是讀取ini檔案中的配置資訊,並初始化SGA區。
l Mount(安裝)Oracle除了需要讀取ini檔案還要讀取控制檔案,並從中擷取有關資料庫的物理結構等資訊。
l Open(開啟)資料庫要檢查所有檔案處於同一時間點,對錯誤進行恢複對未完成交易回復,並最終可以允許使用者訪問。

資料庫的備份主要分為三種類型:冷備份;熱備份;邏輯備份;
資料庫的備份不是本文討論的重點,在這裡只作一個概要的介紹,OracleDatabase Backup主要有:
l Cold Backup(冷備份) 主要指在關閉資料庫的狀態下進行的資料庫完全備份,備份內容包括所有資料檔案、控制檔案、聯機記錄檔、ini檔案。
l Hot Backup(熱備份) 指在資料庫處於運行狀態下,對資料檔案和控制檔案進行備份,要使用熱備份必須將資料庫運行在(Archive Log)歸檔方式下。
l Export(邏輯備份)這是最簡單的備份方法,可按資料庫中某個表、某個使用者或整個資料庫來匯出,並且支援全部、累計、增量三種方式。使用這種方法,資料庫必須處於開啟狀態,而且如果資料庫不是在restrict狀態將不能保證匯出資料的一致性。

資料庫的恢複可分為兩大類:完全恢複;不完全恢複;
完全恢複指將資料庫恢複到發生故障的時間點,不丟失任何資料。不完全恢複指將資料庫恢複到發生故障前的某一個時間點,此時間點以後的所有改動將會丟失。如果沒有特殊需求,我們建議應盡量使用完全恢複。
Oracle資料庫的恢複過程分兩步進行,首先將把存放在重做記錄檔中的所有重做運用到資料檔案,之後對重做中所有未提交的事務進行復原,這樣所有資料就恢複到發生災難那一時刻了。資料庫的恢複只能在發生故障之前的資料檔案上運用重做,將其恢複到故障時刻,而不能將資料檔案反向復原到之前的某一個時刻。舉個例子,我們有一個2001/1/1的Database Backup,當2001/5/1使我們探索資料庫中資料發生混亂,希望將資料庫恢複到2001/4/30時的狀態,我們只能先恢複2001/1/1的Database Backup然後在其上運用重做記錄使其前滾到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檔案,否則就只能進行不完全恢複並且要丟失一部分資料了。



相關文章

Beyond APAC's No.1 Cloud

19.6% IaaS Market Share in Asia Pacific - Gartner IT Service report, 2018

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。