Scn：又叫作系统变更号，可以作为oracle系统内部的一个时钟。
一、Scn的分类：
根据scn位于的位置不同，可以分为以下几种：
1． 存在控制文件中的
A 系统scn
B 每个数据文件的scn
C 每个数据文件的终止scn （stop scn）
2． 存在数据文件头的 启动scn （start scn）
二、获得这些scn号的方法或者语句
1． 系统scn号的获得
select checkpint_change# from v$database;
2． 数据文件scn与终止scn的获得
select name,checkpoint_change#,last_change# from v$datafile where name like ‘’;
3． 启动scn的获得
select name,checkpoint_change# from v$datafile_header where name like ‘’;
三、scn与恢复的关系
在数据库正常运行的时候，控制文件里记录的每个数据文件的终止scn是null。
正常shutdown的时候，系统执行一个ckpt，然后所有db file的终止scn都被设置成等于数据文件头的启动scn；
重启之后，系统将数据文件头的启动scn与控制文件的数据文件scn比较。
不相同 ： media recovery
相同：继续比较启动scn与控制文件数据文件的终止scn
相同：启动成功
不同：instance recovery
四、一般的例子：
create table t…
然后 insert into t… 但是不commit ,shutdown abort
接着mount数据库
select checkpoint_change# from v$database; 比如 12345
select name,heckpoint_change#,last_change# from v$datafile;
发现数据文件的scn为12345 ，而数据文件的scn为null
再查发现数据文件头的启动scn也为12345 所以现在需要进行的就是instance recovery
media recoery的例子就不举了
五、 wrap-up或者说注意：
系统scn与数据文件scn一般一直相等，在8i以前，也与start scn一直相等，但由于checkpoint queue的出现，checkpoint机制发生了变化，不再是事件驱动的checkpoint了，而是根据checkpoint queue来进行checkpoint的驱动。所以可能在数据库的运行过程中出现数据文件头启动scn与上面两个的不相同，这个并不要紧。
另外还要注意的是：既然系统scn与数据文件的scn一直相等，为什么还要保留数据文件scn，这不是浪费么？因为可能出现数据文件的read only
