6.13  基于备份的控制文件的恢复
如果介质恢复时控制文件比当前控制文件旧，则需要进行基于备份的控制文件的恢复（RECOVER DATABASE...USING BACKUP CONTROLFILE）。这适用于控制文件是从一个备份中还原出来的或者用CREATE CONTROLFILE...RESETLOGS命令创建的备份控制文件。

CREATE CONTROLFILE...RESETLOGS命令似的控制文件是一个“备份”。在这个命令之后只能进行基于备份控制文件的恢复，只能用RESETLOGS选项打开数据库。这个命令意味着所有的联机重做日志和控制文件备份都丢失。

相比之下，命令CREATE CONTROLFILE...NORESETLOGS使得控制文件最新。如记录了最新的联机日志和日志序号。这个命令后介质恢复不是必需的。事实上，如果是以“干净”的方式关闭并且没有数据文件是从备份中还原出来的，则不需要进行任何恢复。此后可以以正常的方式或者NORESETLOGS方式打开数据库。

一个备份的控制文件缺乏当前联机日志和数据文件结束SCN的正确信息。因此恢复进程不能找到联机日志并自动应用。并且，恢复进程还得假定结束SCN是无穷大。以RESETLOGS选项打开数据库会纠正该信息。备份的控制文件中包含的启用的线程集合可能跟原始的控制文件也不同，以RESETLOGS选项打开数据库后也会纠正该线程集合信息。

BACKUP CONTROLFILE选项可以独立使用，也可以结合不完全恢复。除非使用了不完全恢复选项，所有线程都要应用重做日志直至线程结束为止。这个会在以RESETLOGS选项打开数据库时验证。

当还原了一个备份的控制文件后，即使没有执行不完全恢复，也会要求以RESETLOGS选项打开数据库。当问题仅仅是因为丢失了当前控制文件（并且存在控制文件备份），下面步骤用来避免基于控制文件的恢复和重置日志：

1.将备份控制文件复制到当前控制文件位置，然后将数据库启动到MOUNTED状态。
2.执行ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS.
3.执行第二步中得到跟踪文件中的SQL：CREATE CONTROLFILE...NORESETLOGS
第三步中的CREATE CONTROLFILE...NORESETLOGS命令很重要，它反映了数据库的结构信息，跟丢失的控制文件一样。如在控制文件备份后添加了一个数据文件，那么CREATE CONTROLFILE 命令就要包含该数据文件的信息。

当控制文件确实是备份的控制文件时，在RECOVER DATABASE命令时用BACKUP CONTROLFILE选项将会失败，这个很快就能检测到。一个迹象就是数据文件头的检查点计数比该数据文件在控制文件中的记录的检查点计数要大。这个测试可能也不能测不出备份控制文件，因为可能数据文件也是从备份中还原。另外一个测试是验证联机日志文件头部跟它们在控制文件中的记录，同样也可能无法测出一个备份控制文件。

6.14  创建数据文件：恢复一个备份中没有的数据文件
如果数据文件丢失或损坏了，而且还没有任何备份，它可以通过重做日志和控制文件中的记录恢复，前提是满足一下条件：

1.自该数据文件创建后的所有重做日志文件都可用。
2.包含该数据文件的信息（名称和大小等）的控制文件可用或者可以重建。
 

首先用ALTER DATABASE CREATE DATAFILE 创建一个新的空的数据文件以替换丢失的数据文件，然后在该数据文件上通过命令RECOVER DATAFILE 应用重做日志，从数据文件创建的时间起到丢失或损坏的那一刻为止。当期间的所有重做日志都应用后，该数据文件就跟丢失前的那一刻状态一致了。这个方法对恢复最近创建的数据文件且没有相应备份的情形很有用。不过SYSTEM表空间的原始数据文件不能用这个方法恢复，因为在数据库创建的时候还没有相应的重做日志保存下来。

6.15  用Export/Import进行即时恢复
偶尔，我们要撤销某个错误的操作（如删除表或者大量数据等）。一个途径就是执行一个在错误时间点之前的不完全恢复，然后重置日志打开数据库。这种方法就导致整个数据库——不仅仅是出错的几个SCHEMA对象——要回到一个过去的时间点。

这个方法有个副作用，就是它丢弃了提交的事务。任何发生在重置日志SCN后的更新都丢失了。重做日志的另外一个副作用就是使得之前所有的备份对将来的恢复都没有用。

因此将数据库全部回滚到过去的一个时间点并不是一个可以接受的方案。下面这个替代方案的副作用仅仅是将受影响的范围限制到恢复的几个对象。

即时不完全恢复是发生在产品数据库的副本上——称之为用于恢复的数据库。该数据库的初始状态取的是产品库发生在那个错误操作之前的备份，在副本数据库上可以将不相干的数据库对象都脱机以避免不必要的恢复。不过SYSTEM表空间和回滚段所在的表空间必须参与恢复以保证能以‘干净的’方式打开数据库。（这也说明了回滚段和数据文件应该分开存放）。

当介质恢复到错误时间之前的那一刻后，以重置日志方式打开数据库。此时数据库处于错误操作之前的一个时间点，等于有了个出错前的数据库版本。将错误操作影响的数据库对象用EXPORT导出来然后导入到产品库中。在导入到产品库之前，先做以下准备：

1.为了恢复一个错误的更新操作，在产品库把受影响的表里的数据先清除掉。如truncate表数据。
2.为了恢复一个错误的删除操作，在产品库里先重建一下被删除的对象（保持空数据）。
 

然后最重要的一步就是用IMPORT导入，选择只导入数据。因为EXPORT/IMPORT是一个漫长的过程，因此可以推迟到无法忍受的时间点执行。同时要恢复的对象也可以通过在产品库和副本库间建DBLINK来随时同步。

这种即时恢复的一个副作用就是跟要恢复的对象有关的事务一致性可能无法保证，不过这个副作用可以通过把要恢复的对象面扩展到跟该事务有关的所有数据库对象。

上一页  [1] [2] [3] [4]