ORACLE数据库的备份恢复(3)

用户管理的恢复

介质恢复
介质恢复用于恢复丢失的或损坏的当前数据文件或控制文件。它还可用于恢复数据文件脱机时由于未使用OFFLINE NORMAL 选项而丢失的那些更改。
首先是还原文件(RESTORE)，在还原文件时，其实是使用备份副本替代丢失的或损坏的文件。然后是文件恢复(RECOVER)，在恢复文件时，将重做日志文件中记录的更改应用到所还原的文件中。
介质恢复的步骤如下：
从备份还原损坏的或丢失的文件。
根据需要应用归档重做日志文件和联机重做日志文件中的更改。此时将生成还原块。这称为前滚或高速缓存恢复。
数据库此时可能包含已提交的和未提交的更改。
还原块用于回退任何未提交的更改。这称为回退或事务处理恢复。
数据库现处于已恢复状态。
在还原文件时，使用操作系统命令从备份中复制文件。可以还原数据文件、控制文件、归档重做日志文件和服务器参数文件。
使用SQL*Plus RECOVER 命令将重做日志文件应用到还原的文件中。可以执行自动恢复，或者逐个查看日志文件以应用更改。

在NOARCHIVELOG 模式下，即使只有一个数据文件被损坏或丢失，也必须还原所有的Oracle 数据库文件。确保还原以下所有文件：数据文件和控制文件。
如果您在备份数据文件和控制文件时还备份了联机重做日志文件，则还要还原这些文件。切记，必须将所有的Oracle 数据库文件进行同步，以打开该数据库。
仅当口令文件和参数文件被损坏或丢失时，才应该还原它们。
对于处于NOARCHIVELOG 模式下的数据库，如果自上次备份以来没有覆盖任何重做日志文件，则只需还原受影响的Oracle 数据文件
是否决定在NOARCHIVELOG 模式下操作数据库，应考虑在恢复时的以下优缺点：
优点：易于操作，原因是只需从一个备份中还原所有的文件。唯一的风险在于操作本身：还原错误的备份、覆盖备份、还原之前未关闭数据库或者备份无效。
经过充分的培训和测试，可最大限度地降低此类风险。在给定的硬件和操作系统下，恢复时间只是还原所有文件所花的时间长度。
缺点：自上一次备份后用户输入的所有数据将丢失，必须手动重新应用。,即使只丢失了一个数据文件，也必须从上次执行的、关闭的数据库的整体备份中还原整个数据库。

示例1：
使用重做日志备份恢复。磁盘2 被损坏，结果丢失了数据文件2。仅有2 个联机重做日志文件。
上次备份是在日志序列144 进行的，当前日志序列号为146。
不能恢复该数据文件，因为重做日志144 已被覆盖。如果尝试进行恢复，将会证实这一问题。因此，必须关闭数据库并还原所有的Oracle 文件。
SQL> SHUTDOWN ABORT
要还原文件，请：
UNIX: cp /BACKUP/* /databases/db01/ORADATA
Windows NT: copy d:\disk1\backup\*.* d:\disk1\data\
复制结束后，重新启动例程：
SQL> CONNECT / as sysdba
SQL> STARTUP
通知用户，他们需要重新输入自上一次备份以后输入的数据。

示例2：
不使用重做日志备份进行恢复。
如果数据库已打开，则按如下方式关闭它：
SQL> SHUTDOWN IMMEDIATE
使用操作系统命令还原对数据库的最新而且完整的备份。必须还原所有的数据文件和控制文件，而不仅仅是还原损坏的文件。以下示例还原了数据库的完整备份：
$ cp /db01/BACKUP/*.dbf /ORADATA/u*/* # restores datafiles
$ cp /db01/BACKUP/*.ctl /ORADATA/u*/* # restores control file
因为您没有备份联机重做日志，所以不能使用数据文件和控制文件还原它们。因此，Oracle 允许重置联机重做日志，您必须按如下方式仿效进行不完全恢复：
SQL> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE
SQL> CANCEL
然后，使用RESETLOGS 选项打开数据库，将当前的重做日志序列重置为1（如下所示）：
SQL> ALTER DATABASE OPEN RESETLOGS;

