执行用户管理（不依赖于RMAN）的备份和恢复_执行用户管理的数据库闪回和恢复

本章描述在用户管理的备份和恢复策略中如何还原和恢复数据库和使用Oracle数据库的闪回特性。用户管理的备份和还原策略意味着不依赖RMAN的方法。

1．使用SQL*Plus执行闪回数据库

可以在非CDB，CDB和PDB上使用SQL*Plus执行闪回数据库操作。Oracle闪回数据库返回整个数据库或整个PDB到先前的状态而不需要从备份还原文件。

闪回数据库要求你为数据库创建一个快速恢复区域和启用闪回日志收集。不管使用RMAN还是SQL*Plus，闪回数据库的要求和准备都是相同的。

使用SQL*Plus执行非CDB的闪回数据库
SQL*Plus的FLASHBACK DATABASE命令执行与RMAN的FLASHBACK DATABASE命令相同的功能：它返回数据库到先前的状态。

执行闪回数据库操作的前提条件在“闪回数据库和还原点的前提条件”中描述。

1）查询目标数据库确认可能的闪回SCN范围。以下SQL*Plus查询显示闪回窗口中最近的和最早的SCN：
SELECT CURRENT_SCN FROM V$DATABASE;

SELECT OLDEST_FLASHBACK_SCN, OLDEST_FLASHBACK_TIME
FROM V$FLASHBACK_DATABASE_LOG;

2）如果必要使用其它闪回特性来识别对数据库不想要的更改的SCN或时间。

3）确保目标数据库是挂载的。
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

4）启动SQL*Plus，运行FLASHBACK DATABASE返回数据库到先前的TIMESTAMP或SCN。
FLASHBACK DATABASE TO SCN 46963;
FLASHBACK DATABASE TO TIMESTAMP ‘2013-11-05 14:00:00’;
FLASHBACK DATABASE TO TIMESTAMP to_timestamp(‘2013-11-11 16:00:00’, ‘YYYY-MM-DD HH24:MI:SS’);

5）当操作完成时，以只读模式打开数据库，执行查询确认已经恢复需要的数据。

如果选择在过去不够远的目标时间，那么使用另外一个FLASHBACK DATABASE语句。否则，你可以使用RECOVER DATABASE来返回数据库到当前的时间，然后尝试另外一个FLASHBACK DATABASE语句。

6）当对结果满意时，使用RESETLOGS选项打开数据库。

如果适合，也可以使用Data Pump Export来保存丢失的数据，使用RECOVER DATABASE返回数据库到现在，重新导入丢失的对象。

2．用户管理的介质恢复概述

本节提供使用SQL*Plus恢复的概述。

2.1．关于用户管理的还原和恢复

通常，当介质故障或用户错误损坏或删除一个或多个数据文件时还原文件。在用户管理的还原操作中，你使用操作系统工具还原文件的备份。

如果介质故障影响数据文件，那么恢复过程依赖于：
1） 数据库的归档模式：ARCHIVELOG或NOARCHIVELOG
2） 介质故障的类型
3）介质故障影响的文件（数据文件，控制文件，归档redo日志和spfile是还原操作的所有候选）

如果永久或临时介质故障影响在NOARCHIVELOG模式中运行的数据库的任何数据文件，那么数据库自动关闭。如果介质故障是临时的，那么纠正底层的问题和重启数据库。通常，崩溃恢复从在线redo日志恢复所有提交的事务。如果介质故障是永久的，那么如“在NOARCHIVELOG模式中恢复数据库”中描述的恢复数据库。

下表阐述了当运行在ARCHIVELOG模式中的数据库丢失文件时介质恢复的可能影响。

如果丢失…	那么…
在SYSTEM表空间中的数据文件或使用活动undo段的数据文件	数据库自动关闭。如果硬件问题是临时的，那么纠正它和重启数据库。通常，崩溃恢复会恢复丢失的事务。如果硬件问题是永久的，那么按“执行关闭的数据库的恢复”中描述的步骤从备份还原数据文件和恢复数据库。
不在SYSTEM表空间中的数据文件或不包含活动回滚或undo段的数据文件	影响的数据文件会被脱机，但数据库保持打开。如果没受影响的数据库部分必须保持可用的，那么不要关闭数据库。使用临时选项将包含问题数据文件的表空间脱机，然后按“执行打开的数据库恢复”中描述的恢复它们。
当前控制文件的所有副本	你必须还原备份的控制文件，然后使用RESETLOGS选项打开数据库。 如果你没有备份，那么你可以尝试重建控制文件。如果可能，使用包含在ALTER DATABASE BACKUP CONTROLFILE TO TRACE输出中的脚本。可能需要额外的工作来匹配控制文件结构和当前的数据库结构。
多路复用的控制文件的一个副本	拷贝完好的多路复用控制文件到损坏或缺失的控制文件位置和打开数据库。如果你不能拷贝控制文件到它的原始位置，那么编辑初始化参数文件来反映新的位置或移除损坏的控制文件。然后，打开数据库。
一个或多个介质恢复需要的归档日志	你必须还原这些归档日志的备份以便恢复继续。你可以还原到缺省或非缺省的位置。如果你没有备份，那么你必须执行不完整的恢复直到在第一个缺失的redo日志之前的SCN，然后使用RESETLOGS选项打开数据库。
spfile	如果你有spfile的备份，那么还原它。或者，如果你有客户端初始化参数文件的备份，那么你可以还原这个文件的备份，启动实例，然后重建spfile。

注意：还原和恢复Oracle管理的文件（OMF）与还原和恢复用户命名的文件没有不同。

为执行介质恢复，Oracle建议你在SQL*Plus中使用RECOVER语句。你也可以使用SQL语句ALTER DATABASE RECOVER，但RECOVER语句通常更简单。为了启动任何类型的介质恢复，你必须遵守以下限制条件：
1）你必须有管理员权限。
2）所有恢复会话必须是兼容的。
3）当另外一个在执行不完整的介质恢复时一个会话不能开始完整的介质恢复。
4）你不能开始介质恢复如果你通过共享的服务器进程连接到数据库。

2.2．使用RECOVER命令的自动恢复

当使用SQL*Plus来执行介质恢复时，最简单的策略是使用SQL*Plus的RECOVER命令执行自动恢复。自动恢复发起恢复而不手动提示SQL*Plus应用每个单独的的归档redo日志。

当使用SQL*Plus时，你有以下选项来自动应用恢复期间需要的归档redo日志的缺省的文件名称：
1）在执行RECOVER命令之前执行SET AUTORECOVERY ON。如果你使用缺省的SET AUTORECOVERY OFF执行恢复，那么你必须手动输入文件名称或按Enter接受建议的文件名称。
2）作为RECOVER命令的选项指定AUTOMATIC关键字。

