N处停止,因为没有超出这个SCN的重做日志存在了。
像2.15中描述的那样,结束SCN是在数据文件脱机时被设置的。如果没有上面这个处理方式,将不能保证数据库打开的时候在结束SCN无穷大的数据文件上的介质恢复何时能停止。
6.11 自动恢复 当介质恢复命令后加上AUTOMATIC选项时将会自动进行介质恢复。它省去了让用户输入归档重做日志文件路径的麻烦,前提是它们在磁盘上。只要日志序号能确定,日志文件名就可以根据数据库初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_FORMAT计算出来。除非用户指定其他的归档目录,当前LOG_ARCHIVE_DEST指定的值将会被使用。介质恢复开始检查点(见6.5)中包含(RBA字段中)线程(产生该开始检查点的线程)初始的日志序号。如果启用了多个重做日志线程,将根据控制文件中的日志历史记录部分将开始SCN映射到各个线程对应的日志序列号。一旦第一个恢复用的日志找到了,后续的日志按顺序应用。如果不能确定初始的日志序号,用户就得猜测直到找到正确的日志。介质恢复开始检查点中的timestamp字段值将帮助用户决定。
6.12 不完全恢复 RECOVER DATABASE命令可以在所有重做日志被应用前停止,这种类型的恢复就是不完全恢复。不完全恢复后打开数据库必须以重置日志方式打开。
不完全恢复将数据库恢复到指定时间点或之前的数据库一致状态。所有后续的更新将丢失。
不完全恢复主要用于下列情形:
a. 因为有文件损坏必须进行介质恢复,但由于某个归档日志或联机日志损坏或丢失,不能进行完全恢复。
b. 所有处于启用状态的联机日志都不可用,因此无法进行实例恢复,这个情形变成上一个情形。
c. 为了恢复一个用户错误的操作(如删了表或者数据等),将数据库恢复到错误操作之前的一个数据库一致的点
6.12.1 Incomplete Recovery UNTIL Options
根据停止的方式分,不完全恢复有三种类型:
a. 基于取消的不完全恢复,命令:RECOVER DATABASE UNTIL CANCEL
b. 基于SCN的不完全恢复,命令:RECOVER DATABASE UNTIL CHANGE
c. 基于时间点的不完全恢复,命令:RECOVER DATABASE UNTIL TIME
基于取消的不完全恢复在用户输入cancel(而不是日志路径)的时候停止恢复。联机日志也不会自动被应用,防止在下一个日志开始前取消。如果多个线程要进行恢复,可能照成某些线程的重做日志只是部分应用。
基于SCN的不完全恢复停止应用指定SCN以及更高SCN相关的重做日志。因此在该SCN时提交的事务(或更晚提交)将会被回滚。如果你想恢复到某个事务提交点SCN时,将将该SCN值加一。
基于时间点的不完全恢复,跟基于SCN的不完全恢复类似,只是输入的是时间点。介质恢复根据重做日志块头部的时间来将该时间点转换成SCN,然后恢复到该SCN处停止。
6.12.2 不完全恢复和数据一致性
为了防止不完全恢复破坏数据库完整性,所有数据文件必须恢复到同一点。并且没有任何一个数据文件拥有该点之后的数据库变更。这就要求介质恢复用的数据文件必须是从早于期望恢复的时间点之前的备份中还原出来的。系统用文件头的模糊位(见8.1)来保证数据文件上没有停止时间点之后的变更。
6.12.3 不完全恢复和控制文件记录的数据文件
如果要不完全恢复到某个数据文件被删除的时间点之前,则控制文件中必须有该被删除的数据文件记录,否则无法进行恢复。而现有的控制文件已经没有该数据文件的记录了。一个可选的方法就是恢复的时候使用删除数据文件之前时间点备份的控制文件进行不完全恢复;另一个可选的方法就是用CREATE CONTROLFILE命令创建一个控制文件包含被删除的数据文件。
不完全恢复到某个数据文件被添加之前的时间点倒没有什么问题。新增的数据文件会在恢复后打开数据库时被忽略,为了避免介质恢复访问该数据文件,该数据文件可能被脱机。
6.12.4 不完全恢复后以重置日志方式打开数据库
不完全恢复后下一步就是以RESETLOGS选项打开数据库。其中一个影响(见第7节)就是数据库丢弃了不完全恢复中没用用到的重做日志,并且后续恢复将再也无法应用这些重做日志。如果是错误的进行了不完全恢复(比如说又找到了丢失的日志),下一步可以以NORESETLOGS选项打开数据库。如果打开成功了,则需要进行成功的完全恢复。
6.12.5 不完全恢复中的脱机文件
如果不完全恢复中某个数据文件处于脱机状态,它不会被恢复。如果该文件是正常脱机的表空间的一部分,不被恢复就没问题。它将一直处于脱机状态直至恢复结束。否则,如果以重置日志方式打开数据库后该数据文件仍然是脱机状态,该 上一页 [1] [2] [3] [4] 下一页
|