在ARCHIVELOG 模式下执行完全恢复
在执行介质恢复时，您将还原的文件更新到当前时间，或者更新到由用户指定的、除当前时间之外的时间。
在完全恢复中，使用重做日志文件或增量备份将还原文件更新到最近的时间点。将归档重做日志文件和联机重做日志文件中包含的重做更改全部应用到这些文件中。
可以对数据库表空间或数据文件执行完全恢复。对于不完全恢复，其实就是将数据库恢复到当前时间以前的某一时刻。通常，您并不会应用备份后生成的所有重做条目。
完全恢复要确保要还原的数据文件处于脱机状态。仅还原丢失的或损坏的数据文件。不要还原控制文件、重做日志文件、口令文件或参数文件。恢复数据文件。
当处于ARCHIVELOG 模式的数据库发生介质故障时，需要使用以下内容将数据库完全恢复到发生故障前那一刻的情形：
在将数据库设置为ARCHIVELOG 模式后进行的有效备份（其中包含丢失的或损坏的
数据文件），从您所使用的备份起至今的所有归档日志，包含尚未归档的事务处理的重做日志文件。
在ARCHIVELOG 模式下进行完全恢复的优缺点：
优点：仅需还原丢失或损坏的文件。已提交的数据不会丢失。通过还原上述文件并应用归档日志和重做日志，就可将数据库恢复至当前的时间点。
恢复的总时间就等于还原文件并应用所有归档日志和重做日志所需的时间。可以在数据库打开的情况下进行恢复（包含联机还原段的系统表空间文件和数据文件除外）。
缺点：必须有自上次备份起到当前时间的所有归档重做日志文件。
如果缺失一个文件，则无法执行完全恢复，原因是必须依次应用所有的归档重做日志文件；即，先应用归档日志144，其次是145，再次是146，以此类推。
要确定需要恢复哪些数据文件以及需要从哪里开始恢复，请按如下方式使用
V$RECOVER_FILE 视图：SQL> SELECT * FROM v$recover_file;
要查找归档日志文件，可查看V$ARCHIVED_LOG 以获得所有归档日志文件，或查看V$RECOVERY_LOG 以获得恢复时所需的归档日志文件：

使用用户管理的过程将数据文件还原到新的位置：
1. 使用操作系统命令将文件还原到新的位置。
注：在UNIX 环境中，在发出ALTER DATABASE RENAME 命令之前，文件必
须位于新位置。在Windows NT 环境中，则不必如此。
2. 启动该例程并装载数据库。
3. 使用ALTER DATABASE 命令来更新控制文件，将其更新为新的文件名或更新到
新的位置：
SQL> ALTER DATABASE RENAME FILE
2> ‘/ORADATA/u03/users01.dbf‘
3> to ‘/ORADATA/u04/users01.dbf‘;

完全恢复的方法：
执行完全恢复的方法有4 种：
方法1：恢复关闭的数据库
此方法适用于以下情况：数据库不是全天候（每周7 天、每天24 小时）运行。恢复的文件属于系统表空间或还原段表空间。需要恢复整个数据库或大部分数据文件。
方法2：恢复打开的数据库（数据库最初是打开的）
此恢复方法一般在以下情况下使用：发生了文件损坏、文件意外丢失或介质故障，但未导致数据库关闭。数据库全天候（每周7 天、每天24 小时）运行。
必须最大限度地减少数据库的停机时间。恢复的文件不属于系统表空间或还原段表空间。
方法3：恢复打开的数据库（数据库最初是关闭的）
此恢复方法一般在以下情况下使用：某个介质故障或硬件故障导致系统关闭。数据库全天候（每周7 天、每天24 小时）运行。必须最大限度地减少数据库的停机时间。还原的文件不属于系统表空间或还原段表空间。
方法4：在没有备份的情况下恢复数据文件
此恢复方法一般在以下情况下使用：介质故障或用户故障导致丢失了从未备份过的数据文件。自该文件创建以来的所有归档日志都存在。还原的文件不属于系统表空间或还原段表空间。
恢复过程中，磁盘中必须有Oracle 服务器所需的所有归档日志文件。如果这些文件在备份磁带中，则必须先还原这些文件。

