1．        系统SCN号
查询系统SCN号的方法：
select dbms_flashback.get_system_change_number from dual
commit后系统SCN号会增长，但是即使没有commit操作，因为有许多后台进程在运行，所以系统SCN号也会增长。
2．        检查点SCN
有4种检查点SCN，其中除了文件头中的启动SCN外，其他三种保存在控制文件中。可以通过：alter system set events ‘immediate trace name controlf level 10’导出控制文件到udump目录的跟踪文件，来查看控制文件的内容。
1)        系统检查点SCN(区别于上面的系统SCN，chekpoint发出后这些SCN号才受影响，如发出：alter system checkpoint),当一个检查点动作完成后，Oracle就把系统检查点的SCN存储到控制文件中，查询方法：
Select checkpoint_change# from v$database
2)        数据文件检查点SCN
当一个检查点动作完成后，Oracle就把每个数据文件的SCN号单独存放在控制文件中，查询方法：
Select checkpoint_change# from v$datafile
3)        文件头中的启动SCN
Oracle把这个检查点的SCN号存储在每一个数据文件的文件头中。主要用于数据库实例启动时，检查是否需要执行数据库恢复。查询方法：
Select name,chekpoint_change# from v$datafile_header
4)        终止SCN
每个数据文件的SCN号都存储在控制文件中，查询方法：
Select name,last_change# from v$datafile
在正常的数据库操作过程中，所有处于联机读写模式下的数据文件的终止SCN都为NULL。
3．        几个检查点SCN号的关系
1)        几个检查点SCN都相同：在数据库打开并运行之后，控制文件中的系统检查点SCN、控制文件中的数据文件检查点SCN及每个数据文件头中的启动SCN都是相同的，控制文件中的每个数据文件的终止SCN都是NULL。
2)        数据库正常关闭时，系统会执行一个检查点动作，这时所有数据文件的 终止SCN号会设置为数据文件头的那个启动SCN。数据库重新启动时，Oracle将数据文件头中的启动SCN与数据文件检查点SCN比较，如果这两个值匹配，Oracle接下来再比较数据文件头中的SCN和控制文件中数据文件的终止SCN，如果这个值也匹配，就意味着所有数据块已经提交，因此数据库不需要进行恢复，此时数据库直接打开。当所有的数据文件都打开之后，终止SCN再次被设置为NULL，表示数据文件已经打开并能够正常使用了。
3)        数据库非正常关闭(或称为实例崩溃)时，终止SCN不会被设置，依然为NULL，这可以通过把数据库启动至mount状态查询出来。这样Oracle通过这个信息就可以知道实例上次运行时崩溃了，检查点没有执行。这样重新启动时，Oracle会执行实例恢复工作，即先执行前滚、回滚操作，再把数据库打开。
4)        数据文件检查点SCN及系统检查点SCN比文件头启动SCN大：这时的情况是：系统发生介质故障，数据文件被以前的备份代替，控制文件中的数据文件检查点SCN肯定比文件头中的启动SCN要大，这样Oracle就知道要对这个文件进行介质恢复。这时要通过下面语句恢复数据库：
recover database ……
5)        系统检查点SCN比数据文件SCN及文件头启动SCN大：
有些表空间是只读的，这时控制文件中的系统检查点SCN号会不断增长，而数据文件SCN号和文件头中的启动SCN号会停止更新(直到表空间又设置为可读写)，显然这时系统检查点SCN号会大于数据文件SCN和文件头启动SCN。
6)        系统检查点SCN及数据文件SCN比文件头启动SCN小：
在数据库恢复时，控制文件可能不是最新的，即把一个较早的控制文件还原为当前的控制文件，然后再执行恢复操作，这时控制文件中的系统检查点SCN和数据文件SCN可能比文件头的启动SCN小。这时恢复数据库要用下面命令：
recover database using Backup Controlfile或其他的恢复语句