恢复相关的各种SCN及在恢复中的关系

摘自：http://space.itpub.net/35489/viewspace-694069

数据库系统的当前SCN，是一直在变化的，其变动因素包括事务的提交与回滚，以及每三秒一次的心跳。

而涉及到数据库启动关闭时检查的SCN有四种，其中三种记录在控制文件中：系统SCN、datafile SCN、stop SCN，另一种是记录在各个数据文件头中的start SCN。

其中，数据文件头的start SCN来自系统当前SCN，而控制文件的系统SCN来自系统当前SCN，datafile SCN来自读取各个数据文件头已经改写好的start SCN，stop SCN在数据库启动后一直为NULL，而正常关闭时会被置为系统当前SCN。 数据库正常关闭的时候，会在执行完所有事务后，执行一次完全checkpoint事件，将数据文件头上的start SCN，以及控制文件中记录的三种SCN：系统SCN、datafile SCN、stop SCN，都置为系统当前的SCN。

数据库再次启动时，首先检查数据文件头的start SCN，是否与控件文件记录的系统SCN和datafile SCN相同，如果三者之一有不相同则要进行media recovery。

然后再检查控制文件中的stop SCN，是否与数据文件头当中的start SCN相同，如果相同，表明上次是正常关闭，这时SCN检查通过。数据库系统正常启动后stop SCN会被置为NULL；如果非正常重启数据库时stop SCN是NULL，这时表明上次没有正常关闭（即没有执行checkpoint将stop SCN置为关时的系统SCN），那么需要进行instance recovery。

我们可以看到，这个检查过程中，不包括redo log的SCN检查。涉及用到redo log的SCN的时候，是当系统需要进行media recovery的时候。

如果是用noresetlogs进行完全恢复，它将使用redo log当中的SCN，作为最新的SCN，然后将这个SCN值写入到控制文件和数据文件的上面几种SCN中。

如果是用resetlogs进行不完全恢复，将控制文件当中的系统SCN设为0，将控制文件当中的SCN和数据文件头的start SCN设为冷备份当中的数据文件头的SCN，这时也不需要用到redo log的SCN。

数据库启动时，是不检查redo log的SCN的,只有在media recovery中使用noresetlogs进行完全恢复时才会将redo log的SCN写入控制文件及数据文件的各种SCN(一般使用noresetlogs时redo log文件都是完好的).

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23862439/viewspace-1058034/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23862439/viewspace-1058034/