完全恢复关闭的数据库
在以下情况中，通常将此恢复方法与RECOVER DATABASE 命令或RECOVER DATAFILE命令一起使用：
恢复的文件属于系统表空间或回退段表空间。需要恢复整个数据库或大部分数据文件。数据库不是全天候（每周7 天、每天24 小时）运行。示例：
已确定u01（数据文件1 存储在其中）包含被损坏的块。通过查询V$DATAFILE 和V$TABLESPACE 视图，可以发现数据文件1 是系统表空间所属的文件之一。请按照以下步骤恢复数据库：
1. 如果例程尚未关闭，请按如下方式发出SHUTDOWN 命令：
SQL> SHUTDOWN ABORT
2. 从备份（可用的最新备份）中还原该文件：
UNIX> host cp /BACKUP/system01.dbf /ORADATA/u01
Windows NT > host copy c:\backup\df1.dbf d:\data\
3. 以“装载” 模式启动例程，并恢复该数据文件：
SQL> STARTUP MOUNT
SQL> RECOVER DATABASE
or SQL> RECOVER DATAFILE ‘/ORADATA/u01/system01.dbf‘
要将数据文件恢复到发生故障前的那一刻，应该应用所有需要的归档日志和重做日
志。
4. 恢复结束后，所有数据文件都将实现同步。打开数据库。
SQL> ALTER DATABASE OPEN;
此时，可通知用户数据库可以使用了，并告诉他们重新输入系统发生故障前未提交的所有数据。
在使用此恢复方法进行恢复的期间，必须关闭数据库；在恢复进程中，整个数据库都无法让用户进行访问。

恢复打开的数据库（数据库最初是打开的）
此恢复方法一般在以下情况下使用：
未导致数据库关闭的文件损坏、文件意外丢失或介质故障。数据库全天候（每周7 天、每天24 小时）运行。必须最大限度地减少数据库的停机时间。受到影响的文件不属于系统表空间或还原/回退段表空间。示例：
数据库当前已打开，并且已使用操作系统命令误删了数据文件2。因为数据库当前已打开，所以可以使用以下命令确定该数据文件属于哪个表空间：
SQL> SELECT file_id f#, file_name,
2> tablespace_name tablespace, status
3> FROM dba_data_files;
1. 发出以下查询，以确定是否需要将数据文件2 脱机：
SQL> SELECT d.file# f#, d.name, d.status, h.status
2> FROM v$datafile d, v$datafile_header h
3> WHERE d.file# = h.file#;
2. 因为该文件处于脱机状态，所以此时可从备份中还原该文件：
UNIX > host cp /disk1/backup/df2.dbf /disk2/data/
Windows NT > host copy c:\backup\df2.dbf d:\data\
3. 使用RECOVER 命令将归档和重做日志应用到还原的数据文件中。
SQL> RECOVER DATAFILE ‘/disk2/backup/df2.dbf‘
or SQL> RECOVER TABLESPACE user_data
4. 恢复结束后，所有数据文件都将实现同步。将该数据文件联机：
SQL> ALTER DATABASE DATAFILE ‘/disk2/data/df2.dbf‘ ONLINE;
或SQL> ALTER TABLESPACE user_data ONLINE;

有时Oracle 服务器会检测到某个文件有问题并自动将该文件脱机。在进行恢复之前，一定要查看警报日志以检查是否有任何错误，并检查文件的状态；可能需要恢复脱机文件。
在将表空间脱机后，就会将其所有数据文件脱机，并且无法访问该表空间中包含的任何数据。
对于具有多个文件的表空间来说，如果将其中一个数据文件脱机，则只有该数据文件中包含的数据无法进行访问，而表空间仍然可以使用。


