Oracle的resetlogs机制浅析

原文地址：http://blog.csdn.net/wyzxg/archive/2010/09/07/5869543.aspx

           http://space.itpub.net/16628454

alter database open resetlogs 这个命令我想大家都很熟悉了，那有没有想过这个resetlogs选项为什么要用？什么时候用？它的原理机制是什么？他都起哪些作用？

我们都知道数据在启动时候是要做一致性检查的，oracle在open阶段要做两次检查

1. 检查数据文件头的检查点计数（checkpoint cnt）是否和控制文件的检查点计数（checkpoint cnt）一致。目的是确认数据文件是否来自同一版本，而不是从备份中恢复的。如果这一步检查通过，就进行第二步检查

2. 检查数据文件头的开始scn和控制文件中记录该文件的结束scn是否一致。如果数据文件头的开始scn和控制文件中该文件的结束scn相等，那说明这个数据文件就不需要恢复，否则就要恢复文件

 如果以上两步检查都通过，那就可以正常打开数据库，锁定数据文件，同时将控制文件中每个数据文件的结束scn设置无穷大。我们在某些条件下打开数 据，会提示让用resetlogs选项open数据库，为什么要用resetlogs呢？它是干嘛用的呢？问号一大堆了吧，下面来具体分析下。

 resetlogs的作用

 防止陈旧的数据进入数据库（保证数据库的一致性），这也就是为什么在resetlogs打开数据库，一定要立即对数据库做个全备。
 在控制文件，data file header，redo log header里存储”resetlogs data“，当open resetlogs被执行时，可以通过这些内容检查一致性。

什么时候用resetlogs

1. 不完全恢复
2. 用备份的控制文件恢复
3. 新创建的控制文件来恢复

resetlogs的原理机制

resetlogs是如何来保证打开数据库是一致的呢？

1）在open resetlogs时，oracle要对比检查控制文件和数据字典file$,如果一个数据文件在file$中存在，但在控制文件中不存在，那在控制文件 中将创建一个这个文件条目（MISSINGnnn ‘nnn’是十进制的file_id）,同时这个文件被标记为离线并需要恢复。如果实际中这个文件存在的话，可以通过如下sql更改到正确的文件名。

   sql> alter database rename file 'MISSINGnnn' to ''；

   然后数据文件被恢复，online。

2）如果一个数据文件存在控制文件中，而不在数据字典file$中，那么直接把控制文件中这个文件的记录条目删除（oracle认为file$文件是正确的，要以它为准）

3）当用旧的备份控制文件恢复的时候，如果有数据文件不在控制文件中注册（会提示控制文件比较旧的错误），那就不得不重建数据文件，以使数据文件注册到控制文件中，然后系统会自动利用redo/archivelog恢复这个数据文件。

在保证控制文件和file$文件内容一致之后，oracle还有做如下检查才能open resetlogs

4）数据文件的版本要小于当前数据库的版本（counter）

5）offline的数据文件必须被online或者直接drop

6）所有的数据文件不能设置fuzzy bit，所有的数据文件要有相同的检查点（checkpoint SCN）

到目前为止，open resetlogs的前提条件都已经满足，resetlogs究竟做了哪些工作呢？（重新使用redo log）

1）所有的online logfile 的信息重新被放置在控制文件中。并且还要为有效的thread挑选一个logfile文件作为current logfile

2）log header被更新为log seq#

3）所有的online的数据文件头被新的checkpoint和新的‘resetlogs data’更新，offline的数据文件被标记为需要媒体恢复。

resetlogs data：当前的scn和counter被称作”resetlogs data“

如果oracle数据库一致性检查失败的，那数据库是不允许被open的，即 open resetlogs不成功。但也不是绝对不能open，可以通过隐含参数“_allow_resetlogs_curruption”,绕过oracle 的一致性检查，但这样会引起数据库的不一致（文件可能有不同的scn或有fuzzy bit设置），如果open后，数据库一定要rebuild （建议ANALYZE TABLE ...VALIDATE  STRUCTURE  CASCADE;或者imp/exp ）

来自于itpub的一篇文章：http://space.itpub.net/16628454

很多人说，resetlogs就是不完全恢复，这是不对的，做不完全恢复必须使用 resetlogs，但resetlogs也可以做完全恢复。而noresetlogs则是必须做完全恢复时使用。resetlogs会重置日志序列号强 制清空或重建REDO，而noresetlogs则不会这么做。

第一种情况，我们假设仅仅控制文件丢失，而其他文件没有丢失（主要是归档和 REDO），那么恢复的时候如果选择从备份中恢复控制文件。恢复后，控制文件会去读数据文件头中与CHECKPOINT SCN对应的RBA信息来确定从那个序列的归档日志开始恢复，一直推进恢复到NEXT SCN是无穷大的那个REDOLOG，此时恢复是完全恢复的，但打开的时候还要以resetlogs方式打开，这样要重置归档日志的sequence，也 就是说，如果你恢复时使用了备份控制文件，那么打开数据库时必然是要resetlogs的。 

第二种情况，不完全恢复，不管你是要什么样的不完全恢复，SCN，TIME，跨越REDO，都必须使用resetlogs。

第三种情况，丢失REDOLOG，这就更需要resetlogs了，因为 resetlogs能够重建REDOLOG。如果你的REDOLOG、控制文件、数据文件丢失的话，需要先恢复控制文件，然后restore database;recover database;alter database open resetlogs;注意，这时候做的是不完全恢复，因为REDO没有了。在recover过程中可能会报错然后自动退出RMAN，无视，alter database open resetlogs即可。

    第四种情况，没有丢失控制文件及各种日志，仅丢失数据文件，这种问题比较常见，有可能 磁盘损坏造成数据文件丢失，等磁盘故障排除后，需要恢复，此时的恢复就很简单了，restore database;recover database;alter database open;就一切OK，也就是说，在不使用备份控制文件恢复的情况下，是可以使用noresetlog方式打开数据库的。前提有一，不能丢失日志文件。假 若丢失了控制文件和数据文件但还是想以noresetlog打开的话，就必须手动以noresetlogs方式重建控制文件，而且REDOLOG的状态都 必须正常，否则是无法使用noresetlogs方式打开。