incomplete media recoveryrecovery using a backup control filerecovery with a control file created withthe resetlogs option
当对做过不完全恢复时,联机重做文件中最近的 redo 记录没有被应用,resetlogs 选项在打开数据库之前,把这些未应用的 redo 记录从重做文件中清除掉。
(一起看看周末天坛风光在读哦)
Oracle 官方文档中也提到,一旦用备份的控制文件进行数据库恢复,就需要使用 resetlogs 的方法打开数据库,但是 resetlogs 通常意味着不完全恢复,而且更重要的是一旦用 resetlogs 方法打开数据库,日志的序号用重新从 1 开始。其实如果只是控制文件损坏,日志文件都完整的话,数据库是可以完全恢复的,而且不必非得用 resetlogs 打开。接下来,我们就对不完全恢复做出总结,如下图所示,然后再通过一些实验深入理解。
控制文件的重建方法及后续恢复操作
使用 resetlogs 选项,会把当前的日志序号(logsequence number)重设为 1,并抛弃所有日志信息。在以下条件时需要使用 resetlogs 选项:
指定 RESETLOGS 会执行下列操作:
顾名思义,reset 将重置日志顺序号,那么以前数据库的备份将不再可用
万事万物有果必有因,执行了不完全恢复操作,或者使用了备份的控制文件进行恢复,或者执行 Flashback Database 操作之后,在打开数据库时必须指定 RESETLOGS 选项,这是由 Oracle 自身特性决定的。
正常运行中 Oracle 内部有一个生命周期,这种生命周期在 Oracle 中也有一个专业词汇,叫 incarnation。不完全恢复,顾名思义就是只恢复部分数据,由于已经无法将数据库恢复到当前状态(崩溃前的状态),Oracle 数据库也不知道当前处于什么状态了,事务上也许一致,但是不是最新,Oracle 自己无从判断,后续也许仍有重做日志文件,但却无法应用(或 DBA 不允许应用)。
如果没有 Incarnation 的概念,正常 Open 数据库的话又会产生重做日志文件,并且这些日志文件的序号与之前相同(但内容可能不同),这样不管是备份还是恢复都会造成混淆,因此必须在执行不完全恢复后,标示之前生命周期结束,方法就是以 RESETLOGS 方式打开数据库。以 RESETLOGS 方式打开后,Oracle 数据库又开始了一个新的生命周期,即重置 Incarnation,日志文件序号也被重新初始化到 1。
下图显示了一次 OPEN RESETLOGS 的操作。如果我们画一个时间轴的话,不完全恢复就是将数据库恢复到从备份时间到当前时间之间的某一个点。
数据库在日志文件序号为 1000 时创建了备份,在日志文件序号为 4000 时崩溃,由于日志文件序号为 2501,因此你只能将数据库恢复到日志文件序号为 2500 时的状态,然后以 RESETLOGS 方式打开,Oracle 数据库又开始了一个新的 Incarnation,日志文件序号被重新初始化到 1,然后随着数据库的运行不断增加并达到 4000,但这些日志文件与之前的日志文件并不关联(虽然文件序号相同)。
指定 RESETLOGS 会执行下列操作:
在 10g 之前的版本,数据库执行完 OPEN RESETLOGS 操作之后,都建议立刻进行一次完全备份,因为之前版本中在执行 OPEN RESETLOGS 操作时并不对当前的 Online Redologs 文件进行归档,这会导致归档文件不再连续,因此之前创建的备份不再有效(恢复不到当前状态了,只能恢复到 OPEN RESETLOGS 操作之前)。
10g 及之后版本就不存在这个问题了,OPEN RESETLOGS 操作会首先将当前在线重做日志文件归档(如果能够访问到的话),并且 OPEN RESETLOGS 操作也会记入 Online Redologs 文件并正常归档,相当于 OPEN RESETLOGS 只是一个命令操作,就像其他 SQL 命令一样,这样保证了归档日志文件的连续性,之前的备份依然有效,不过三思仍然建议执行 OPEN RESETLOGS 操作之后马上进行一次全库备份。
提示:什么是Incarnation?
Oracle 数据库的 Incarnation 在有些资料中译作对应物,在我看来可以将其理解成生命周期。Oracle 数据库从创建到遇到 RESETLOGS 操作为一个生命周期,这个生命周期内数据库的逻辑属性,如 SCN、日志文件序列号等具有相同的特征。当通过 OPEN RESETLOGS 方式打开数据库后,原生命周期即宣告结束,原生命周期中生成的重做日志文件也被废弃,日志文件序号自动重置为 1。