恢复打开的数据库（数据库最初是关闭的）此恢复方法一般在以下情况下使用：介质或硬件故障导致系统关闭。
数据库全天候（每周7 天、每天24 小时）运行。必须最大限度地减少数据库的停机时间。损坏的文件不属于系统表空间或还原段表空间。示例：
您刚刚确定介质故障是由于某个磁盘控制器发生故障而引起的，该控制器只包含磁盘2。
根据您对数据库的了解，您知道数据文件2 不是系统数据文件或还原段数据文件，并且并不会由于无法使用该文件而妨碍用户运行其月末报告。
1. 装载该数据库。由于数据文件2 无法打开，因此无法打开该数据库。
SQL> STARTUP MOUNT
2. 如果该数据文件未脱机，则无法打开数据库。因此，必须将该文件脱机。您已经
查询了V$DATAFILE 并确定该文件处于联机状态。
SQL> ALTER DATABASE datafile ‘/disk2/data/df2.dbf‘ offline;
注：此时不能使用ALTER TABLESPACE 命令，原因是数据库尚未打开。
3. 然后就可以打开数据库，使用户能够访问系统：
SQL> ALTER DATABASE OPEN;
4. 然后，还原该文件。因为无法将文件还原到损坏的磁盘2 上，所以将它还原到磁盘3 上：
UNIX > host cp /disk1/backup/df2.dbf /disk3/data/
Windows NT > host copy c:\backup\df2.dbf e:\data\
现在必须通知Oracle 服务器新文件的位置：
SQL> ALTER DATABASE rename file ‘/disk2/data/df2.dbf‘
2> to ‘/disk3/data/df2.dbf‘;
如果数据库已打开并且需要恢复表空间，请发出以下查询，以确定该数据文件所属的表空间的名称：
SQL> SELECT file_id f#, file_name,
2> tablespace_name tablespace, status
3> FROM dba_data_files;
5. 使用RECOVER 或ALTER DATABASE RECOVER 命令开始将归档重做日志文件和联
机重做日志文件应用到还原的数据文件中。
SQL> RECOVER DATAFILE ‘/disk3/data/df2.dbf‘
或SQL> RECOVER TABLESPACE user_data
6. 恢复结束后，所有数据文件都将实现同步。将该数据文件联机：
SQL> ALTER DATABASE datafile ‘/disk3/data/df2.dbf‘ online;
或SQL> ALTER TABLESPACE user_data online;

在没有备份的情况下恢复数据文件，此恢复方法一般在下列情况使用：介质故障或用户故障导致丢失了从未备份过的数据文件，
自该文件创建以来的所有归档日志都存在，受到影响的文件不属于系统表空间或还原段表空间。
如果定期备份中不包含新的表空间或数据文件，或者该数据文件的备份丢失了，则通常使用该方法。使用ALTER DATABASE 命令，用相同的名称重新创建该数据文件：
SQL> ALTER DATABASE CREATE DATAFILE
2> '/ORADATA/u03/users01.dbf';
将使用数据字典中记录的原始文件名创建该文件。使用以下版本重新创建该数据文件，但使用新的文件名或位置：
SQL> ALTER DATABASE CREATE DATAFILE
2> '/ORADATA/u03/users01.dbf'
3> AS '/ORADATA/u04/users01.dbf';
查询V$RECOVER_FILE 确定恢复状态，以检查备份的状态：

