Backup and Recovery Strategies1

故障发生在用户错误，数据文件块损坏，媒体故障。次開始数据库的正常操作的速度是哪种还原、恢复技术类型的执行过程。每种还原和恢复技术强加须要在备份策略上。包含数据库要使用的特性，存储和管理你的备份。
当考虑恢复策略时。要问自己的问题有：
（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为备份提供哪些工具，怎么配置数据库来提高健壮性和怎么使备份和恢复更easy。当然，你的策略必须平衡恢复策略的需求和花费的问题、资源、人力和其它因素。

2.3.1、Protecting Your Redundancy Set--数据库的备份放在单独的一个磁盘；控制文件，数据文件使用raid等技术实现冗余；重做日志进行归档并使用多路复制
一个数据文件、控制文件或重做日志中不论什么一个失败时。恢复数据库的文件集被称作冗余集。冗余集（备份集）应该包括：
（1）控制文件和全部数据文件的近期备份
（2）在近期备份后，产生的全部归档日志
（3）oracle多路复制产生的当前控制文件和重做日志的拷贝
（4）配置文件的拷贝，比方server參数文件。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能够自己主动管理归档日志，它记录了全部归档日志的内容，把归档日志复制到磁带更加easy。同一时候识别和删除不再匹配恢复目标旧的日志）
（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
通过在不同硬件上完毕还原和恢复策略的一个一致性測试来測试你的备份。

理想地面，使用一种作为硬件和软件配置和生产环境的考验尽可能接近地。