摘自：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博客 ” ，链接：https://blog.itpub.net/23862439/viewspace-1058034/ ，如需转载，请注明出处，否则将追究法律责任。