1. 如果数据库已关闭，则装载该数据库、将该数据文件（无备份）脱机，然后打开数据库。这将允许不需要TABLE_DATA 表空间的用户对系统执行操作。
如果数据库已打开，则将该数据文件或表空间脱机。如果数据库已打开，则必须包含“立即” (IMMEDIATE) 选项，以避免数据库写入器试图写入到一个并不存在的文件中：
SQL> ALTER TABLESPACE table_data OFFLINE IMMEDIATE;
Tablespace altered.
查询V$RECOVER_FILE 确定恢复状态，以检查备份的状态：
SQL> SELECT * FROM v$recover_file;
2. 发出以下命令来重新创建该文件：
SQL> ALTER DATABASE create datafile ‘/disk2/DATA/df4.dbf’
2> as ‘/disk1/DATA/df4.dbf‘;
SQL> SELECT * FROM v$recover_file;
3. 用RECOVER 或ALTER DATABASE RECOVER 命令，开始将归档重做日志文件和联机
重做日志文件应用到重新创建的数据文件中：
SQL> RECOVER TABLESPACE table_data;
要将数据文件恢复到发生故障前的那一刻，应该应用所有需要的归档日志和重做日
志。此时所有数据文件都将实现同步。
4. 恢复完成后，将该表空间联机：
SQL> ALTER TABLESPACE table_data ONLINE;
所有数据现已恢复。将文件包括在备份策略中，并通知用户可以再次使用表空间了。

只读表空间恢复
情况1：被恢复的表空间现在是只读的，并且在上次备份时也是只读的。在这种情况下，只需从备份中还原表空间。无需应用任何重做信息。
情况2：被恢复的表空间现在可读写，但在上次备份时则是只读的。在这种情况下，需要从备份中还原表空间，并应用自表空间被设置为可读写状态以来的重做信息。
情况3：被恢复的表空间现在是只读的，但在上次备份时是可读写的。因为您应该在将表空间设置为只读状态后始终对它进行备份，所以不应该遇到这种情况。
但是，如果确实出现这种情况，则必须从备份中还原表空间，并将其恢复到被设置为只读状态前的那一刻。
如果您需要用CREATE CONTROL FILE 命令重新创建控制文件，并且您的数据库有只读表空间，则必须按照特殊的过程进行操作。发出ALTER DATABASE BACKUP CONTROLFILE TO TRACE 命令以获得这些过程的列表。
如果不能将只读数据表空间中的数据文件副本还原到正确的目标位置，则可以使用ALTER DATABASE RENAME 命令将这些文件放到新的位置。
带备份控制文件的只读表空间与脱机正常表空间的恢复过程实质上是相同的，只是您需要在打开数据库后将表空间联机。

丢失控制文件的恢复
以下是三种可能需要您恢复或重新创建控制文件的情形：
第一，所有控制文件由于某个故障而丢失。如果您已正确地多元备份了控制文件并将这些文件分布到多个物理设备上，则很少会遇到这种问题。
第二，您需要更改数据库的名称。如果数据库将成为分布式环境的一部分，并且其它数据库具有相同的名称，则有必要更改数据库的名称。如果是出于恢复目的而还原数据库，则可能也需要更改其名称。
第三，您需要更改控制文件中的设置。控制文件中的很多设置是在文件创建之时确定下来的。在创建了控制文件后，就不能动态地更改这些设置；若要更改这些设置，必须重新创建控制文件。
有三种方法可以用于还原和恢复控制文件：
第一，用当前副本还原丢失的文件。这种方法假定您没有丢失所有的控制文件。
第二，使用CREATE CONTROLFILE 命令创建一个新文件。要完成此项操作必须知道数据库的所有文件。间或备份控制文件以进行跟踪有助于完成此过程。
第三，使用RECOVER DATABASE USING BACKUP CONTROLFILE 命令。如果丢失了所有的控制文件，则需要使用此命令。
如果使用镜像的数据文件正确配置数据库，则丢失所有控制文件的可能性将降至最低。

