①在数据库打开并运行之后，控制文件中的系统检查点scn、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的      ②控制文件中的每个数据文件的终止scn都为null     ③NORMAL或IMMEDIATE 关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn 都会设置成数据文件头中的那个启动scn的值。     ④在数据库重新启动的时，Oracle将执行两次检查       ◆ 看数据文件头中的ckpt计数器是否与对应控制文件中的ckpt计数器一致。若相等，进行第二次检查       ◆ 比较文件头中的启动scn和对应控制文件中的终止scn进行比较，如果终止scn等于启动scn，则不需要对那个文件进行恢复     ⑤数据库打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了     注：当ABORT强制关闭数据库时不进行检查点处理，所以终止scn仍然为无穷大。在下次启动期间，发现启动scn和终止scn不同，需要进行线程恢复。    3、SCN的增加     ①SCN(System Change Number)只要数据库被修改，就会+1，而不是一定要进行checkpoint，例如DML的发生即使没有提交也会使SCN+1     注：SCN增加并不代表会在数据文件头中表现出来，而是需要等到checkpoint执行后才写入(当然可能已经增加了很多)     ②如果一个DML导致产生事务，则会产生一个SCN。这个意思是说如果一个事务包含多个dml，则只有第一个初始产生事务的dml产生scn，提交的时候又是一个scn，如果一个事务只有一个dml，拿看起来就是dml产生一个scn，提交或者回滚产生一个scn。     ③Oracle 10g内部的SCN会默认不管有没有动作，每隔3s自动增加一次。其他需要增加的情况则再加。     ④只有ckpt进程才会修改文件头中的checkpoint计数器和SCN，DBWR只会修改数据块，即ckpt通知dbwr写数据文件，写完之后ckpt更新控制文件和数据文件头。此时若DBWR发现数据块的log block还没有被写入日志文件，则在dbwr写块之前通知llgwr把log buffer中的日志写入log文件。     注：总结一下，日志切换必定出发ckpt，但ckpt不一定会出发llgwr，但是一定会触发dbwr4、其他的SCN     ①日志文件头中包含了Low scn、Next scn，表示给日志文件包含有从Low scn到Next scn的redo record     注：当系统运行时，日志文件的Next scn同样为无穷大。而且需要注意：在恢复时不是用日志文件中的Low scn和Next scn来选择恢复的日志文件，而是通过数据文件头中的信息。     ②数据块中的SCN   data block里面的SCN是当block被更改的时候的SCN，而数据文件有那么多 block，自然不同的block有不同的SCN，block中存在block SCN和ITL中的commit SCN。block SCN 又在块头和块位都有，若不一致意味着block损坏。而ITL中的commit SCN则跟consistent gets and delay block cleanout有关。
   ③v$database中的checkpoint_change# 和 dbms_flashback.get_system_change_number 不同。前者是作为数据库的最后一次checkpoint是的SCN，而后者是系统的最新SCN，所以一般后者都会比前者大，而当刚做完checkpoint时两者会差不多。     ④当begin backup命令发出后，相关数据文件的checkpoint scn被冻结(以及状态标志被改变)，其他一切照旧。例如：日志切换时checkpoint count正常递增/检查点照常写文件，自然文件中的数据块内的各种scn也照常递增。    不登高山，怎知天高；不临深溪，焉知地厚！站在坚实的土地上，做着生命中最真实的事情；像一棵挺拔的大树，认可自己的命运并敢于迎接属于这一方天空的风风雨雨。
网页题目：SCN的工作机制-创新互联
URL链接：http://chengdu.cdxwcx.cn/article/dejpsc.html