原文转载自：https://blog.csdn.net/JackieLiuLixi/article/details/17140659
1.SCN（System Change Number）作为oracle中的一个重要机制，在数据恢复、Data Guard、Streams复制、RAC节点间的同步等各个功能中起着重要作用。
2. 在理解SCN之前，我们先看一下oracle事务中的数据变化是如何写入数据文件中的：
1. 事务开始；
2. 在buffer cache中找到需要的数据块，如果没有找到，则从数据文件中载入buffer cache中；
3. 事务修改buffer cache的数据块，该数据被标识为“脏数据”，并写入log buffer中；
4. 事务提交，LGWR进程将log buffer中的“脏数据”写入redo log file中；
5. 当发生checkpoint，CKPT进程更新所有数据文件的文件头中信息，DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。
3. SCN是一个只会增加、不会减少的数字，它是由当时的timestamp转换过来的。每当需要产生一个新的SCN到redo记录时，系统获取当时的timestamp，并将其转换未数字作为SCN。
4. 一共有4种SCN。系统检查点（System Checkpoint）SCN、数据文件检查点（Datafile Checkpoint）SCN、结束SCN（Stop SCN）以及开始SCN（Start SCN）。其中前面三个存在于控制文件中，最后一个存在于数据文件中。
5. 在控制文件中，System Checkpoint SCN是针对整个数据库全局的，因此该SCN只有一个。而Datafile Checkpoint SCN以及Stop SCN是对于每个数据文件的，因此存在多个。在数据库正常运行期间，Stop SCN是一个无穷大或者说是NULL，当数据库正常结束时，系统会自动进行一次checkpoint，保持Stop SCN与其他三个SCN保持一致（即都为最新的Next SCN）。但是如果是宕机等异常情况，则Stop SCN与Start SCN不一致，这样就可以判断数据库是否需要修复。
6. 在一个事务提交后（上述第四个步骤）会在redo log中存在一条redo记录，同时，系统为其提供一个最新的SCN记录在该条记录中，如果该条记录再redo log被清空（日志满做切换时或发生checkpoint时，所有变化日志已经被写入数据文件中），则其SCN被记录为redo log的low SCN，以后在日志再次被清空前写入的redo记录中的SCN则成为Next SCN。
7. 当日志切换或者发生checkpoint（上述第五个步骤）时，从Low SCN到Next SCN之间所有redo记录的数据就被DBWn进程写入数据文件中，而CKPT进程则将所有数据文件（无论redo log中的数据是否影响该数据文件）的文件头上记录的Start SCN更新为Next SCN，同时将控制文件中的System Checkpoint SCN、每个数据文件对应的Datafile Checkpoint更新为Next SCN。但是如果该数据文件被设置成了read-only时，数据文件的Start SCN和控制文件中Datafile Checkpoint SCN都不更新。
8. 当数据库启动时，Oracle先检查控制文件中的每个Datafile Checkpoint SCN和数据文件中的Start SCN是否相同，再检查每个Datafile Checkpoint SCN和Stop SCN是否相同。如果发现不同，就从Redo log中找到丢失的SCN，重新写入数据文件中进行恢复。
9. 如果打开数据库时发现 system scn>datafile scn，那么以为着使用旧的备份数据文件，也就是需要介质恢复
如果是 system scn<datafile scn，及控制文件 scn 是旧的，代表使用了老的控制文件，需要 recover using backup controlfile 进行恢复。