不完全恢复
不完全恢复能够重建数据库，使之恢复到以前的某个时间点（发生故障之前）。该情况会导致进行恢复操作后提交的事务处理中丢失数据。
如果需要，这些数据将需要手动重新输入。只在绝对必要的情况下执行这种恢复操作。不完全恢复操作可能比较困难而且耗费时间较长。要执行不完全恢复，需要：
恢复时间点之前制作的所有数据文件的有效脱机或联机备份,截止到指定的恢复时间之前备份中生成的所有归档日志通常在完全恢复操作失败的情况下进行不完全恢复。
需要进行不完全恢复的常见情况：
丢失归档：由于归档日志损坏或丢失，完全恢复操作失败。数据库只能恢复到应用归档日志之前的过去的某一时间的状态。
丢失重做日志：未镜像重做日志，并且重做日志在归档之前丢失，数据文件也丢失。恢复无法继续到丢失的重做日志之后。
用户错误：用户错误地删除了某个表，提交了用错误的WHERE 子句更新的数据等等。
丢失控制文件：您未镜像控制文件，不知道数据库的结构，但您有旧的二进制副本的备份。
不完全恢复的类型：
基于时间的恢复，截止指定时间点之前的所有更改提交后，该恢复方法终止。
在以下情况下使用此方法：对数据作出了不必要的更改，或者删除了重要的表，并且知道错误发生的大概时间。
如果您立即得到通知，恢复时间最短、数据损失最少。精心测试过的程序、安全性和过程应当可以避免此类恢复。知道未镜像的联机重做日志损坏的大概时间。镜像日志可以避免此类恢复。
基于取消的恢复，在恢复提示符下输入CANCEL（而不是日志文件名），即可终止该恢复方法。在以下情况下使用此方法：当前重做日志文件或组被破坏，并且不可用于恢复。
镜像可以避免此类恢复。进行恢复所需的归档重做日志文件丢失。经常备份并将归档存放在多个目标位置可以避免此类恢复。
基于更改的恢复，截止指定系统更改编号(SCN) 之前所做的所有更改提交之后，该恢复方法即终止。在分布式环境中恢复数据库时，使用这种方法。
使用备份控制文件恢复，指定的恢复方法（基于取消、基于时间或基于更改的恢复）已完成或控制文件已恢复时，该恢复方法终止。
必须在RECOVER DATABASE 命令中指定恢复将使用控制文件的旧副本。在以下情况下使用这种方法：
所有控制文件都已丢失，并且无法重新创建，但存在控制文件的二进制备份。镜像控制
文件（至不同磁盘）并保留CREATE CONTROLFILE 语句的当前文本版本将减少使用该方法的几率。将某个结构与当前数据库不同的数据库还原到先前的某个时间点。

不完全恢复原则：
认真按照所有恢复步骤进行操作很重要，因为不完全恢复的大多数问题都是由恢复过程中的DBA 错误造成的。事务活动只能前滚至期望的时间，而不能回退至期望的时间。
这就是对要及时恢复的数据库必须还原所有数据文件的原因。如果没能还原所有数据文件，将无法打开（非同步）数据库。
开始不完全恢复之前应执行整体关闭数据库备份（包括控制文件和重做日志）。这样
做的好处有：允许从错误中恢复。如果恢复失败（例如，恢复超出了期望的恢复点），重做
日志和控制文件将无法用于下一次恢复，除非存在这些文件的备份。如果恢复失败，可以节省时间。在这种情况下，可以以从新备份中还原数据文件，而不是从需要应用归档的上一次备份中还原。
如果不执行整体备份，至少应归档当前重做日志(ALTER SYSTEM
ARCHIVE LOG CURRENT) 并备份控制文件(ALTER DATABASE BACKUP
CONTROLFILE TO <LOCATION>)。
恢复成功后，执行关闭的数据库的整体备份。如果需要进行恢复才能完成下一次排定的备份，则建议使用这种方法。
在允许用户访问系统之前一定要验证故障是否已经修复，以防止恢复失败而需要再次进行恢复。从系统中备份（以后删除）归档日志，以避免混合不同数据库复本中的归档。

