2.1、Data Recovery Strategy Determines Backup Strategy
当设计备份策略时，应该以数据恢复需求和数据恢复策略开始。每一种类型的数据恢复需要你采取适当的备份类型。失败会发生在用户错误，数据文件块损坏，介质失败。你可以重新开始数据库的正常操作的速度是哪种还原、恢复技术类型的运行过程。每种还原和恢复技术强加需要在备份策略上，包括数据库要使用的特性，存储和管理你的备份。
当考虑恢复策略时，要问自己的问题有：
（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
通过在不同硬件上完成还原和恢复策略的一个一致性测试来测试你的备份。理想地，使用一个作为测试的硬件和软件配置和生产环境尽量接近。
Backup and Recovery Strategies1