當設計備份策略時，應該以數據恢復需求和數據恢復策略開始。每一種類型的數據恢復需要你採取適當的備份類型。失敗會發生在用戶錯誤，數據文件塊損壞，介質失敗。你可以重新開始數據庫的正常操作的速度是哪種還原、恢復技術類型的運行過程。每種還原和恢復技術強加需要在備份策略上，包括數據庫要使用的特性，存儲和管理你的備份。
當考慮恢復策略時，要問自己的問題有：
（1）如果磁盤失敗和損壞一些數據庫文件，比如數據文件和重做日誌，你想怎樣恢復丟失的文件。
Planning a Response to Media Failure: Restore and Media Recovery
（2）如果應用程序的邏輯錯誤或一個用戶錯誤引起多個表或表空間重要數據的丟失，你可以怎麼恢復那些數據，從錯誤開始數據庫更新會發生什麼？你能解決錯誤的原因從而阻止再次發生？
Planning Responses to User Error: Point-in-Time Recovery and Flashback
（3）如果實例的alert log顯示一個或多個表包含損壞塊，你怎麼修復損壞？在修復期間表空間必須保持可用的？
Planning a Response to Datafile Block Corruption: Block Media Recovery
（4）如果整個數據中心被損壞，你能完成災難恢復嗎？假設你只有包含備份的歸檔磁帶。你怎麼恢復數據庫？恢復需要多長時間？
（5）如果你離職，其他人能恢復數據庫嗎？你的恢復過程充分自動和文檔化了嗎？
思考上述問題，決定了你怎麼充分利用備份和恢復有關的特性，關注每種特性怎麼滿足備份策略的需要。比如：
（1）使用rman比user-managed backup and recovery更多簡化備份和還原的操作。它自動管理很多備份文件，比如磁盤或者磁帶上不再需要恢復的備份和歸檔日誌的刪除。它提供了備份活動詳細的報告，可以識別被用作恢復數據庫可用的備份。rman支持incremental backups，但是user-managed backup and recovery不支持incremental backups
（2）閃回數據庫幫助你還原數據庫到一個之前的時間點，它的速度比介質恢復更快。然而你必須配置一個快速閃回區和保存flash logs
（3）如果可用性是嚴格的，塊介質恢復比數據文件介質恢復更好。即使備份策略不依賴於rman，塊介質恢復也是可能的，基於rman塊介質恢復可以更快和更少困難。
一旦你決定了在恢復策略中使用哪種特性，你就可以設計備份策略，問自己如下問題：
（1）你怎麼和在哪裏保存你的備份？你會使用一個快速閃回區嗎？你會使用一個asm磁盤組支持冗餘嗎？你會把備份保存在磁盤或其他離線存儲，或僅僅磁盤嗎？
（2）你隔多長時間做日程備份？在每種情況下你採取什麼樣的物理備份的組成？
（3）哪種情況需要在規定日程外需要你採取數據庫備份？有時你必須採取一個非日程化的備份確保你可以恢復數據，比如open resetlogs後，把你的數據庫改變爲nologging（操作不會出現在重做日誌中）後。你也可能有商業需求需要審計目標的備份。
（4）你怎麼驗證你的備份，從而確保需要時你可以恢復你的數據庫？
（5）你有每種類型失敗的詳細恢復設計嗎？在危機時刻你怎麼執行這些計劃？在危機時刻腳本可以被寫入和自動執行這些設計嗎？
（6）在數據庫失敗期間，你可以應用oracle數據庫高可用性技術，比如dg或rac來提高可用性？使用這些高可用性技術怎麼影響到你的備份和恢復策略？
2.2、Planning Data Recovery Strategy
數據恢復策略應該包括任何一種數據庫失敗方案。一個有效、高效的策略的關鍵是預見失敗狀況，在失敗狀況中匹配適合的數據庫恢復技術和工具，接着確認你混合備份類型支持這些恢復技術。
2.2.1、Planning Responses to User Error: Point-in-Time Recovery and Flashback Features
一個用戶和應用程序可能產生不希望的改變，比如錯誤的更新，delete行，或drop表。一個適合的備份和恢復策略使用多種數據庫特性讓你把數據庫返回到期望的狀態，同時對數據庫可用性有最小影響，dba有最小的困難。依賴於你處於的情況，思考組成備份策略每一個選項，接着建立數據庫使這些選項可用。
2.2.1、Planning Responses to User Error: Point-in-Time Recovery and Flashback Features
一個用戶和應用程序可能產生不希望的改變，比如錯誤的更新，delete行，或drop表。一個適合的備份和恢復策略使用多種數據庫特性讓你把數據庫返回到期望的狀態，同時對數據庫可用性有最小
影響，dba有最小的困難。依賴於你處於的情況，思考組成備份策略每一個選項，接着建立數據庫使這些選項可用。
2.2.1.1、Flashback Database
只要你有閃回數據庫的日誌，不需要還原備份使用閃回數據庫把整個數據庫返回到之前的狀態。你可以打開flashback logging允許返回到隨意的scn，或者你可以創建guaranteed restore points
比如主數據庫更新之前，它保證閃回數據庫可以被使用。你必須爲閃回數據庫和安全的還原點配置一個快速閃回區。
2.2.1.2、Creating Normal and Guaranteed Restore Points
安全還原點保證你可以使用閃回數據庫把數據庫返回到之前的時間點。normal restore points不提供數據保護，但是它們是一個方便，因爲創建一個，在你使用基於時間點的恢復或閃回表之前你可以避免記錄數據庫的scn，或者你在決定了正確的scn後必須研究。雖然在還原點需要之前你必須設計創建還原點，但是使用normal restore points不需要特殊的設計。
2.2.1.3、Database Point-in-Time Recovery
你可以完成基於時間點的恢復，把一個表空間或整個數據庫帶回到錯誤的時刻之前。不管哪種情況，在錯誤的時刻之前你需要備份。
2.2.1.4、Importing Lost Objects from Logical Backup
如果你通過export導出被影響的表完成一個邏輯備份，你可以把數據導入到表。
注意：在很多場景中，oracle的閃回技術比介質恢復提供更快和更少破壞
（1）閃回數據庫是一個物理級別的恢復機制，它和介質恢復很相似，但是一般更快和不需要從備份還原
（2）閃回表和閃回drop是邏輯級別的恢復機制，回滾表不希望的改變，包括反轉drop table語句的影響
（3）閃回查詢和閃回版本查詢在查看錶的過去內容和研究邏輯損壞怎麼和何時影響數據庫是有用的。
關於閃回的特性被收集在chapter 7，"Performing Flashback and Database Point-in-Time Recovery"。
2.2.2、Planning a Response to Media Failure: Restore and Media Recovery
當一個問題阻止數據庫讀或寫時，一個介質失敗出現。典型的介質失敗包括物理失敗，比如文件頭崩潰，重寫，數據文件的刪除或損壞。介質失敗比用戶和應用錯誤少見，但是備份和恢復策略必須準備好。介質失敗的類型決定了使用恢復的技術。比如，損壞數據文件的恢復策略與控制文件丟失的恢復策略是不同的。
例子：重做日誌恢復
一個日誌組的所有成員丟失的恢復策略依賴很多因素，比如：
（1）數據庫的狀態（打開，崩潰，一致性關閉）
（2）丟失的重做日誌組是否是當前的
（3）丟失的重做日誌住是否是歸檔的
如果丟失了當前日誌組，同時數據庫沒有一致性關閉（既可以是打開，也可以是崩潰），那麼你不得不還原一箇舊的備份和完成基於時間點的恢復，要執行open resetlogs。你丟失了在
丟失日誌中的所有事務。隨後，在open resetlogs後，你應該立刻採取一個數據庫的全備；
如果丟失了當前日誌組，同時數據庫一致性關閉了，那麼你執行open resetlogs並沒有事務的丟失。但是，你應該立刻採取一個數據庫的全備；
如果丟失了非當前日誌組，那麼你可以使用alter database clear logfile語句來重建在日誌組的所有成員。沒有事務的丟失，立刻採取一個數據庫的全備。如果丟失的日誌組已經被歸檔，那麼你不需要任何的操作。
2.2.3、Planning a Response to Datafile Block Corruption: Block Media Recovery
如果一個或多個數據文件的很少一部分塊損壞，你可以完成塊介質恢復替代數據文件的完全介質恢復。rman的blockrecover命令可以用來還原和恢復指定的數據塊，但是數據庫需要打開同時損壞的數據文件需要在線。
Oracle Database Backup and Recovery Advanced User's Guide講述了怎麼使用rman完成塊介質恢復。
2.3、Planning Backup Strategy
數據恢復策略是數據備份策略的基礎。這個討論描述普遍的指導原則，它可以幫助你決定何時進行數據庫備份，你應該備份數據庫的哪些部分，oracle爲備份提供哪些工具，怎麼配置數據庫來提高健壯性和怎麼使備份和恢復更容易。當然，你的策略必須平衡恢復策略的需求和花費的問題、資源、人力和其他因素。
2.3.1、Protecting Your Redundancy Set--數據庫的備份放在單獨的一個磁盤；控制文件，數據文件使用raid等技術實現冗餘；重做日誌進行歸檔並使用多路複製
一個數據文件、控制文件或重做日誌中任何一個失敗時，恢復數據庫的文件集被稱作冗餘集。冗餘集（備份集）應該包含：
（1）控制文件和所有數據文件的最近備份
（2）在最近備份後，產生的所有歸檔日誌
（3）oracle多路複製產生的當前控制文件和重做日誌的拷貝
（4）配置文件的拷貝，比如服務器參數文件，tnsnames.ora，listener.ora
注意：不要把冗餘集保存數據文件，重做日誌和控制文件的磁盤上。否則磁盤就成爲一個單點故障。如果這個磁盤失敗，你就丟失了已提交的事務。
一個最小生產級別的數據庫需要至少兩個磁盤：一個保存冗餘集，一個保存數據庫文件。理想的，用每個可能的方法：分割的卷，分割的文件系統，分割的raid設備來保存冗餘集。管理冗餘集最簡單的方法就是使用快速閃回區，它放在和數據庫文件分開的設備上。然而，無論是否你是否使用一個快速閃回區，oracle建議如下的慣例：
（1）在數據庫級別多路複製在線重做日誌文件和控制文件（配置數據庫把重做日誌寫入到兩個或多個位置，那麼每個寫入是分開的操作）。如果在數據庫級別多路複製，一個i/o失敗或丟失寫只會損壞一份。理想地，多路複製文件應該放在不同磁盤控制器的不同的磁盤上。快速恢復區是存放一份拷貝好的位置。你也可以在操作系統級別或硬件級別拷貝重做日誌和控制文件，但是它不是多路複製的一個替代。
（2）如果數據庫運行在歸檔模式，把重做日誌歸檔到不同磁盤。如果你使用快速恢復區，把它作爲歸檔位置的一個。
（3）數據庫級別的多路複製，控制文件的所有拷貝必須始終都是可用的，否則實例會崩潰。操作系統或硬件級別的鏡像，即使因爲磁盤失敗控制文件的一個拷貝不可用，數據庫可以繼續運行。
（4）如果可能儘量使用操作系統或硬件級別的鏡像，避免爲簡單的磁盤故障完成介質恢復
（5）如果目標數據庫保存在raid設備上，那麼冗餘集應該放在不同於raid設備的磁盤上
2.3.2、Deciding Whether to Use a Flash Recovery Area
強烈建議：充分利用快速閃回區保存儘量多的備份和恢復文件。
一些oracle數據庫的備份和恢復特性，比如oracle閃回數據庫和安全還原點需要使用快速閃回區。然而，快速閃回區並不強迫你保存所有與恢複相關的文件。即使不是必須使用快速閃回區，但是，快速閃回區提供了很多優勢。已經從快速閃回區拷貝到磁帶的備份保留在磁盤直到其他文件需要空間，從而較少從磁帶還原備份的需要。同時，不再匹配備份目標過期的文件會被適當地刪除。dba不必手動刪除舊的備份。
在3-13頁：Setting Up a Flash Recovery Area for RMAN，提供了更多關於使用和收益於快速閃回區
2.3.3、Deciding Between ARCHIVELOG and NOARCHIVELOG Mode
重做日誌記錄了數據庫的數據文件的所有改變（有些異常的，比如direct path loads）。數據庫可以運行在兩個模式：archivelog模式和noarchivelog模式。在歸檔模式中，用過的重做日誌組再次
使用前必須被拷貝到一個或多個歸檔位置。非歸檔模式，日誌成員再次被使用時，重做日誌組會被重寫。
2.3.3.1、Implications of Running in NOARCHIVELOG Mode
數據庫運行在非歸檔模式，備份和恢復策略就會受限制：
（1）不能完成數據庫的在線備份。備份之前，必須一致性的關閉數據庫。
（2）不能使用需要歸檔日誌的任何數據恢復技術。這些技術包括完全和基於時間點的介質恢復，更加高級的恢復技術比如單個表空間的基於時間點恢復和閃回數據庫
運行在非歸檔模式，同時必須從磁盤失敗恢復，你有兩個重要的選擇：
（1）刪除受影響的數據文件中的所有對象，數據庫剩下的是完整的，但是受影響文件中所有數據丟失
（2）把整個數據庫還原最近的備份，丟失從備份開始的所有改變
2.3.3.2、Implications of Running in ARCHIVELOG Mode
對於很多應用，運行在非歸檔模式更好，因爲在數據丟失之後有更多靈活的恢復選項，比如數據庫和表空間的基於時間點的恢復。然而，運行在歸檔模式有相關的花費：
（1）爲歸檔位置設置空間。在數據庫中有大量的更新日誌
（2）必須要管理保存的歸檔日誌。爲了限制磁盤空間，歸檔日誌可以被拷貝到磁帶，不再匹配恢復目標舊的日誌應該被刪除。（rman可以自動管理歸檔日誌，它記錄了所有歸檔日誌的內容，把歸檔日誌拷貝到磁帶更加容易，同時識別和刪除不再匹配恢復目標舊的日誌）
（3）後臺進程arc0到arcn，拷貝重做日誌到歸檔位置
2.3.4、Deciding Whether to Use Oracle Flashback Features and Restore Points
當修復不希望的數據庫改變造成的影響時，使用閃回特性提高數據庫的可用性。邏輯級別的閃回特性允許沒有受影響的對象仍然可用，物理級別的閃回數據庫比基於時間點的恢復更快。如果你想要充分利用邏輯級別的閃回特性，你必須考慮數據庫如何管理回滾數據。Oracle Database Concepts and Oracle Database Administrator's Guide提供了更多關於回滾數據和自動回滾管理的信息。
2.3.5、Choosing a Backup Retention Policy
備份保留策略是你設置 關於保存的備份匹配恢復和其他需求的規則。備份保留策略基於冗餘或一個恢復窗口。在一個基於冗餘的保留策略，你指定一個數字n那麼你至少有每個文件的n個備份。在一個基於恢復窗口的保留策略，你指定過去的一個時間段，保存所有需要的備份，你可以完成在那個窗口之間任何一個基於時間點的恢復。
2.3.5.1、Implementing Backup Retention Policy with RMAN
rman使一個備份保留策略的實現自動化，可以使用如下命令：
（1）CONFIGURE RETENTION POLICY命令設置應用到所有數據文件的保留策略，它作爲默認設置
（2）REPORT OBSOLETE命令列出備份策略中過期的備份
（3）DELETE OBSOLETE命令刪除REPORT OBSOLETE列出的過期的文件
（4）CHANGE... KEEP爲指定的備份設置一個分別的保留策略，比如爲歸檔的目標保存long-term backups。可以指定一個備份必須被保存到一個未來的時間，甚至指定備份永久地被保存。CHANGE... NOKEEP使備份保留策略應用CHANGE... KEEP之前的操作。
如果使用快速恢復區保存備份，數據庫會隨着新備份需要空間自動地刪除過期的備份、歸檔日誌和其他文件。
2.3.6、Archiving Older Backups
保存舊的數據文件和歸檔日誌的備份，有以下原因：
（1）舊的備份爲完成最新備份之前的基於時間點的恢復是需要的
（2）如果最近的備份損壞，你可以使用舊的備份恢復數據庫
（3）爲了歸檔的目的，你可能想保存數據庫的拷貝
爲了完成基於時間點的恢復到一個目標時間，它稍早於最近備份的時間點，那麼需要舊的備份和舊的備份位於的時間點到目標時間點的所有歸檔日誌。
2.3.7、Determining Backup Frequency
對於任何恢復計劃頻繁的備份是最基本的。備份的頻繁度基於數據庫改變的頻繁度或速度，比如：
（1）表的增加和刪除
（2）行的添加和刪除
（3）更新數據
數據庫被更新的越頻繁，完成數據庫備份也要越頻繁。Backup Scripts When Blocks Change Frequently on page A-5中的場景每個星期備份數據庫全備。
如果數據庫被更新的相對不頻繁，那麼數據庫全備也要相對不頻繁，使用增量備份補充備份。Backup Scripts When Few Data Blocks Change" on page A-8中場景描述了怎麼基於全備設計一個開發策略。
2.3.8、Performing Backups Before and After You Make Structural Changes
有時，需要在規律備份日程外採取數據庫的備份。如果產生以下結構改變之前，完成數據庫適當部分的備份：
（1）創建或刪除一個表空間
（2）增加或重命名一個數據文件
（3）增加，重命名或刪除一個重做日誌組或成員
如果在非歸檔模式，必須關閉數據庫，完成一致性全備；如果是歸檔模式，你必須備份一個控制文件，使用rman的BACKUP CONTROLFILE命令或ALTER DATABASE BACKUP CONTROLFILE命令。
2.3.9、Scheduling Backups for Frequently-Updated Tablespaces
運行在歸檔模式，可以備份一個單一的表空間或一個單一的數據文件。數據庫很多更新被限制在表空間的一小部分。如果每個週日採取全備，那麼經常更新的表空間在週五出現介質失敗就需要應用大量的重做。經常更新的表空間的每天備份減少重做日誌的應用。
2.3.10、Backing Up after NOLOGGING Operations
當完成direct path load操作，沒有重做日誌記錄這些數據庫改變。使用介質恢復不能恢復這些改變。同樣地，以nologging創建的表和索引，數據庫不會記錄它們的改變。在執行沒有重做日誌記錄的操作後，你應該備份數據文件。既可以使用全備也可以使用增量備份。無論哪種都會捕捉所有變更的塊。
Oracle Database SQL提供了關於不可恢復的選項，比如CREATE TABLE ... AS SELECT語句
2.3.11、Exporting Data for Added Protection and Flexibility
oracl數據庫導入和導出工具可以用於導出數據庫對象（表、存儲過程），然後重新導入對象。一個導出提供導出對象邏輯級別的快照，它是一個二進制文件，之後可以被導入源數據庫或其他數據庫。導出不是全備的替代，但是非常有用。導出不能提供物理級別備份的一致性恢復優勢。比如，你不能給邏輯備份應用歸檔。Oracle Database Utilities提供了關於用於邏輯備份的導出和導入。
2.3.12、Preventing the Backup of Online Redo Logs
重做日誌，應該從不備份。和備份重做日誌關聯的最重要的危險是意外地還原沒有意義的備份，損壞數據庫。
重做日誌的備份不是特別有用，有以下的原因：
（1）數據庫運行在歸檔模式，歸檔進程已經自動歸檔所有重做日誌，不一定
（2）數據庫運行在非歸檔模式，唯一的物理備份類型是關閉的、一致的、全備的，重做日誌沒有起任何作用
保護重做日誌避免介質失敗最好的方法是多路複製，在不同磁盤控制器的不同磁盤上多路複製每個組的所有日誌成員
注意：rman不允許備份重做日誌，在做常規備份之前，你必須使用命令歸檔沒有歸檔的重做日誌
2.3.13、Keeping Records of the Hardware and Software Configuration of the Server
在恢復的場景中，在處置過程中你有所有的信息非常重要。你遇到你不瞭解的問題時，你需要聯繫Oracle Support。你需要有關於硬件配置的以下文檔：
（1）操作系統的版本和補丁
（2）磁盤和磁盤控制器的數量
（3）所有數據文件的名字
（4）介質管理軟件（如果使用第三方介質管理）的名字和版本
你需要有關於軟件配置的以下文檔：
（1）數據庫實例的名字
（2）數據庫識別符
（3）數據庫的版本和補丁
（4）網絡軟件的版本和補丁
（5）數據庫備份的策略（rman或user-managed）和頻繁度
（6）還原和恢復的策略
你也應該保存電子版和影印版的信息。比如你把上述信息保存到文本或一封email，當整個系統down機，你不可以訪問這些數據。保存DBID非常重要。如果你必須還原和恢復包含spfile和controlfile丟失的數據庫，在恢復過程中，你會需要DBID。Basic Database Restore and Recovery Scenarios on page 6-3提供了關於在恢復期間怎麼使用DBID。
2.4、Validating Your Data Recovery Strategy
在遷移到生產系統之前，在測試環境聯繫備份和恢復技術。通過以上方式，可以估測策略的完全性，最小化問題。規律地完成測試恢復保證歸檔，備份和恢復的過程有效。如果使用rman，運行DUPLICATE命令使用生產數據庫的備份創建一個測試數據庫。如果你完成user-managed備份和恢復，那麼你也可以創建一個新的數據庫，一個standby數據庫或一個存在的數據庫的拷貝來測試你的備份。
Oracle Database Backup and Recovery Advanced User's Guide提供了關於rman測試方法，troubleshooting sql*plus 恢復，塊介質恢復和rman災難恢復
2.4.1、Using BACKUP... VALIDATE
使用rman Using BACKUP... VALIDATE命令調用rman讀入 爲一個特定備份任務輸入的所有指定的數據庫文件，沒有實際產生任何備份作爲輸出。比如BACKUP DATABASE VALIDATE調用rman會讀入全備需要備份的所有文件，保證他們是完整和沒有損壞的。在輸入文件中的所有數據塊會被驗證，確切地就像一個實際備份發生時。該過程提供一個有用的、完整的檢查。
2.4.2、Validating RMAN Backups: VALIDATE and RESTORE VALIDATE
rman的VALIDATE and RESTORE VALIDATE命令應該是恢復設計測試的一部分。VALIDATE調用rman來讀入特定的備份，報告是否它們是正確和可用的。RESTORE... VALIDATE調用rman檢查可用的備份是否滿足還原特定的數據庫對象。比如RESTORE TABLESPACE TBS_1 VALIDATE
2.4.3、Testing Your Database Restore and Recovery Procedures
通過在不同硬件上完成還原和恢復策略的一個一致性測試來測試你的備份。理想地，使用一個作爲測試的硬件和軟件配置和生產環境儘量接近。