不完全恢复的步骤
出现故障而要求进行不完全恢复时，必须拥有下列文件才能进行恢复：包含所有数据文件的有效脱机或联机备份。从上次还原的备份到发生故障之前的所有归档重做日志。
请按照下列步骤进行恢复：
1. 对现有数据库执行关闭的数据库的完全备份。关闭数据库，从备份还原所有数据
文件（包括系统表空间文件）。
2. 还原所有数据文件，以及时恢复数据库。
3. 将数据库置于装载模式并确保数据文件处于联机状态。
4. 恢复数据库。
5. 使用RESETLOGS 选项打开数据库并验证恢复。
6. 对数据库执行关闭的数据库的整体备份。
以下命令用于执行不完全恢复：
RECOVER [AUTOMATIC] DATABASE <Option>
其中：
automatic：自动应用归档和重做日志文件。
option: until time ‘YYYY-MM-DD:HH:MI:SS’
until cancel
until scn <integer>
using backup control file
注：要在恢复过程中自动应用重做日志文件，可以使用SQL*Plus 命令SET
AUTORECOVERY ON，在恢复提示符后输入AUTO，或者使用SQL 命令RECOVER
AUTOMATIC。

基于时间的恢复示例：
当前时间是2001 年3 月9 日夜间12:00。
EMPLOYEES 表已被删除。
删除该表的时间大约是上午11:45。
由于大多数员工当前都在开会，数据库的活动很少。该表必须进行恢复。 使用UNTIL TIME 进行不完全恢复：
关闭数据库并开始恢复。由于知道故障发生的大概时间，并且数据库结构从上午11:44 之后并未更改，因此，可以使用UNTIL TIME 方法：
1. 如果数据库已打开，使用NORMAL 或IMMEDIATE 或TRANSACTIONAL 选项关闭数据库。
2. 从备份还原所有数据文件（尽可能使用最新备份）。可能需要还原归档日志。
如果有足够的可用空间，还原到LOG_ARCHIVE_DEST 位置，或使用ALTER SYSTEM ARCHIVE LOG START TO <LOCATION> 或SET LOGSOURCE <LOCATION> 更改位置。
3. 装载数据库。
4. 恢复数据库：
SQL> recover database until time ‘2001-03-09:11:44:00’
5. 要将数据文件与控制文件和重做日志同步，应使用RESETLOGS 选项打开数据库：
SQL> alter database open resetlogs;
SQL> archive log list
6. 执行关闭的数据库的整体备份之前，查询EMPLOYEES 表以确保该表存在。
恢复成功并且备份完成后，通知用户该数据库可以使用，而恢复时间（上午11:44）后输入的所有数据将需要重新输入。

基于取消的恢复示例：
当前时间是2001 年3 月9 日夜间12:00。
某人尝试修复损坏的块时删除了EMPLOYEES 表。
日志文件都位于同一磁盘上。
删除该表的时间大约是上午11:45。
员工当前正在开会。
您担心是磁盘错误导致EMPLOYEES 表中的块损坏。由于重做日志都包含在同一磁盘中，
您决定检查重做日志和归档日志的状态：
SQL> select * from v$logfile;
SQL> select * from v$log;
重做日志未多元备份。有一个联机重做日志缺失。缺失的重做日志未归档。重做日志包含自上午11:34 以来的信息。26 分钟的数据将丢失。用户可恢复其数据。
对/disk1/data 目录进行搜索之后，发现找不到重做日志log2a.rdo，并且该日志未归
档。因此，不能恢复该点之后的数据。
查询V$LOG_HISTORY 确认缺少归档日志序列48 (log2a.rdo)：
SQL> select * from v$log_history;
由于这是OLTP 系统，V$LOG 的输出显示：如果数据库是在应用log2a.rdo 之前恢复的，另外10 分钟的工作将丢失。用户不愿意丢失工作，但可以恢复该工作。可以以按照以下步骤恢复数据库：
1. 关闭数据库。
2. 从最新备份还原所有数据文件。
3. 您已经拥有有效备份，因此请装载数据库。
4. 将数据库恢复到序列号为48 的日志：
SQL> recover database until cancel
5. 使用RESETLOGS 选项打开数据库。
6. 检查EMPLOYEES 表是否存在。
7. 恢复完成后，制作一份备份。通知用户该数据库可以使用，而恢复时间（上午11:34）
之后输入的所有数据将需要重新输入。

