一、各种SCN简介：
如图，控制文件中有系统SCN号，针对每个数据文件还有文件SCN号、结束SCN号（如四个数据文件就有4个对应的文件SCN号、结束SCN号）
数据文件头部有开始SCN号。都是为了保证数据文件的一致性
正常情况下：系统SCN、文件SCN、文件头部的开始SCN应该一样，结束SCN为null
系统SCN：
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
617242
文件SCN：
SQL> select name,checkpoint_change# from v$datafile;
NAME CHECKPOINT_CHANGE#
-------------------------------------------------- ------------------
/u01/app/oracle/oradata/jiagulun/system01.dbf 617242
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 617242
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 617242
/u01/app/oracle/oradata/jiagulun/users01.dbf 617242
/u01/app/oracle/oradata/jiagulun/example01.dbf 617242
/u01/app/oracle/oradata/jiagulun/data1_01_dbf 617242
结束SCN：
SQL> select name,last_change# from v$datafile;
NAME LAST_CHANGE#
-------------------------------------------------- ------------
/u01/app/oracle/oradata/jiagulun/system01.dbf
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf
/u01/app/oracle/oradata/jiagulun/users01.dbf
/u01/app/oracle/oradata/jiagulun/example01.dbf
/u01/app/oracle/oradata/jiagulun/data1_01_dbf
数据文件头部开始SCN：
SQL> select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#
-------------------------------------------------- ------------------
/u01/app/oracle/oradata/jiagulun/system01.dbf 617242
/u01/app/oracle/oradata/jiagulun/undotbs01.dbf 617242
/u01/app/oracle/oradata/jiagulun/sysaux01.dbf 617242
/u01/app/oracle/oradata/jiagulun/users01.dbf 617242
/u01/app/oracle/oradata/jiagulun/example01.dbf 617242
/u01/app/oracle/oradata/jiagulun/data1_01_dbf 617242
每一条日志都有SCN，每个日志组文件的头部有两个SCN first SCN和next SCN
first SCN：即这个文件组中第一条日志的SCN，等于上一组的next SCN。
next SCN：即这个文件组中最后一条日志的SCN，等于下一组的first SCN。
二、SCN如何保证数据库文件一致性（如何确认需要恢复）？
正常关闭：将所有buffer cache脏块写到磁盘，同时更新系统SCN、文件SCN，数据头部开始SCN，同时结束SCN写上与系统SCN、文件SCN、数据头部开始SCN都一样的时间点（关闭时间）
非正常关闭：结束SCN为null，未正常写上。开启数据库时检测到结束SCN为null，则需要实例恢复。
数据文件丢失：例如当1号DBF文件丢失了，从备份中拷贝一个备份的1号DBF文件过来，此时文件头部的SCN比较旧，与控制文件系统SCN号对比，oracle则发现需要做恢复。则用跑日志将其SCN跑到与控制文件中文件SCN一样。
控制文件丢失：控制文件和数据文件都换成旧的，此时光对比控制文件中的SCN号和数据文件头部的SCN号还不能确认需不需要恢复，oracle还要对比on disk rba scn，如果on disk rba scn比控制文件中的SCN号和数据文件头部的SCN号都新，则要实例恢复。
用SCN号确认使用哪些日志组来恢复实例：
目前系统SCN号为617242：
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
617242
此时日志组1first SCN为617242，则需要日志组1恢复即可；
试着经过两次日志组切换：
SQL> alter system switch logfile;
System altered.
SQL> alter system switch logfile;
System altered.
此时系统当前最新的文件SCN仍然是617242
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
617242
那么这时候数据库实例崩溃使用哪些日志组恢复呢？
此时617242在日志组1，按照序列号8-10，日志组3是最新日志，此时需要日志组1、2、3恢复。
日志中active代表组中存在日志对应的脏块还没有写到磁盘中。
执行
SQL> alter system flush buffer_cache;
System altered.
后，日志组active变为inactive：
而此时控制文件中的SCN也更新为：
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
628825
此时如果数据库实例非正常关闭，则需要日志组3来恢复。
三、总结：
控制文件中系统SCN,文件SCN等于最旧的active日志文件组的first SCN，实例恢复需要active和current日志组。
控制文件中的系统SCN,文件SCN用于确认数据恢复的所需要的重做日志文件组。
确认文件组后根据控制文件中的LRBA地址去跑日志跑到on disk rba地址。
CKPT进程只是将LRBA地址写到控制文件中，而控制文件中的系统SCN，文件SCN和数据头部SCN的更新是当一个日志组由active变为inactive时更新的，结束SCN则是关闭数据库时候更新的。