在两种情况中，如果必要的文件在正确的位置有正确的名称，当执行RECOVER命令时不需要交互。当数据库成功应用redo日志文件时，会返回以下信息：
Log applied.

你然后被提示在序列中下一个redo日志。如果最近应用的日志是最后需要的日志，那么恢复终止。

自动恢复使用的文件名称是从LOG_ARCHIVE_FORMAT和LOG_ARCHIVE_DEST_n的连接值中衍生的，其中n是在所有启用的本地目的地当中最大的值。例如，假设以下初始化参数设置在数据库实例中生效：
LOG_ARCHIVE_DEST_1 = “LOCATION=/arc_dest/loc1/”
LOG_ARCHIVE_DEST_2 = “LOCATION=/arc_dest/loc2/”
LOG_ARCHIVE_DEST_STATE_1 = DEFER
LOG_ARCHIVE_DEST_STATE_2 = ENABLE
LOG_ARCHIVE_FORMAT = arch_%t_%s_%r.arc

在这个示例中，SQL*Plus自动提议文件名称/arc_dest/loc2/arch_%t_%s_%r.arc（其中%t是线程，%s是序列，%r是resetlogs ID）。

2.2.1．使用SET AUTORECOVERY命令的自动恢复

在还原数据文件备份之后，你可以运行SET AUTORECOVERY ON命令来启用自动恢复。例如，你可以输入以下命令在SQL*Plus中执行自动恢复和打开数据库：
STARTUP MOUNT
SET AUTORECOVERY ON
RECOVER DATABASE
ALTER DATABASE OPEN;

注：在发出SQL*Plus的RECOVER命令之后，你可以在V$RECOVERY_FILE_STATUS视图中查看所有已经被考虑恢复的文件。你可以在V$RECOVERY_STATUS视图中访问每个文件的状态信息。这些视图在终止恢复会话之后是不能访问的。

2.2.2．使用RECOVER命令的AUTOMATIC选项的自动恢复

除了使用SET AUTORECOVERY来打开自动恢复之外，也可以在RECOVER命令中只指定AUTOMATIC关键字。例如，你可以在SQL*Plus中输入以下命令执行自动恢复和打开数据库：
STARTUP MOUNT
RECOVER AUTOMATIC DATABASE
ALTER DATABASE OPEN;

如果你使用Oracle RAC配置，和如果你执行不完整的恢复或使用备份的控制文件，那么数据库只能从第一个redo线程中计算第一个归档redo日志文件的名称。你可能必须手动应用来自另一个redo线程中的第一个日志文件。在已经提供给定线程中第一个日志文件之后，数据库可以提议这个线程中接下来的日志的名称。

2.3．当归档日志在缺省位置时的恢复

当归档redo日志文件在缺省位置中存在时，不需要额外的步骤来执行恢复。

在恢复期间，当需要日志文件时，数据库提议文件名称。如果使用SQL*Plus运行非自动的介质恢复，那么输出会以这个示例中显示的格式展示：

ORA-00279: change 53577 generated at 11/26/02 19:20:58 needed for thread 1
ORA-00289: suggestion : /oracle/oradata/trgt/arch/arcr_1_802.arc
ORA-00280: change 53577 for thread 1 is in sequence #802
Specify log: [<RET> for suggested | AUTO | FROM logsource | CANCEL ]

当使用ALTER DATABASE … RECOVER语句时，会返回类似的信息。然而，没有提示会显示。

数据库通过连接初始化参数LOG_ARCHIVE_DEST_n（n是所有启用的本地目的地当中最大的值）和LOG_ARCHIVE_FORMAT的当前值构建提议的归档日志文件名称和使用来自控制文件的日志历史数据。以下是可能的设置：
LOG_ARCHIVE_DEST_1 = ‘LOCATION = /oracle/oradata/trgt/arch/’
LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc

SELECT NAME FROM V$ARCHIVED_LOG;

NAME
----------------------------------------
/oracle/oradata/trgt/arch/arcr_1_467.arc
/oracle/oradata/trgt/arch/arcr_1_468.arc
/oracle/oradata/trgt/arch/arcr_1_469.arc

因此，如果所有需要的归档日志文件在LOG_ARCHIVE_DEST_1目的地存在，和如果LOG_ARCHIVE_FORMAT的值从未更改，那么数据库可以提议和应用日志文件来自动完成介质恢复。

2.4．当归档日志在非缺省位置时的恢复

当归档redo日志文件存储在非缺省位置中时，为了执行介质恢复，你必须指定归档redo日志文件的位置。

当归档redo日志文件存储在非缺省位置中执行介质恢复时，你有以下互斥的选项：
1）编辑LOG_ARCHIVE_DEST_n参数来指定归档redo日志的位置，然后像往常一样恢复。
2）恢复前在SQL*Plus中使用SET语句指定非缺省位置，或在RECOVER命令中指定LOGFILE参数。

2.4.1．重置归档日志目的地

可以编辑初始化参数文件或发出ALTER SYSTEM语句来更改归档redo日志的缺省位置。

