对ORACLE SCN的理解

1、SCN数值实际来源于系统的timestamp，这个实际可以证明
select current_scn from v$database;
select timestamp_to_scn(sysdate) from dual;
这两个数值是完全一样的。
2、在数据库关闭和启动的过程中，在关闭的时候，用系统SCN同步了数据文件头SCN和控制文件SCN，在启动的过程中，数据库文件头SCN和控制文件SCN还有START SCN和STOP SCN，这些是用来控制数据库是否在启动的时候，需要继续介质恢复，但是启动完成之后，第一个系统SCN，我判断应该是有TIMETASMP生成出来的，因为这第一个SCN，比启动之后的数据文件头SCN多了很多，一个空闲数据库在关闭15分钟之后，启动之后，第一个SCN和数据文件头SCN，数值相差500多，说明系统启动之后，系统SCN是通过TIMESTAMP来的，而不是继承上一次关闭的SCN。
3、经过实际检测发现，用来修改checkpoint scn的CKPT进程，应该有3个触发条件：1是手动，alter system checkpoint，2是由日志切换触发，手动或者自动切换重做日志，均会触发CKPT进程运行，3是数据库干净重启，将控制文件、数据文件头、系统的checkpoint scn进行同步。
一个保持7*24小时长时间运行的数据库，checkpoint scn的改变频率，是和在线日志大小及业务量有关的，改变频率等于在线日志的切换频率，在线日志小而且业务量大，那么checkpoint的改变频率就快。但是从整个数据库4个SCN看起来，改变频率最慢的还是checkpoint scn，其他的改变频率都要比这个快。
在v$database中，有两个相似的scn，分别是archive_change#和archivelog_change#，archivelog_change#是当前日志的开始SCN，也是当前的checkpoint scn，而archive_change#，却是上一个日志的开始scn，这个看起来有点奇怪，仔细想想，用处还比较大，archive_change#，确实应该是之前的checkpoint scn，确切的描述应该是上上次的checkpoint scn，正确的描述应该是当前日志的上一个日志的开始SCN，所以可以说是上上次的checkpoint scn，那么用途是什么呢，用途应该是两个，一个是这个scn之前的日志要强制归档，也就是说，在3个日志模式中，当前日志的下一个日志，比如当前日志是redo02，那么下一个日志就是redo03，这个redo03，在未归档之前，其实就是archive_change#之前的日志，这个说法就很明确了，也说明了为什么数据库必须确保3个日志，2个日志不行，因为当前日志无法归档，上一个日志可以延后归档，数据库设定上上一个日志要强制归档，那么当前日志、上一个日志、上上个日志，当然要全部存在，才好做了。这里又引申出来，这样archive_change#的第二个用途，从之前的描述可以看出，当前日志肯定无法归档，同时上一个日志也可以没有被归档，这是为了减低磁盘IO压力，做的异步归档，上一个日志是一个延后归档，那么在当前日志刚切换，上一个日志还没有归档的时候，数据库出现问题，需要恢复，怎么办，archive_change#，就可以非常方便查出需要检查是否恢复的大概范围。这样做，好像看起来有点多余，但是这应该是数据安全的另外一层保障机制。oracle数据库强调的就是数据安全。

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