備份的概念

所謂備份，就是把數據庫復制到轉儲設備的過程。其中，轉儲設備是指用于放置數據庫拷貝的磁帶或磁盤。通常也將存放于轉儲設備中的數據庫的拷貝稱為原數據庫的備份或轉儲。如下圖所示：

ORACLE數據庫的備份分為物理備份和邏輯備份兩種。物理備份是將實際組成數據庫的操作系統文件從一處拷貝到另一處的備份過程，通常是從磁盤到磁帶。可以使用 Oracle 的恢復管理器（Recovery Manager，RMAN）或操作系統命令進行數據庫的物理備份。邏輯備份是利用SQL語言從數據庫中抽取數據并存于二進制文件的過程。Oracle提供的邏輯備份工具是 EXP。數據庫邏輯備份是物理備份的補充。

根據在物理備份時數據庫的狀態，可以將備份分為一致性備份（consistent backup）和不一致性備份（inconsistent backup）兩種：

一致性備份：一致性備份是當數據庫的所有可讀寫的數據庫文件和控制文件具有相同的系統改變號（SCN），并且數據文件不包含當前 SCN 之外的任何改變。在做數據庫檢查點時，Oracle 使所有的控制文件和數據文件一致。對于只讀表空間和脫機的表空間，Oracle 也認為它們是一致的。使數據庫處于一致狀態的唯一方法是數據庫正常關閉（用shutdown normal 或 shutdown immediate 命令關閉）。因此，只有在以下條件下的備份是一致性備份：

數據庫正常關閉（用shutdown normal 或 shutdown immediate 命令關閉）。

不一致性備份：不一致備份是當數據庫的可讀寫的數據庫文件和控制文件的系統改變號（SCN）在不一致條件下的備份。對于一個 7*24 工作的數據庫來說，由于不可能關機，而數據庫數據是不斷改變的，因此只能進行不一致備份。在 SCN 號不一致的條件下，數據庫必須通過應用重做日志使 SCN 一致的情況下才能啟動。因此，如果進行不一致備份，數據庫必須設為歸檔狀態，并對重做日志歸檔才有意義。在以下條件下的備份是不一致性備份：

數據庫處于打開狀態。

數據庫處于關閉狀態，但是用非正常手段關閉的。例如，數據庫是通過 shutdown abort 或機器掉電等等方法關閉的。

恢復的概念

所謂恢復，就是把數據庫由存在故障的狀態轉變為無故障狀態的過程。根據出現故障的原因，恢復分為兩種類型：

實例恢復。這種恢復是Oracle實例出現失敗后，Oracle自動進行的恢復。

介質恢復。這種恢復是當存放數據庫的介質出現故障時所做的恢復。本書后面提到的恢復都是指介質恢復。

裝載（restore）物理備份與恢復（Recover）物理備份是介質恢復的手段。裝載是將備份考回到磁盤，恢復是利用重做日志（物理備份的一部分）修改考回到磁盤的數據文件（物理備份的另一部分），從而恢復數據庫的過程。如下圖所示：

根據數據庫的恢復程度，將恢復方法分為兩種類型：

完全恢復：將數據庫恢復到數據庫失敗時數據庫的狀態。這種恢復是通過裝載數據庫備份和并應用全部的重做日志做到的。

不完全恢復：將數據庫恢復到數據庫失敗前的某一時刻數據庫的狀態。這種恢復是通過裝載數據庫備份和并應用部分的重做日志做到的。進行不完全恢復后必須在啟動數據庫時用 resetlogs 選項重設聯機重做日志。

例如，在上午10：00，由于磁盤損壞導致數據庫中止使用。現在使用兩種方法進行數據庫的恢復，第一種方法使數據庫可以正常使用，且使恢復后與損壞時（10：00）數據庫中的數據相同，那么第一種恢復方法就屬于完全恢復類型；第二種方法能使數據庫正常使用，但只能使恢復后與損壞前（例如9：00）數據庫中的數據相同，沒能恢復數據庫到失敗時（10:00）數據庫的狀態，那么第二種恢復方法就屬于不完全恢復類型。

事實上，如果數據庫備份是一致性的備份，則裝載后的數據庫即可使用，從而也可以不用重做日志恢復到數據庫備份時的點。這也是一種不完全恢復。

備份與恢復的關系

備份一個Oracle數據庫，類似于買醫療保險——在遇到疾病之前不會意識到它的重要性，獲得保險金的數量取決于保險單的種類。同理，隨著制作備份的種類和頻繁程度的不同，數據庫發生故障后其恢復的可行性、難度與所花費的時間也不同。

數據庫故障是指數據庫運行過程中影響數據庫正常使用的特殊事件。數據庫故障有許多類型，最嚴重的是介質失敗（如磁盤損壞），這種故障如不能恢復將導致數據庫中數據的丟失。數據庫故障類型有：

語句失敗。

用戶進程失敗。

實例失敗。

用戶或應用錯誤操作。這類錯誤可能是意外地刪除了表中的數據等錯誤操作。

介質失敗。如硬盤失敗，硬盤中的數據丟失。

自然災害。如地震、洪水等。

由于故障類型的不同，恢復數據庫的方法也不同。通過裝載備份來恢復數據庫既是常用的恢復手段，也是恢復介質失敗故障的主要方法。

備份與恢復要考慮的問題

備份與恢復要考慮以下的三個問題：

備份與恢復策略要考慮的商業、操作、及技術問題；

災難恢復計劃的組成；

測試備份與恢復策略的重要性。