恢复期间使用备份控制文件：
当前时间是2001 年3 月9 日夜间12:00。包含EMPLOYEES 表的表空间已被删除。错误出现的时间大约是上午11:45。许多员工记录都在这一天早晨更新，但上午11:00 之后没有更新。每天晚上都进行备份。
前一晚的备份包含恢复所需的数据文件和控制文件。EMP_TS 表空间有一个数据文件。当前日志序列号是61。确认该表空间是在2001 年3 月9 日上午11:44:54被删除的。数据文件编号4 处于脱机状态。
1. 包含EMPLOYEES 表的表空间已被删除，如下所示：
SQL> drop tablespace emp_ts including contents;
2. 您立即要求用户注销并保留过去15 分钟内输入的数据记录。在等待所有用户注销并且其余会话终止时，您将数据库置于受限模式以防止进一步的访问：
SQL> alter system enable restricted session;
3. 调查过程中，您从前一晚的备份中找到了二进制控制文件。由于当前的控制文件将被替换，因此应仔细收集数据库结构信息，以备不时之需：
SQL> select * from v$log;
4. 您通过检查警报日志确定错误发生时间：
5. 关闭数据库、备份控制文件、然后还原表空间存在时的某个时间点的数据库的所有数据文件和控制文件。尝试打开数据库之后，以下错误将通知您重做日志与控制文件不同步：
ORA-00314: log 1 of thread 1,expected sequence# doesn't match
ORA-00312: online log 1 thread 1: '/disk1/data/log1a.rdo'
6. 验证是否存在脱机数据文件并使它们处于联机状态，因为恢复后所有脱机文件可能无法恢复：
SQL> select * from v$recover_file;
SQL> alter database datafile 4 online;
7. 执行恢复：
SQL> recover database until time '2001-03-09:11:44:00'
2> using backup controlfile;
8. 要使数据文件与控制文件和重做日志同步，请用RESETLOGS 选项打开数据库。
9. 检查EMPLOYEES 表是否存在。
10. 进行整体备份。
11. 通知用户数据库可以使用，需要重新输入在上午11:44 之后输入的所有数据。

当前联机重做日志文件的丢失的恢复
当前联机重做日志丢失，如果数据库已经关闭：尝试打开数据库。查找当前日志序列号。恢复发出取消命令之前的数据库。如果需要，应删除并重新创建日志文件。使用RESETLOGS 打开数据库。执行整体数据库备份。
如果数据库关闭，可能发生了介质故障或者后台进程可能已终止。按照以下步骤纠正该情况：
1. 如果尝试打开数据库，以下消息将立即通知您当前的重做日志组：
Database mounted.
ORA-00313: open failed for members of log group 2 of
thread 1
ORA-00312: online log 2 thread 1: '/disk1/archive/log2a.rdo'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
由于日志组2 是当前日志组，因此尚未归档。使用CLEAR LOGFILE 命令无效，原因是：
SQL> alter database clear unarchived logfile group 2;
ORA-01624: log 2 needed for crash recovery of thread 1
ORA-00312: online log 2 thread 1: 'disk1/archive/log2a.rdo'
2. 因此需要不完全恢复。首先，必须记录当前日志序列号：
SQL> select * from v$log;
3. 从先前的备份还原所有数据文件，使用RECOVER UNTIL CANCEL 命令并在应用重做日志61 之前停止：
SQL> recover database until cancel;
4. 使用RESETLOGS 选项打开数据库。
5. 现在数据库应该可以运行了，因为将重新创建所有丢失的日志文件。
注：如果由于介质故障需要在另一个磁盘上重新创建日志文件，请使用ALTER
DATABASE DROP LOG GROUP 和ALTER DATABASE ADD LOG GROUP 命令手动创建日志文件。
6. 由于您刚刚执行了不完全恢复，因此，现在应备份数据库。