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

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

1. 不完全恢复
2. 基于备份控制文件的恢复
3. CREATE CONTROLFILE...RESETLOGS

 

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

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

 

 

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.注意日志文件和相关的线程是从控制文件中取出来的（用控制文件中记录的线程号和它的日志集合）。如果这个控制文件是备份的控制文件，可能跟数据库最后一次打开的时候有点区别。

 

8.5  重置日志对联机数据文件的影响

所有联机数据文件头的检查点都更新为新的数据库检查点。新的重置数据会更新到各个联机数据文件头部。

 

8.6  重置日志对脱机数据文件的影响

脱机数据文件在控制文件中的记录显示需要做介质恢复。不过这是不可能的，因为它需要应用的重做日志的日志文件的重置数据已经不对了。这意味着包含这个数据文件的表空间必须被删除掉。有一个重要的例外就是该表空间是正常脱机的或者只读的，表空间的数据文件头中的检查点SCN都保存在TS$中，即表空间干净结束 SCN（见2.17）。只要数据文件不是“模糊的”且是在表空间干净结束SCN处做的检查点，在将数据文件联机时是不需要重做日志的。此时脱机文件头部的重置数据被忽略。因此在重做日志之前正常脱机的表空间是不受它脱机期间的重做日志操作影响的。

 

8.7  重置日志打开数据库时对数据字典和控制文件的检查

重做日志打开数据库后，数据字典FILE$中记录的数据文件会跟控制文件中记录的数据文件进行对比。这个操作在用CREATE CONTROLFILE命令后的第一次打开数据库也会进行的。不完全恢复结束的时侯数据库中的数据文件可能跟用来恢复的控制文件中记录数据文件不一致。使用备份的控制文件或者创建一个控制文件都有同样的问题。检查数据字典没有什么危害，因此每次数据库打开的时候都会做。不过正常情形下也要花时间去做没有什么道理。

FILE$中数据文件的入口会跟控制文件中每个数据文件号进行比较。因为FILE$反映的是数据库中的空间分配信息，它是正确的，控制文件中可能不对。如果FILE$中不存在的而控制文件中存在的数据文件将会从控制文件中清除掉。

如果一个数据文件在FILE$中存在而在控制文件中不存在，则会在控制文件中创建一个记录占位，记录在名字MISSINGnnnn下（MISSINGnnnn中nnnn是十进制形式的文件号）。MISSINGnnnn在控制文件中用来表示被脱机的文件和需要介质恢复的文件。实际文件可以通过将MISSINGnnnn重命名为实际文件名的途径来访问。

在重置打开的时候，重命名MISSINGnnnn能够访问实际数据文件的前提是该数据文件是只读的或者正常脱机的。换句话说如果重命名MISSINGnnnn为一个不是正常脱机或只读的数据文件，并不能使得该数据文件可以访问，因为它还需要重置打开数据库前的重做日志来进行介质恢复。如果是这样，这个表空间就得被删除了。

如果是因为执行了CREATE CONTROLFILE...NORESETLOGS后打开数据库时进行数据字典检查而不是因为重置打开数据库的话，需要介质恢复将该数据文件更新到最新状态。

另外一个步骤就是重复上面操作使控制文件中的数据文件记录跟数据字典中的一致。对不完全恢复而言，这个就要求还原所有的备份再重新恢复了。

 

 

 

继第九章 Oracle恢复内部原理（恢复相关的 V$ 视图）

**********本博客所有内容均为原创，如有转载请注明作者和出处!!!**********
Name:    guoyJoe

QQ:      252803295

Email:    oracledba_cn@hotmail.com

Blog:      http://blog.csdn.net/guoyJoe

ITPUB:   http://www.itpub.net/space-uid-28460966.html

OCM:    http://education.oracle.com/education/otn/YGuo.HTM
_____________________________________________________________
加群验证问题：哪些SGA结构是必需的，哪些是可选的？否则拒绝申请!!!

答案在：http://blog.csdn.net/guoyjoe/article/details/8624392

DSI&Core Search（QQ群）:127149411