能夠進行什么樣的恢復依賴于有什么樣的備份。作為 DBA，有責任從以下三個方面維護數據庫的可恢復性：

使數據庫的失效次數減到最少，從而使數據庫保持最大的可用性；

當數據庫不可避免地失效后，要使恢復時間減到最少，從而使恢復的效率達到最高；

當數據庫失效后，要確保盡量少的數據丟失或根本不丟失，從而使數據具有最大的可恢復性。

備份與恢復策略要考慮的商業、操作、及技術問題

作為 DBA，首先需要了解企業是如何使用數據庫系統的，以及企業對數據庫的可用性，恢復性能，和數據的可恢復性以及恢復時間的要求。然后，DBA 需要使企業的管理人員了解維護這樣的數據庫的可用性的代價有多大。做到這點的最好方法是評估恢復需要的花費，以及丟失數據給企業帶來的損失。

在代價被評估后，就可以進行備份與恢復的討論了。此時，要定義數據庫總體的可用性需求，并根據各項工作對數據庫可用性的影響程度來定義工作重點的次序。例如，如果數據庫需要 7*24 的可用性，那么其重要性就高于其它任何工作，其它任何需要關機才能做的工作就不能做。

另外，數據庫變化的情況也是備份與恢復策略需要考慮的一個因素。例如，如果數據不斷改變，有新數據或數據文件加入，或表結構有大的變化，則應該經常備份；反之，如果數據是靜態的或只讀的，則備份一次即可。無論如何，應遵從這樣一個原則，如果懷疑數據庫的可恢復性，就應該備份。

災難恢復計劃的組成

針對災難恢復，必須回答下述問題：

系統可能出現什么樣的災難恢復情況？

如果出現數據丟失，災難恢復情況是怎樣的？

系統中數據的易變程度如何？

如果出現問題，系統需要多快的速度恢復？

在各種情況下恢復策略的代價，以及相應的花時間重新錄入數據的代價?

對這些問題的回答組成了災難恢復計劃。

計算機是易壞的。主板上的芯片、主板電路、內存、電源等任何一項不能正常工作，都會導致計算機系統不能正常工作。當然，這些損壞可以修復，不會導致應用和數據的損壞。但是，如果計算機的硬盤損壞，將會導致數據丟失，此時必須用備份恢復數據。

災難恢復的最重要步驟是設計充足頻率的硬盤備份過程。備份過程應該滿足系統要求的可恢復性。例如，如果數據庫可有較長的關機時間，則可以每周進行一次冷備份，并歸檔重做日志；但是，如果數據庫只有極少的關機時間，則只能從硬件的角度來考慮備份與恢復的問題，例如使用硬盤鏡像或雙機系統。選擇備份策略的依據是：丟是數據的代價與確保數據不丟失的代價之比。

果每天都能備份當然會很理想，但要考慮其現實性。企業都在想辦法降低維護成本，現實的方案才可能被采用。只要仔細計劃，并想辦法達到數據庫可用性的底線，花少量的錢進行成功的備份與恢復也是可能的。

DBA 還應以服務協議的形式制訂一個可恢復性與可用性的標準文件。該文件應成為討論DBA 服務，以及服務是否能達到預期標準的依據。這樣做可使所有相關人員對同樣的預期有潛在的危機感。

測試備份與恢復策略的重要性

備份與恢復策略必須經測試無誤后才可使用。如果進行了備份，但不知道該備份是否支持希望的恢復目標則與根本沒有備份沒有兩樣。

恢復策略也要考慮慮對環境的依賴性。例如，假如機器的硬盤失效了，供貨商能在多長時間內提供一個新的硬盤；在機器需要重新啟動時，能找到操作系統管理員嗎？

另外一個需要考慮的問題是數據庫是否能經受自然的破壞。應在與計算機不同的地方再存儲一份備份介質，以免出現自然災害時主機與備份一起遭到破壞。

最后需要考慮的問題是萬一DBA 出現了問題怎么辦？后備的DBA能否執行備份策略？他或她能找到支持用的文檔嗎？這些文檔存在嗎？

沒有比花了大精力指定了好的計劃，但沒有測試其有效性而使其付諸東流的了。一個好的計劃還應容納人為錯誤，特別是用于開發的系統。理想的測試計劃應包括以下內容：

一系列的測試例子及其狀態描述；

測試結果是否成功的標準；

解決這些狀態的步驟。

只有在上述情況測試成功的前提下，DBA 才應該考慮把備份計劃付諸實施，用于實際使用的生產系統。

在數據庫實際使用時，備份策略的測試也不能終止。小范圍的測試可以確保備份策略可以滿足未來的需求。隨著應用系統的成熟，備份策略也應相應地成熟。如果備份策略不能滿足新的需求，就應該重新設計。

測試備份策略的益處：

測試人工的備份過程可能會發現人工的疏漏，促使DBA考慮自動的備份方法。只要自動的備份過程經過了測試，并能解決數據庫改變后的（例如增加了表空間）的備份問題，自動備份是有益無害的。

測試的另外一個好處是可以發現數據塊的問題。如果數據文件的一個或多個數據塊損壞了，而又使用了數據庫的物理備份方法，則損壞了的數據塊會被拷貝到備份文件中，這會導致備份的損壞和數據庫的損壞。如果不做測試，該問題是不會被發現的。當然，也可以通過設置INIT.ORA 文件中的參數DB_BLOCK_CHECKSUM 或用DBVERIFY 實用工具進行數據的完整性檢查。