恢复前更改缺省归档日志位置：
1）使用操作系统工具还原归档日志到非缺省的位置。
% cp /backup/arch/* /tmp/

2）更改归档日志参数的值为非缺省位置。可以在实例启动后执行ALTER SYSTEM语句，或编辑初始化参数文件然后启动数据库实例。例如，当实例关闭时编辑参数文件如下：
LOG_ARCHIVE_DEST_1 = ‘LOCATION=/tmp/’
LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc

3）使用SQL*Plus，通过指定编辑的初始化参数文件启动新的实例，然后挂载数据库。
STARTUP MOUNT

4）像往常一样开始介质恢复。
RECOVER DATABASE

2.4.2．覆盖归档日志目的地

在某些情况中，你可能想覆盖归档目的地参数的当前设置为作为归档日志文件的源。

使用SET LOGSOURCE恢复在非缺省位置中的归档日志：
1）使用操作系统工具拷贝归档redo日志到备选的位置。
% cp $ORACLE_HOME/oradata/trgt/arch/* /tmp

2）在SQL*Plus中指定恢复操作的备选位置。
SET LOGSOURCE “/tmp”

3）恢复脱机的表空间。
RECOVER AUTOMATIC TABLESPACE users

或者，你可以避免运行SET LOGSOURCE而简单地运行：
RECOVER AUTOMATIC TABLESPACE users FROM “/tmp”

注：覆盖redo日志源不会影响正在被归档的在线redo日志组的归档redo日志目的地。

2.5．使用存储快照优化的恢复

存储快照优化让你在在数据库不在备份模式时对数据库做第三方快照，恢复数据库到当前时间或在快照创建之后指定的时间点。如果存储快照创建时数据库没有置于备份模式，如果快照遵守Oracle要求，那么你可以只使用快照执行恢复。如果这些条件都满足，那么你可以如其它备份方法一样使用RMAN或SQL*Plus采取某些基本的恢复步骤。

如果存储快照不遵从使用存储快照优化的要求，那么你通过将数据文件置于备份模式来创建快照。为了使用这些快照执行恢复，使用后面章节中的“使用SQL*Plus执行完整的数据库恢复”或“执行不完整的数据库恢复”中描述的过程。

指定快照恢复的时间
如果存储快照在数据库不在备份模式中创建的，当使用快照来恢复数据库时你必须指定SNAPSHOT TIME选项。SNAPSHOT TIME选项可以在RMAN或SQL*Plus的RECOVER命令中使用。使用SNAPSHOT TIME选项的时间必须是一个紧接在快照完成之后的时间。如果指定不正确的时间，那么数据库可能以不能修复的方式损坏。

因为时间在快照发生的存储阵列中向前走，而Oracle数据库的宿主机器可能没有完美同步，建议你增加几秒钟到SNAPSHOT TIME选项指定的时间。这帮助避免任何通过恢复到快照制作之前的点将文件遗留在不一致的状态的可能性。

所有在RECOVER命令中指定的时间，包含在SNAPSHOT TIME子语句中的，都被认为是在Oracle数据库主机的时区中。然而，存储阵列中的时钟可能与Oracle数据库主机不同的时区。如果存储阵列报告它的快照时间是在不同的时区，那么在SNAPSHOT TIME选项中指定时间时你必须将这个不同考虑在内。

注：通过UNTIL选项指定的恢复点，不能比指定的SNAPSHOT TIME更早。

使用存储快照恢复示例：
本章节中的示例使用RECOVER DATABASE命令来执行使用快照的恢复。你可以从RMAN或SQL*Plus中使用RECOVER DATABASE。然而，UNTIL CANCEL子语句只在SQL*Plus中有效。

完整恢复数据库：
RECOVER DATABASE;

使用特定的快照恢复数据库：
这个示例使用在10月15日2:00 P.M.做的快照恢复数据库。UNTIL TIME可以指定快照之后的任何时间。
RECOVER DATABASE UNTIL TIME ‘10/15/2012 15:00:00’ SNAPSHOT TIME ‘10/15/2012 14:00:00’;

使用归档redo日志文件执行部分恢复：
RECOVER DATABASE UNTIL CANCEL SNAPSHOT TIME ‘10/15/2012 14:00:00’;

2.6．在用户管理的恢复期间取消恢复

如果启动介质恢复之后必须中断它，那么当提示redo日志文件时输入CANCEL或使用操作系统中断信号如果正在恢复个别的数据文件或自动恢复正在进行时必须终止。在恢复被取消之后，可以在后来使用RECOVER命令重新开始。恢复从它被取消中断的地方继续。

2.7．并行介质恢复

缺省情况下，Oracle数据库使用并行介质恢复来改善介质恢复向前滚动阶段的性能。在介质的并行恢复中，数据库使用“劳动分工”的方法在向前滚动时分配不同的进程到不同的数据块，因此让过程更有效。使用的进程的数量衍生自CPU_COUNT初始化参数，缺省情况下等于系统上CPU的数量。例如，如果并行恢复是在一个CPU_COUNT是4的系统上执行，只有一个数据文件要恢复，那么4个孵出（spawned）的进程从归档日志读取块和应用redo。

通常，介质恢复受数据块读和写所限制。并行恢复尝试使用系统所有可用的I/O带宽来改善性能。除非存在系统I/O瓶颈或不理想的异步I/O支持，并行恢复很可能改善恢复性能。

为了覆盖执行并行恢复的缺省行为，使用SQL*Plus的RECOVER命令与NOPARALLEL选项，或RECOVER PARALLEL 0。初始化参数RECOVERY_PARALLELISM只控制实例或崩溃恢复。介质恢复不受RECOVERY_PARALLELISM的值影响。

3．使用SQL*Plus执行完整的数据库恢复

通常，当介质故障导致一个或多个数据文件不可访问时，你执行数据库的完整恢复。在完整数据库恢复期间，你使用所有可用的redo来恢复数据库到当前的SCN。

视图V$RECOVER_FILE指示哪些文件需要恢复。取决于环境，你可以恢复整个数据库或恢复个别的表空间或数据文件。因为你不需要在完整恢复之后使用RESETLOGS选项打开数据库，你可以选择一次恢复某些数据文件，后面再恢复剩余的数据文件。

3.1．执行关闭的数据库恢复

当数据库没有打开执行完整的恢复时，可以在一个操作中恢复所有损坏的数据文件或在不同的操作中执行每个损坏的数据文件的个别恢复。

本过程假设以下：
1）当前的控制文件是可用的。
2）你有所有需要的数据文件的备份。
3）所有必要的归档redo日志是可用的。

还原和恢复损坏或缺失的数据文件：
1）如果数据库是打开的，查询V$RECOVER_FILE来确认哪些数据文件必须恢复和为什么它们必须被恢复。

如果你计划执行完整恢复而不是时间点恢复，那么你只恢复那些需要恢复的数据文件，而不是整个数据库。对于时间点恢复，你必须还原和恢复所有的数据文件，除非你执行RMAN TSPITR。你也可以使用闪回数据库，但这个过程影响所有的数据文件和将整个数据库返回到过去的时间点。

你可以查询V$RECOVERY_FILE视图按数据文件序号列出要求恢复的数据文件和它们的状态与错误信息。
SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME
FROM V$RECOVER_FILE;

注：你不能与从备份中还原的控制文件或在影响数据文件的介质故障之后重建的控制文件一起使用V$RECOVER_FILE。还原或重建的控制文件不包含需要用来准确更新V$RECOVER_FILE的信息。

你也可以通过使用数据文件序号和V$DATAFILE与V$TABLESPACE视图执行有用的连接来获得数据文件与表空间的名称。

ERROR列鉴别了每个要求恢复的文件的问题。

2）查询V$ARCHIVED_LOG和V$RECOVERY_LOG视图确认需要哪些归档redo日志文件。

V$ARCHIVED_LOG列出所有归档redo日志的文件名称，而V$RECOVERY_LOG只列出数据库需要执行介质恢复的归档redo日志。后者也包括了文件基于使用LOG_ARCHIVE_FORMAT参数指定的命名惯例的可能名称。

注：V$RECOVERY_LOG只有在数据文件需要介质恢复时才填充。因此，这个视图对于计划中的恢复比如从用户错误中恢复是没用的。
如果数据文件需要恢复，但数据文件的备份不存在，那么你需要从数据文件增加到数据库开始后生成的所有redo。

3）如果所有的归档日志在缺省的位置中存在，那么跳到第四步。

如果某些归档日志必须被还原和有足够的可用空间，那么还原需要的归档日志文件到LOG_ARCHIVE_DEST_1指定的位置。在介质恢复期间需要的时候，数据库自动定位正确的日志。
% cp /disk2/arch/* $ORACLE_HOME/oradata/trgt/arch

如果可用空间不够，那么还原某些或所有需要的归档redo日志文件到备选的位置。

4）如果数据库是打开的，那么关闭它。
SHUTDOWN IMMEDIATE

5）检查介质确认问题源。
如果导致介质故障的硬件问题是临时的和如果数据是未损坏的（例如，磁盘或控制器电源故障发生），那么介质恢复是不需要的：启动数据库和恢复正常的操作。

如果不能修复问题，那么继续步骤6。

6）如果文件是永久损坏的，那么鉴别损坏文件最近的备份。只还原介质故障损坏的数据文件：不要还原未损坏的数据文件或任何在线redo日志文件。

例如，如果只有ORACLE_HOME/oradata/trgt/users01.dbf时损坏的文件，那么你可能找到/backup/users01_10_24_02.dbf是最近的文件备份。如果你没有特定的数据文件的备份，那么你可以创建空的可以被恢复的替换文件。

7）使用操作系统工具还原数据文件到它们缺省的位置或一个新的位置。例如，Linux或UNIX用户还原users01.dbf到它的缺省位置：
% cp /backup/users01_10_24_06.dbf $ORACLE_HOME/oradata/trgt/users01.dbf

使用以下准则决定还原数据文件备份到哪里：
a．如果硬件问题被修复和你可以还原数据文件到它们缺省的位置，那么还原数据文件到它们缺省的位置和开始介质恢复。
b．如果硬件问题持续和你不能还原数据文件到它们的原始位置，那么还原数据文件到备选的存储设备。使用ALTER DATABASE RENAME FILE语句在控制文件中指示这些文件的新位置。
c．如果还原一个数据文件到裸磁盘或分区，那么这个技术基本与还原到文件系统上的文件时相同。当心在裸设备上的文件的命名惯例（跟操作系统相关），使用支持裸设备的操作系统工具。
8）使用管理员权限连接到数据库，然后启动新的实例和挂载，但不打开数据库。
STARTUP MOUNT

9）如果你还原一个或多个损坏的数据文件到备选的位置，那么更新数据库的控制文件来反映新的数据文件名称。例如，更改表空间users中的数据文件的文件名称：
ALTER DATABASE RENAME FILE ‘?/oradata/trgt/users01.dbf’ TO ‘/disk2/users01.dbf’;

10）通过检查通常伴随当前控制文件的数据文件列表或查询V$DATAFILE视图获取所有数据文件的文件名称和状态。
SELECT NAME,STATUS FROM V$DATAFILE;

11）确保所有需要恢复的数据文件是在线的。唯一的例外是正常脱机的脱机表空间中的数据文件或只读表空间中的数据文件。例如，为保证名称为oracle/dbs/tbs_10.f的数据文件是联机的，输入以下命令：
ALTER DATABASE DATAFILE ‘/oracle/dbs/tbs_10.f’ ONLINE;

如果指定的数据文件已经在线，那么数据库忽略这个语句。如果你更喜欢创建脚本来将所有数据文件同时联机，如下例所示：
SPOOL onlineall.sql
SELECT ‘ALTER DATABASE DATAFILE ‘’’||name||‘’’ ONLINE;’ FROM V$DATAFILE;
SPOOL OFF
SQL> @onlineall

12）如果还原归档redo日志到备选的位置，那么你可以在介质恢复之前使用SQL*Plus中的SET命令的LOGSOURCE参数指定位置。
SET LOGSOURCE /tmp

或者，可以使用RECOVER命令中的FROM参数。
RECOVER AUTOMATIC FROM ‘/tmp’ DATABASE

注：覆盖redo日志源不会影响正在被归档的在线redo日志组的归档redo日志目的地。

13）执行其中一个语句恢复数据库，表空间，或数据文件。
RECOVER AUTOMATIC DATABASE    # whole database
RECOVER AUTOMATIC TABLESPACE users   # specific tablespace
RECOVER AUTOMATIC DATAFILE ‘?/oradata/trgt/users01.dbf’;   # specific data file

如果你选择不自动应用归档redo日志，那么你必须接受或拒绝每个提示的日志。如果你自动恢复，那么数据库自动应用日志。恢复继续直到所有需要的归档和在线redo日志已经应用到还原的数据文件。当介质恢复完成时，数据库通知你：
Media recovery complete.

如果不需要归档redo日志用来完全介质恢复，那么数据库应用所有必要的在线redo日志文件和终止恢复。

14）在恢复终止之后，打开数据库来使用：
ALTER DATABASE OPEN;

15）在应用归档日志之后，确认每个归档日志组的每个副本仍然在离线存储上存在，然后删除归档redo日志文件的还原的副本来释放磁盘空间。
% rm /tmp/*.arc

3.2．执行打开的数据库恢复

当数据库打开时，可以执行数据库中非SYSTEM数据文件的完全恢复。

过程假设以下：
1）当前的控制文件是可用的。
2）你有所有需要的数据文件的备份。
3）所有必要的归档redo日志是可用的。

当数据库保持打开时，也可能发生介质故障，让未损坏的数据文件联机和可以使用。损坏的数据文件（但不是包含它们的表空间）会自动被脱机如果数据库写进程不能写它们。如果数据库写进程不能要开数据文件，仍然会返回一个错误。不能读取损坏文件的查询返回错误，但数据文件不会因为失败的查询自动被脱机。例如，你可能运行SQL查询和看到以下的查询：

ERROR at line 1: 
ORA-01116: error in opening database file 3 
ORA-01110: data file 11: '/oracle/oradata/trgt/cwmlite02.dbf' 
ORA-27041: unable to open file 
SVR4 Error: 2: No such file or directory 
Additional information: 3

注：你不能使用本章节中的这个过程在数据库打开时对SYSTEM表空间执行完全介质恢复。如果介质故障损坏SYSTEM表空间的数据文件，那么数据库自动关闭。

在打开的数据库中还原数据文件：
1）遵循“执行关闭的数据库恢复”的步骤1到3。
2）如果数据库是打开的，那么将包含损坏的数据文件的所有表空间脱机。例如，如果表空间USERS和TOOLS包含损坏的数据文件，那么执行以下SQL语句：
ALTER TABLESPACE users OFFLINE TEMPORARY;
ALTER TABLESPACE tools OFFLINE TEMPORARY;

如果指定TEMPORARY，那么Oracle数据库为表空间中所有联机的数据文件创建一个检查点。在你将表空间联机之前当执行这个语句时状态是脱机的文件可能需要介质恢复。如果你指定IMMEDIATE，那么你必须在将表空间联机之前在其上执行介质恢复。

3）检查介质确认问题源。
你可以使用DBERIFY工具对脱机的数据文件运行完整性检查。

如果导致介质故障的硬件问题是临时的和数据没有损坏，那么不需要介质恢复。你可以将脱机的表空间联机和恢复正常操作。如果你不能修复问题，或DBVERIFY报告损坏块，那么继续步骤4。

4）如果文件是永久性损坏的，那么使用操作系统命令只还原介质故障损坏的数据文件的最近的备份。例如，在Linux或UNIX上使用cp命令还原users01.dbf：
% cp /disk2/backup/users01.dbf $ORACLE_HOME/oradata/trgt/users01.dbf

如果硬件问题已纠正和数据文件可以还原到它们的原始位置，那么这样做。否则，还原数据文件到备选的存储设置。不要恢复未损坏的数据文件，在线redo日志或控制文件。

注：在某些环境中，如果你没有特定的数据文件的备份，你可以使用ALTER DATABASE CREATE DATAFILE语句来创建空的替代文件用于恢复。

5）如果你还原一个或多个损坏的数据文件到备选位置，那么更新数据库的控制文件来反映新的数据文件名称。例如，更改表空间users中的数据文件名称：
ALTER DATABASE RENAME FILE ‘?/oradata/trgt/users01.dbf’ TO ‘/disk2/users01.dbf’;

6）如果你还原归档redo日志到备选的位置，那么你可以在介质恢复之前在SQL*Plus中的SET命令中使用LOGSOURCE参数指定新的位置。例如，如果日志位于/tmp：
SET LOGSOURCE /tmp

或者可以在步骤7中使用RECOVER命令的FROM参数。
RECOVER AUTOMATIC FROM ‘/tmp’ TABLESPACE users, tools;

注：覆盖redo日志源不会影响正在被归档的在线redo日志组的归档redo日志目的地。

7）使用管理员权限连接到数据库，使用一个步骤启动脱机的表空间恢复，恢复一个或多个脱机表空间中的所有损坏的数据文件。例如，恢复users和tools：
RECOVER AUTOMATIC TABLESPACE users, tools;

数据库通过应用必要的归档和在线redo日志来重构还原的数据文件，开始介质恢复的向前滚动阶段。除非使用RECOVER AUTOMATIC或SET AUTORECOVERY ON命令自动应用redo，数据库提示每个要求的redo日志文件。

恢复继续直到所有需要的归档日志已经被应用到数据文件。然后应用在线redo日志到还原的数据文件来完成介质恢复。如果不需要归档redo日志来完成介质恢复，那么数据库不会提示任何日志。而是应用所有必要的在线redo日志，介质恢复就完成。

8）当损坏的表空间被恢复到介质故障发生的时刻，将脱机的表空间联机。
ALTER TABLESPACE users ONLINE;
ALTER TABLESPACE tools ONLINE;

4．执行不完整的数据库恢复

不完整的恢复也被称为数据库时间点恢复。

通常，在以下情形中执行数据库时间点恢复（DBPITR）：
1）你想恢复数据库到用户错误或管理错误之前的SCN。
2）数据库包含损坏的块。
3）因为所有必要的归档redo日志不可用，完全数据库恢复失败。
4）你正在从生产数据库备份创建测试数据库或报告数据库。

如果数据库运行在ARCHIVELOG模式和如果一个归档redo日志文件的唯一副本是损坏的，那么损坏的文件不影响数据库现在的操作。下表描述了取决于何时写了redo日志和何时备份了数据文件时可能会出现的情况。

丢失归档redo日志

如果备份了…	那么…
在填满了的在线redo日志组（正在被归档的）被写之后的所有数据文件	填满了的在线redo日志组的归档版本不需要用来做完全介质恢复。
在填满了的在线redo日志组被写之前的一个特定的数据文件	如果相应的数据文件被永久的介质故障损坏，那么使用损坏的数据文件最近的备份和执行损坏的数据文件的表空间时间点恢复，直到损坏的归档redo日志文件。

警告：如果你知道归档redo日志组已经被损坏，那么立即备份所有的数据文件从而具有不需要损坏的归档redo日志的整个数据库的备份。

DBPITR的技术与执行关闭的数据库恢复非常类似，除了你通过指定特定的时间或SCN或输入CANCEL终止DBPITR。基于取消的恢复提示你建议的归档redo日志文件的文件名称。当你指定CANCEL而不是文件名称或所有redo已经应用到数据文件时恢复停止。基于取消的恢复是控制哪个归档日志终止恢复的最佳技术。

4.1．执行基于取消的不完全恢复

在基于取消的恢复中，恢复通过提示建议的归档redo日志文件的名称继续。当你指定CANCEL而不是文件名称或者当所有redo已经应用到数据文件时恢复停止。

过程假设以下：
1）当前的控制文件是可用的。
2）有所有需要的数据文件的备份。

执行基于取消的恢复：
1）遵循“执行关闭的数据库恢复”中的步骤1到8。
2）在SQL*Plus中执行以下命令开始基于取消的恢复：
RECOVER DATABASE UNTIL CANCEL

注：如果你在RECOVER命令中没有指定UNTIL子语句，那么数据库假设是完全恢复和不打开直到应用了所有redo。

数据库应用必要的redo日志文件来重构还原的数据文件。数据库提供它预计从LOG_ARCHIVE_DEST_1中找到的文件名称和请求你停止或继续应用日志文件。如果控制文件是一个备份，那么你必须提供在线redo日志的名称如果你想应用这些日志中的更改。

3）继续应用redo日志文件直到最后的日志已经被应用到还原的数据文件，然后执行以下命令取消恢复：
CANCEL

数据库指示恢复是否是成功的。如果在所有数据文件被恢复到一致的SCN之前取消，然后尝试打开数据库，那么你会收到ORA-1113错误如果更多的恢复是必要的。你可以查询V$RECOVER_FILE来确认是否需要更多的恢复，或在开始不完全恢复之前一个数据文件的备份是否没有被恢复。

4）使用RESETLOGS选项打开数据库。你必须总是在不完整恢复或使用备份的控制文件恢复之后重置日志。
ALTER DATABASE OPEN RESETLOGS;

如果你在不应该时尝试使用OPEN RESETLOGS，或你在应该时忽略重置日志，那么数据库返回一个错误和不打开数据库。纠正错误和再次尝试。

5）在使用RESETLOGS选项打开数据库之后，检查alert日志。

注：最简单定位跟踪文件和alert日志的方法是运行以下SQL查询：
SELECT NAME, VALUE FROM V$DIAG_INFO

当使用RESETLOGS选项打开时，取决于恢复是完全的或不完全的，数据库返回不同的信息。如果恢复是完全的，那么以下信息出现在alert日志中：
RESETLOGS after complete recovery through change scn

如果恢复是不完全的，那么以下信息报告在alert日志中，其中scn指不完全恢复的结束点：
RESETLOGS after incomplete recovery UNTIL CHANGE scn

同时检查alert日志来确认数据库是否检测到数据字典和控制文件之间的不一致。下表描述了两种可能的场景。

数据文件列出在控制文件中	数据文件列出在数据字典中	结果
是	否	从控制文件中移除到未列出的数据文件的标记。在alert日志中的信息指示找到了什么。
否	是	数据库在控制文件中MISSINGnnnn（nnnn是十进制的文件号）下创建一个占位条目。MISSINGnnnn在控制文件中标示为脱机和需要介质恢复。你可以通过为MISSINGnnnn使用ALTER DATABASE RENAME FILE使得对应它的数据文件可访问的以便它指向数据文件。如果没有这个数据文件的备份，那么删除表空间。

4.2．执行基于时间或更改的不完全恢复

你可以为不完全恢复的结束点指定SCN或时间。

如果数据库受季节时间更改影响（例如，夏时制），那么你可能遇到问题如果时间在redo日志中出现两次和你想恢复到第二个或后来的时间。为了处理时间更改，执行基于取消或更改的恢复。

过程假设以下：
1）当前的控制文件是可用的。
2）有所有需要的数据文件的备份。

执行基于更改或时间的恢复：
1）遵循“执行关闭的数据库恢复”中的步骤1到8。
2）执行RECOVER DATABASE UNTIL语句开始恢复。如果要恢复到一个SCN，那么不带引号作为十进制数字指定。例如，恢复到SCN 10034：
RECOVER DATABASE UNTIL CHANGE 10034;

如果恢复到一个时间，那么时间总是使用以下格式用单引号来指定：‘YYYY-MM-DD:HH24:MI:SS’。以下语句恢复数据库到指定的时间：
RECOVER DATABASE UNTIL TIME ‘2000-12-31:12:47:30’

3）应用必要的redo日志文件来恢复还原的数据文件。当到达正确的时间时，数据库自动终止恢复和返回一个信息指明恢复是否成功。

注：除非恢复是自动的，数据库从LOG_ARCHIVE_DEST_1中提供名称和在每个日志之后询问停止或继续。如果控制文件是一个备份，那么在应用完归档日志之后你必须提供在线日志的名称。

4）遵循“执行基于取消的不完全恢复”中的步骤4和5。

5．在非归档模式中恢复数据库

如果介质故障损坏NOARCHIVELOG数据库中的数据文件，那么唯一的恢复选项通常是恢复一致的整个数据库备份。如果你正在使用通过Oracle Data Pump Export创建的逻辑备份来补充常规的物理备份，那么你也可以尝试通过导入已导出的数据库备份到重建的数据库或从旧备份中还原的数据库来还原数据库。

还原和恢复最近的整个数据库备份：
1）如果数据库是打开的，那么关闭数据库。
SHUTDOWN IMMEDIATE

2）如果可能，纠正介质问题以便备份的数据库文件可以还原到它们的原始位置。

3）使用操作系统命令还原最近的整个数据库备份。还原整个数据库备份的所有数据文件和控制文件，而不仅仅是损坏的文件。如果硬件问题没有被纠正和某些或全部数据库文件必须还原到备选的位置，那么还原整个数据库备份到新的位置。以下示例还原整个数据库备份到它的缺省位置：
% cp /backup/*.dbf $ORACLE_HOME/oradata/trgt/

4）如果必要，编辑还原的初始化参数文件来指示控制文件的新位置。
CONTROL_FILES = “/new_disk/oradata/trgt/control01.dbf”

5）使用还原和编辑的参数文件启动实例和挂载，但不打开数据库。
STARTUP MOUNT

6）如果还原的数据文件的名称不同（比如当还原到不同的文件系统或目录，在相同的节点或不同的节点），那么更新控制文件来反映新的数据文件位置。例如，重命名数据文件1：
ALTER DATABASE RENAME FILE ‘?/oradata/trgt/system01.dbf’ TO ‘/new_disk/oradata/system01.dbf’;

7）如果在线redo日志位于损坏的磁盘上和硬件问题没有被纠正，那么为每个受影响的在线日志指定新的位置。
ALTER DATABASE RENAME FILE ‘?/oradata/trgt/redo01.log’ TO ‘/new_disk/oradata/redo_01.log’;
ALTER DATABASE RENAME FILE ‘?/oradata/trgt/redo02.log’ TO ‘/new_disk/oradata/redo_02.log’;

8）因为在线redo日志从不会被备份，你不能与数据文件和控制文件一起还原它们。为了让数据库重置在线redo日志，你必须首先模仿不完全恢复：
RECOVER DATABASE UNTIL CANCEL
CANCEL

9）以RESETLOGS模式打开数据库。这个命令清除在线redo日志和重置日志序列号为1：
ALTER DATABASE OPEN RESETLOGS;

如果你还原NOARCHIVELOG数据库备份，然后重置日志，这个操作丢弃从备份开始到故障期间对数据库做的所有更改。

6．介质恢复故障诊断

本章节描述如何故障诊断用户管理的介质恢复，即不使用RMAN执行的介质恢复。

6.1．关于用户管理的介质恢复问题

下表描述了在介质恢复期间可能发生的潜在问题。

问题	描述
缺失或错误命名归档日志	因为数据库不能找到记录在控制文件中的归档日志，恢复停止。
当尝试打开数据库，错误ORA-1113指示数据文件需要介质恢复	错误通常发生因为： 1）你在执行不完全恢复但未能恢复所有需要的数据文件备份。 2）在数据文件到达一个一致的SCN之前不完全恢复停止。 3）你正在从一个在线的备份中恢复数据文件，但没有应用足够的redo来让数据文件一致。 4）你正在使用备份的控制文件执行恢复和没有指定需要的在线redo日志的位置。 5）当尝试打开数据库时数据文件正在经历介质恢复。 6）需要恢复的数据文件在执行RECOVER DATABASE命令之前没有联机，所以没有恢复。
redo记录问题	两种可能的情况如下： 1）恢复因为失败的一致性检查停止，问题称为stuck recovery。当底层的操作系统或存储系统丢失正常操作期间数据库发出的写时，stuck recovery可能会发生。 2）当应用redo时数据库提示内部错误。这个错误可能由Oracle数据库bug造成。如果没有使用校验和验证，那么错误也可能是由redo或数据块损坏导致。
损坏的归档日志	当存储在存储系统或在存储系统之间拷贝时，日志可能会被损坏。如果DB_BLOCK_CHECKSUM被启用，那么数据库通常显示检验和错误。如果检验和检查被禁用，那么日志损坏可能会作为redo问题出现。
使用不兼容的并行redo格式的归档日志	如果你启用并行的redo特性，那么数据库使用新格式生成redo日志。Oracle以前的版本不能应用并行redo日志。然而，在Oracle 9i（9.2）之前的版本可以检测到并行redo格式和使用以下错误信息指示不一致性：External error 00303, 00000, “cannot process Parallel Redo”.
损坏的数据块	数据文件备份可能包含损坏的数据块，或数据块可能在恢复或拷贝到备份时损坏。如果启用了DB_BLOCK_CHECKSUM，那么数据库在正常操作期间为每个块计算校验和和在写到磁盘之前存储它在块中。当数据库后来从磁盘上读取块时，它重新计算校验和与存储的值比较。如果不匹配，那么数据库显示检验和错误。如果禁用了校验和检查，那么问题也可能作为redo损坏出现。
随机问题	内存损坏和其它临时的问题可能在恢复期间发生。

介质恢复问题的症状通常是恢复期间标示的外部或内部错误。例如，外部错误指示redo块或数据块的校验和验证检查失败。内部错误可能由数据库中的bug或来自于底层操作系统和硬件的错误导致。

当恢复数据库备份时，如果介质恢复遇到问题，那么不管它是stuck recovery问题还是redo应用期间的问题，数据库总是停止和将在经历恢复的数据文件留在一致的状态，即在故障前的一个一致的SCN。然后你可以做以下一个操作：
1）以只读模式打开数据库来调查问题。
2）使用RESETLOGS选项打开数据库，如果以RESETLOGS打开的要求已经满足。同样应用RESETLOGS限制来打开物理备数据库。因为备数据库通过一种介质恢复的形式来更新。

通常，只读打开数据库或使用RESETLOGS选项打开要求所有在线数据文件恢复到相同的SCN。如果要求没有满足，那么在尝试打开它时数据库可能显示ORA-1113或其它错误。ORA-1113错误的某些常见的原因见上表中的描述。

响应介质恢复问题的基本的原则发生在以下阶段：
1）尝试鉴别问题的原因。如果需要运行试验性的恢复。
2）如果问题与缺失redo日志有关或如果你怀疑存在redo日志，内存，或数据块损坏，那么尝试使用上表中描述的方法解决问题。
3）如果你不能使用上表中描述的方法解决问题，那么做以下一个操作：
a．如果你在恢复整个数据库备份，使用RESETLOGS选项打开数据库。如果你已经执行串性的介质恢复，那么数据库包含所有更改直到但不包括损坏发生时的SCN时的更改。这个SCN向前的更改不在数据库的恢复部分中。如果你已经还原在线备份，那么只有已经恢复到redo流中的所有ALTER … END BACKUP操作才能使用RESETLOGS成功打开数据库。
4）通过允许介质恢复损坏数据块来继续恢复。在介质恢复完成之后，尝试使用RMAN执行块介质恢复。

6.2．调查介质恢复问题：阶段1

如果介质恢复遇到问题，那么在恢复终止之后尽可能获取更多的信息。你不想浪费时间修复错误的问题，它可能会让事情更糟糕。

这个最初的调查的目标是确认问题是否由不正确的设置，损坏的redo日志，损坏的数据块，内存损坏或其它问题导致。如果你在数据块上看到校验和错误，那么数据块是损坏的。如果你在redo日志块上看到校验和错误，那么redo日志是损坏的。

有时恢复问题的原因很难确认。不管如何，在本章节的方法让你快速恢复数据库即使你不能完全理解问题的原因。

调查介质恢复问题：
1）检查alert.log来看错误信息是否给出关于问题本性的通用信息。例如，alert_SID.log是否指示任何校验和故障？alert_SID.log是否指示介质恢复可能必须损坏数据块以继续？
2）检查恢复期间Oracle数据库生成的跟踪文件。它可能包含额外的错误信息。

6.3．尝试纠正没有损坏块的恢复问题：阶段2

取决于你怀疑的介质恢复问题的类型，你有不同的方案来处理。你可以尝试下表中的一个或多个技术组合。这些方案是常用的修复技术和相当安全来解决大部分介质恢复问题。

介质恢复解决方案

如果你怀疑…	那么…
缺失或错误命名归档redo日志	确认是否输入正确的文件名称。如果做了，那么检查日志是否从操作系统中缺失。如果它是缺失的和有备份，那么还原备份和应用日志。如果没有备份，那么如果可能执行不完全的恢复直到缺失日志的点。
ALTER DATABASE OPEN的ORA-1113	回顾上表中这个错误的原因。确保需要恢复的所有读写数据文件在线。 如果你使用备份的控制文件来恢复 ，那么控制文件和数据文件必须在一个对要打开的数据库一致的SCN。如果没有必要的redo，那么你必须重建控制文件。
损坏的归档日志	日志是损坏的如果redo日志块的校验和验证失败。如果在恢复会话期间或数据库生成redo时没有启用DB_BLOCK_CHECKSUM，那么恢复问题可能是由损坏的日志导致。如果日志是损坏的和损坏块的备选副本可用，那么尝试应用它和看这个策略是否纠正了问题。 DB_BLOCK_CHECKSUM初始化参数决定是否为redo日志和数据块计算校验和。
具有不兼容并行redo格式的归档日志	如果你运行Oracle 9i（9.2）之前的数据库版本和尝试应用具有并行redo格式的redo日志，那么你必须做以下步骤： 1）升级数据库到后来的版本 。 2）执行介质恢复 3）一致地关闭数据库和备份数据库。 4）降级数据库到原来的版本。
内存损坏或临时问题	你可能可以通过关闭数据库和重启恢复纠正问题。数据库应该被留在一致的状态如果第二次尝试也失败。
损坏的数据块	使用用户管理的方法再次还原和恢复数据文件，或使用RMAN的RECOVER … BLOCK命令还原和恢复个别的数据块。这个技术可能修复这个问题。 数据块是损坏的如果块上的校验和验证失败。如果禁用了DB_BLOCK_CHECKING了，那么损坏的数据块问题可能如redo问题一样出现。如果你必须继续介质恢复，那么你可能想允许介质恢复现在标记块为损坏的，继续恢复，然后使用RMAN执行块介质恢复。

如果你不能使用上表中描述的方法纠正问题，那么可能不存在容易的方式来纠正问题而不丢失数据。你有这些选项：
1）使用RESETLOGS选项打开数据库（为整个数据库恢复）。
这个选项丢弃在redo问题发生点之后的所有更改，但保证一个逻辑一致的数据库。

2）允许介质恢复损坏一个或多个数据块，然后继续。
这个选项只有在alert日志标明如果允许损坏数据块恢复可以继续时才成功，这是对于大部分恢复问题的情况。这个选项是最佳的如果你必须将数据库快速拉起和恢复所有更改。如果你在考虑这个选项，那么继续“决定是否允许恢复标记损坏块：阶段3”。

6.4．决定是否允许恢复标记损坏块：阶段3

当介质恢复遇到问题时，alert日志可能指示如果允许标记导致问题的数据块为损坏的，恢复可以继续。alert日志包含关于块的信息：它的块类型，块地址，它属于的表空间，等等。对于包含用户数据的块，alert日志可能也报告数据对象序号。

在这个情况中，如果允许标记问题块为损坏的，数据库可以继续恢复。不管如何，这个响应不总是可取的。例如，如果块是SYSTEM表空间中一个重要的块，将块标记为损坏的可能最终阻止你打开恢复的数据库。另一个考虑是恢复问题是否是孤立的。如果redo流中的许多其它问题紧跟在问题后面，那么你可能想使用RESETLOGS选项打开数据库。

对于包含用户数据的块，你通常可以查询数据库来发现哪个对象或表拥有这个块。如果数据库不是打开的，那么可以只读的模式打开数据库，即使你正在恢复整个数据库备份。以下示例取消恢复和以只读方式打开数据库：
CANCEL
ALTER DATABASE OPEN READ ONLY;

假设在alert_SID.log中报告的数据对象序号是8031。可以执行以下查询确认属主，对象名称，和对象类型：
SELECT OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_TYPE
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = 8031;

为了确认恢复问题是否是孤立的，可以运行诊断的trial recovery，它扫描问题的redo流但不实际对要恢复的数据库做任何更改。如果尝试性的恢复发现任何恢复问题，那么它报告它们在alert_SID.log中。你可以使用RECOVER … TEST语句来调用尝试性恢复，如“执行RECOVER … TEST语句”中所描述。

在做完这些调查之后，可以遵循下表中的指南决定是否接受恢复允许损坏块。

如果问题是…	和块是…	:那么…
不是孤立的		可以使用RESETLOGS选项打开数据库。这个响应对于stuck recovery问题是重要的，因为stuck recovery可能是操作系统或存储系统丢失写造成的。如果操作系统或存储系统突然出故障，那么可能会在几个块上导致stuck recovery问题。
孤立的	在SYSTEM表空间中	不要损坏块，因为它可能最终阻止你打开数据库。然而，某些时候SYSTEM中的数据是不重要的。如果你必须损坏SYSTEM块和恢复所有更改，那么联系Oracle支持服务。
孤立的	索引数据	考虑损坏索引块因为索引可以在后面数据库已经恢复之后重建。
孤立的	用户数据	基于数据的重要性来决定。如果你继续数据文件恢复和损坏块，那么会丢失块中的数据。然而，你可以在数据文件恢复完成之后使用RMAN执行介质恢复。如果使用RESETLOGS选项打开数据库，那么数据库是一致的但会丢失恢复停止点之后所做的任何更改。
孤立的	回滚或undo数据	如果所有事务已经提交，那么考虑损坏回滚或undo块。数据库是未受损害的如果生成undo的事务从未回滚。然而，如果那些事务被回滚了，那么损坏undo块会导致问题。如果不确定，请联系Oracle支持服务。

6.5．允许恢复损坏块：阶段4

如果你决定即使块损坏也容许恢复继续，那么运行RECOVER命令和ALLOW n CORRUPTION子语句，其中n是容许的损坏块数量。

容许恢复损坏块：
1）确认满足所有正常的恢复前提条件。例如，如果数据库是打开的，那么在尝试恢复前将表空间脱机。
2）如下示例中运行RECOVER命令：
RECOVER DATABASE ALLOW 5 CORRUPTION

6.6．执行尝试性恢复

当问题比如stuck recovery发生时，你有一个艰难的选择。如果块是相对不重要的和问题是孤独的，那么最好损坏块。但如果问题不是孤立的，那么可能最好使用RESETLOGS选项打开数据库。

因为这种情形，Oracle数据库支持尝试性恢复。尝试性恢复以正常介质恢复类似的方式应用redo，但它不会写更改到磁盘和总是回滚它的更改。尝试性恢复只在内存中发生。

6.6.1．尝试性恢复如何工作

缺省情况下，如果尝试性恢复遇到stuck recovery或类似的问题，那么当这个操作允许恢复继续时它总是在内存中将数据块标记为损坏的。数据库将尝试性恢复期间生成的错误写到alert文件中。这些错误会被清晰地标记为测试运行错误。

像正常的介质恢复，尝试性恢复会提示你归档日志文件名称和询问你应用它们。当以下情况发生时，尝试性恢复结束：
1）数据库运行用完尝试性恢复被允许使用的内存中最大数量的缓冲区。
2）示意不可恢复的错误，即，一个不能被损坏数据块解决的错误。
3）你取消或中断恢复会话
4）redo流中下一个redo记录更改控制文件
5）已经应用了所有请求的redo

当尝试性恢复终止时，数据库从系统中移除测试运行的所有影响—除了alert文件中的可能的错误信息。如果实例在尝试性恢复期间故障，那么数据库从系统中移除所有尝试性恢复的影响，因为尝试性恢复从不写更改到磁盘。

尝试性恢复让你预见什么问题可能发生如果你继续正常恢复。对于正在进行的内存损坏导致的问题，尝试性恢复和正常恢复可能会遇到不同的错误。

6.6.2．执行REOCVER … TEST语句

可以为任何RECOVER命令使用TEST选项。例如，你可以启动SQL*Plus，然后执行以下命令：
RECOVER DATABASE TEST
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL TEST
RECOVER TABLESPACE users TEST
RECOVER DATABASE UNTIL CANCEL TEST

缺省情况下，尝试性恢复总是在内存中尝试损坏块如果操作允许尝试性恢复继续。尝试性恢复默认可以损坏无限的数据块数量。你可以在RECOVER … TEST语句上指定ALLOW n CORRUPTION子语句来限制尝试性恢复在内存中可以损坏的数据块数量。

尝试性恢复在正常恢复命令可用的任何场景中都是有用的。不管如何，当恢复遭遇问题时你可以运行尝试性恢复。

来源：《Oracle Database Backup and Recovery User’s Guide，19c》