SCN（System Chang Number）作为oracle中的一个重要机制在数据恢复Data GuardStreams复制RAC节点间的同步等各个功能中起着重要作用理解SCN的运作机制可以帮助你更加深入地了解上述功能
在理解SCN之前我们先看下oracle事务中的数据变化是如何写入数据文件的
事务开始
在buffer cache中找到需要的数据块如果没有找到则从数据文件中载入buffer cache中
事务修改buffer cache的数据块该数据被标识为髒数据并被写入log buffer中
事务提交LGWR进程将log buffer中的髒数据写入redo log file中
当发生checkpointCKPT进程更新所有数据文件的文件头中的信息DBWn进程则负责将Buffer Cache中的髒数据写入到数据文件中
经过上述个步骤事务中的数据变化最终被写入到数据文件中但是一旦在上述中间环节时数据库意外宕机了在重新启动时如何知道哪些数据已经写入数据文件哪些没有写呢（同样在DGstreams中也存在类似疑问redo log中哪些是上一次同步已经复制过的数据哪些没有）？SCN机制就能比较完善的解决上述问题
SCN是一个数字确切的说是一个只会增加不会减少的数字正是它这种只会增加的特性确保了Oracle知道哪些应该被恢复哪些应该被复制
总共有中SCN系统检查点（System Checkpoint）SCN数据文件检查点（Datafile Checkpoint）SCN结束SCN（Stop SCN）开始SCN（Start SCN）其中其面中SCN存在于控制文件中最后一种则存在于数据文件的文件头中
在控制文件中System Checkpoint SCN是针对整个数据库全局的因而之存在一个而Datafile Checkpoint SCN和Stop SCN是针对每个数据文件的因而一个数据文件就对应在控制文件中存在一份Datafile Checkpoint SCN和Stop SCN在数据库正常运行期间Stop SCN（通过视图v$datafile的字段last_change#可以查询）是一个无穷大的数字或者说是NULL
在一个事务提交后（上述第四个步骤）会在redo log中存在一条redo记录同时系统为其提供一个最新的SCN（通过函数dbms_flashbackget_system_change_number可以知道当前的最新SCN）记录在该条记录中如果该条记录是在redo log被清空（日志满做切换时或发生checkpoint时所有变化日志已经被写入数据文件中）则其SCN被记录为redo log的low SCN以后在日志再次被清空前写入的redo记录中SCN则成为Next SCN
当日志切换或发生checkpoint（上述第五个步骤）时从Low SCN到Next SCN之间的所有redo记录的数据就被DBWn进程写入数据文件中而CKPT进程则将所有数据文件（无论redo log中的数据是否影响到该数据文件）的文件头上记录的Start SCN（通过视图v$datafile_header的字段checkpoint_change#可以查询）更新为Next SCN同时将控制文件中的System Checkpoint SCN（通过视图v$database的字段checkpoint_change#可以查询）每个数据文件对应的Datafile Checkpoint（通过视图v$datafile的字段checkpoint_change#可以查询）也更新为Next SCN但是如果该数据文件所在的表空间被设置为readonly时数据文件的Start SCN和控制文件中Datafile Checkpoint SCN都不会被更新
那系统是如何产生一个最新的SCN的？实际上这个数字是由当时的timestamp转换过来的每当需要产生一个最新的SCN到redo记录时系统获取当时的timestamp将其转换为数字作为SCN我们可以通过函数SCN_TO_TIMESTAMP（g以后）将其转换回timestamp
SQL> select dbms_flashbackget_system_change_number SCN_TO_TIMESTAMP(dbms_flashbackget_system_change_number) from dual;
GET_SYSTEM_CHANGE_NUMBER
SCN_TO_TIMESTAMP(DBMS_FLASHBACKGET_SYSTEM_CHANGE_NUMBER)
AUG PM
也可以用函数timestamp_to_scn将一个timestamp转换为SCN
SQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual; SCNSQL> select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
SCN
最后SCN除了作为反映事务数据变化并保持同步外它还起到系统的心跳作用——每隔秒左右系统会刷新一次系统SCN
下面在简单介绍一下SCN如何在数据库恢复中起作用
数据库在正常关闭（shutdown immediate/normal）时会先做一次checkpoint将log file中的数据写入数据文件中将控制文件数据文件中的SCN（包括控制文件中的Stop SCN）都更新为最新的SCN
数据库异常/意外关闭不会或者只更新部分Stop SCN
当数据库启动时Oracle先检查控制文件中的每个Datafile Checkpoint SCN和数据文件中的Start SCN是否相同再检查每个Datafile Checkpoint SCN和Stop SCN是否相同如果发现有不同就从Redo Log中找到丢失的SCN重新写入数据文件中进行恢复具体的数据恢复过程这里就不再赘述
SCN作为Oracle中的一个重要机制在多个重要功能中起着控制器的作用了解SCN的产生和实现方式帮助DBA理解和处理恢复DGStreams复制的问题
最后提一句利用SCN机制在Oraclegg中又增加了一些很实用的功能——数据库闪回数据库负载重现等
