一、各种scn简介：如图，控制文件中有系统scn号，针对每个数据文件还有文件scn号、结束scn号（如四个数据文件就有4个对应的文件scn号、结束scn号）数据文件头部
一、各种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则是关闭数据库时候更新的。