scn：systemchangenumberscn是oracle数据库的一个逻辑的内部时间戳，用以标识数据库在某个确切时刻提交的版本。在事务提交或回滚时，它被赋予一个惟一的标识事务
scn：system change number
scn是oracle数据库的一个逻辑的内部时间戳，用以标识数据库在某个确切时刻提交的版本。在事务提交或回滚时，它被赋予一个惟一的标识事务的scn，香港虚拟主机，用来保证数据库的一致性。
sql> select dbms_flashback.get_system_change_number, scn_to_timestamp(dbms_flashback.get_system_change_number) from dual;get_system_change_number scn_to_timestamp(dbms_flashback.get_system_change_number)------------------------ -------------------------------------------------------1819076 06-jul-13 11.40.12.000000000 pmsql>select current_scn from v$database;current_scn-----------1819065
scn在数据库中是无处不在的，美国空间，常见的控制文件、数据文件头部、日志文件等都记录有scn。
控制文件中
系统检查点scn(system checkpoint scn)
sql> select checkpoint_change# from v$database;checkpoint_change#------------------1809219文件检查点scn(datafile checkpoint scn)
文件结束scn(stop scn)
sql> select name,checkpoint_change#,last_change# from v$datafile;namecheckpoint_change# last_change#--------------------------------------------- ------------------ ------------+data/orcl/datafile/system.256.8173432291809219+data/orcl/datafile/sysaux.257.8173432311809219+data/orcl/datafile/undotbs1.258.8173432311809219+data/orcl/datafile/users.259.8173432311809219+data/orcl/datafile/example.265.8173435431809219
数据文件头部
开始scn(start scn)
sql> select checkpoint_change# from v$datafile_header;checkpoint_change#------------------18092191809219180921918092191809219
日志文件中
first scn：redo log file中第一条日志的scn
next scn：redo log file中最后一条日志的scn(即下一个redo log file的第一条日志的scn)
通常,只有当前的重做日志文件组写满后才发生日志切换,但是可以通过设置参数archive_log_target控制日志切换的时间间隔,在必要时也可以采用手工强制进行日志切换.
一组redo log file写满后，会自动切换到下一组redo log file。上一组redo log的high scn就是下一组redo log的low scn,且对于current日志文件的high scn为无穷大(ffffffff)。
sql> select group#,sequence#,status,first_change#,next_change# from v$log;group# sequence# statusfirst_change#next_change#---------- ---------- ---------------- ------------- ------------------134 inactive17465721770739235 inactive17707391808596336 current1808596 281474976710655
实例崩溃恢复：
在open数据库时,oracle通过控制文件进行了以下验证：
检查数据文件头部所记录的start scn 和控制文件中所记录的system checkpoint scn 是否一致,若不同则需要进行介质恢复
检查数据文件头部所记录的start scn 和控制文件中记录的stop scn是否也一致,若不同则需要进行实例恢复.
如果两个都一致了,说明所有已被修改的数据块已经写入到了数据文件中,才可以正常open,
当数据库open并正常运行期间,系统scn、文件scn和数据文件头部的开始scn都是一致的,且(大于或)等于active/current日志文件的最小first scn,但文件结束scn为null(无穷大);
当数据库正常关闭时,oracle通过完全检查点将buffer cache中的所有缓存写到磁盘上,同时根据关闭数据库的时间点更新控制文件中的系统scn、文件scn、结束scn和数据文件头部中的开始scn,且scn都是一致的,且lrba指针指向on disk rba,否则需要前滚;
当数据库非正常关闭(崩溃/掉电)后启动实例时,oracle将检测到控制文件中的系统scn、文件scn和数据文件头部的开始scn都是一致的,但是结束scn为null,则在需要参与实例崩溃恢复的redo log file中根据控制文件中记录的lrba地址(前滚起点)和on disk rba(前滚终点)地址找出相应的日志项进行实例崩溃恢复,最终才可将数据库open.
实例恢复的详细过程：
前滚阶段(前滚靠redo,又叫缓冲区恢复cache recovery,即负责恢复已经在内存中但还没有写入数据文件中的内容)
     oracle是按照redo log file的记录来前滚的(不管有没有commit),所以前滚完成后,data file中可能会有没有提交的数据(所以需要后面的回退过程).
     另外,由于undo的生成也是要记录redo log的,所以还会按照redo重新生成后面回退时需要的undo信息.
数据库open阶段
     前滚完毕后,数据库中所有已被修改的数据块已经写入到了数据文件中才可以正常open
回滚阶段(回滚靠undo,又叫事务恢复transaction recoery,即负责回退实例崩溃前没有提交的事务)
正常关闭数据库时：
系统scn、文件scn、结束scn和数据文件头部中的开始scn都是相等的，美国服务器，且(大于或)等于active/current日志文件中的最小first scn
sql> shutdown immediatedatabase closed.database dismounted.oracle instance shut down.sql> startup mountoracle instance started.total system global area 459304960 bytesfixed size2214336 bytesvariable size289408576 bytesdatabase buffers159383552 bytesredo buffers8298496 bytesdatabase mounted.sql> select checkpoint_change# from v$database;checkpoint_change#------------------1822573sql> select name,checkpoint_change#,last_change# from v$datafile;namecheckpoint_change# last_change#--------------------------------------------- ------------------ ------------+data/orcl/datafile/system.256.81734322918225731822573+data/orcl/datafile/sysaux.257.81734323118225731822573+data/orcl/datafile/undotbs1.258.81734323118225731822573+data/orcl/datafile/users.259.81734323118225731822573+data/orcl/datafile/example.265.81734354318225731822573sql> select name,checkpoint_change# from v$datafile_header;namecheckpoint_change#--------------------------------------------- ------------------+data/orcl/datafile/system.256.8173432291822573+data/orcl/datafile/sysaux.257.8173432311822573+data/orcl/datafile/undotbs1.258.8173432311822573+data/orcl/datafile/users.259.8173432311822573+data/orcl/datafile/example.265.8173435431822573sql> select group#,sequence#,status,first_change#,next_change# from v$log;group# sequence# statusfirst_change#next_change#---------- ---------- ---------------- ------------- ------------------137 current1822207 281474976710655336 inactive18085961822207235 inactive17707391808596正常open数据库时：