Oracle恢复内部原理(重置日志RESETLOGS)

重置日志的最主要的作用就是丢弃不完全恢复中没有使用的重做日志并保证后续的恢复不再需要。为此，重置日志选项将所有联机日志和

重置日志选项用于下列情形后的第一次打开数据库的时候：

1.不完全恢复

2.基于备份控制文件的恢复

3.CREATE CONTROLFILE...RESETLOGS

重置日志的最主要的作用就是丢弃不完全恢复中没有使用的重做日志并保证后续的恢复不再需要。为此，重置日志选项将所有联机日志和归档日志都做废掉。副作用就是此前的所有备份对将来的恢复都没有用了。

重做日志选项还初始化了控制文件中关于联机日志和重做线程的内容，清除了当前存在的联机重做日志的内容，如果联机日志文件不存在就创建，并重置了所有线程的日志序号。

系列文章：Oracle恢复内部原理 ?where=nkey&keyword=19824

8.1  模糊的文件

以重做日志选项方式打开数据库时最重要的事情就是检验所有的数据文件都被恢复到同一个时间点。这保证了单笔重做日志的所有变更都自动应用了。这点对其他的一致性原因也很重要。如果所有线程重做日志都应用到所有联机数据文件上，当然可以说数据库是一致的。

如果进行了不完全恢复，有可能某个文件不是从足够旧的备份中恢复过来。通常这点可以通过检测该数据文件的头部的检查点跟其他数据文件不一致而发现（脱机文件和只读文件是例外）。

另外一种可能性就是这个文件是“模糊的”。它可能包含了超出它检查点SCN的变更。由前面章节知数据文件头部维护了下面这些“模糊状态位”来判断数据文件是否是“模糊的”：

 1.联机模糊位（见3.5，6.7.2）

2.热备份模糊位（见4，6.7.3）

3.介质恢复模糊位（见6.7.1）

不完全恢复后以重置日志方式打开数据库时如果联机数据文件的模糊被设置了则会打开失败。

热备份或崩溃恢复结束时会写一笔重做日志记录使得介质恢复可以决定何时可以清除这些模糊位。重做日志会报错如果这些模糊位还没有被清除。

当数据文件中有一个数据文件结束恢复时的检查点SCN跟其他数据文件的检查点SCN（重置日志SCN，见8.2）不一致时，重置日志会报错，除非是下面这几种情形：

1.            一个数据文件恢复到一个比重置SCN要早点的SCN是可以接受的，前提是该数据文件在二者之间已经没有重做日志可以应用。举例说明，该数据文件是只读的或者脱机的，且脱机范围覆盖了结束恢复时的SCN和重置SCN。这种情形下重做日志允许该数据文件设置为脱机。

2.            一个数据文件做检查点的SCN比重做SCN要晚，，前提是它的创建SCN（在创建数据文件的时候分配的，保存在文件头中）显示它是在重置SCN以后创建的。重做日志时检查数据字典和控制文件会发现该数据文件在数据字典中不存在但控制文件中存在。结果，它会从控制文件中被清除。

8.2  重置SCN和计数器

控制文件的数据库信息部分记录了一个重置日志的SCN和时间点（合称重置日志数据）。重置日志数据是为了唯一标识每次重做日志打开数据库的操作，同时也保存在每个数据文件头和日志文件头。日志文件中的重置日志数据如果跟控制文件中记录的不一致就不能应用该日志文件中的重做日志。数据文件中的重做日志数据如果跟控制文件中记录的不一致则该数据文件就不能被访问或者恢复，除非某些特殊情形（如该数据文件所在表空间正常脱机或者是只读的）。这保证了被重置日志丢弃的重做日志不会再被应用到数据库中，也声明了此前的任何备份对将来的恢复都是无用的。因此重做日志后立即做一个备份时聪明之举。

8.3  重置日志对线程的影响

重置日志时，每个线程的控制文件记录都清除线程打开标记并将线程检查点SCN设置到重置SCN。因此看起来线程好像在重置SCN处关闭了。控制文件中数据库信息部分记录的启用的线程列表依旧可以使用。此时哪个线程在恢复结束被启用已经不重要了，因为此前的重做日志已经不需要了。所有线程的日志序号都被置为 1，其中一个线程的检查点被选为数据库检查点。

8.4  重置日志对日志文件的影响

所有联机日志都被清零，意味着所有的重做日志都被永久丢弃，除非在重做日志之前有备份联机日志，否则没有任何办法可以恢复这些联机日志。因此要恢复错误的清除联机日志的唯一方案就是联机日志有备份。要恢复一个错误的重做日志操作，必须先还原所有的数据文件、控制文件和联机日志文件，然后全部恢复。

每个启用的线程会挑选一个日志文件作为当前日志。那个日志头部将写为日志序号1.注意日志文件和相关的线程是从控制文件中取出来的（用控制文件中记录的线程号和它的日志集合）。如果这个控制文件是备份的控制文件，可能跟数据库最后一次打开的时候有点区别。