SCN（SystemChang Number）作为oracle中的一个重要机制，在数据恢复、DataGuard、Streams复制、RAC节点间的同步等各个功能中起着重要作用。理解SCN的运作机制，可以帮助你更加深入地了解上述功能。
在理解SCN之前，我们先看下oracle事务中的数据变化是如何写入数据文件的：
1、事务开始；
2、在buffer cache中找到需要的数据块，如果没有找到，则从数据文件中载入buffer cache中；
3、事务修改buffer cache的数据块，该数据被标识为“脏数据”，并被写入log buffer中；
4、事务提交，LGWR进程将log buffer中的“脏数据”写入redo log file中；
5、当发生checkpoint，CKPT进程更新所有数据文件的文件头中的信息，DBWn进程则负责将BufferCache中的脏数据写入到数据文件中。
经过上述5个步骤，事务中的数据变化最终被写入到数据文件中。但是，一旦在上述中间环节时，数据库意外宕机了，在重新启动时如何知道哪些数据已经写入数据文件、哪些没有写呢（同样，在DG、streams中也存在类似疑问：redolog中哪些是上一次同步已经复制过的数据、哪些没有）？SCN机制就能比较完善的解决上述问题。
SCN是一个数字，确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特性确保了Oracle知道哪些应该被恢复、哪些应该被复制。
这四个分别是：
1.System Checkpoint SCN
当checkpoint完成后，ORACLE将System CheckpointSCN号存放在控制文件中。我们可以通过下面SQL语句查询：
select checkpoint_change# from v$database;
2.Datafile Checkpoint SCN
当checkpoint完成后，ORACLE将Datafile CheckpointSCN号存放在控制文件中。我们可以通过下面SQL语句查询所有数据文件的DatafileCheckpoinnt SCN号。
select name,checkpoint_change# from v$datafile;
3.Start SCN号
ORACLE将Start SCN号存放在数据文件头中。
这个SCN用于检查数据库启动过程是否需要做Media Recovery.（介质恢复）
我们可以通过以下SQL语句查询：
select name,checkpoint_change# from v$datafile_header;
4.End SCN (Stop SCN)号
ORACLE将End SCN号存放在控制文件中。
这个SCN号用于检查数据库启动过程是否需要做Instance Recovery.（实例恢复）
我们可以通过以下SQL语句查询：
select name,last_change# from v$datafile;
在数据库正常运行的情况下，对可读写的，online的数据文件，该SCN号为NULL.
SCN号与数据库启动
在数据库启动过程中，当System Checkpoint SCN、Datafile Checkpoint SCN和StartSCN号都相同时，数据库可以正常启动，不需要做media recovery.三者当中有一个不同时，则需要做mediarecovery。如果在启动的过程中，End SCN号为NULL，则需要做instancerecovery。ORACLE在启动过程中首先检查是否需要media recovery，然后再检查是否需要instancerecovery。
SCN号与数据库关闭
如果数据库的正常关闭的话，将会触发一个checkpoint，同时将数据文件的END SCN号设置为相应数据文件的StartSCN号。
当数据库启动时，发现它们是一致的，则不需要做instance recovery。在数据库正常启动后，ORACLE会将ENDSCN号设置为NULL。如果数据库异常关闭的话，则END SCN号将为NULL.
为什么需要System checkpoint SCN号与Datafile CheckpointSCN号
为什么ORACLE会在控制文件中记录System checkpoint SCN号的同时，还需要为每个数据文件记录
Datafile Checkpoint SCN号？
原因有二：
1.对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。
这三个SCN在表空间处于只读期间都将被冻结。
2.如果控制文件不是当前的控制文件，则System checkpoint会小于Start SCN或ENDSCN号。记录这些SCN号，可以区分控制文件是否是当前的控制文件。
Recovery database using backup controlfile
当有一个Start SCN号超过了System CheckpoitSCN号时，则说明控制文件不是当前的控制文件，因此在做recovery时需要采用using backupcontrolfile。这是为什么需要记录SystemCheckpoint SCN的原因之一。
这里需要一提的是，当重建控制文件的时候，System Checkpoint SCN为0，Datafile CheckpointSCN的数据来自于Start SCN。根据上述的描述，此时需要采用using backupcontrolfile做recovery。
那系统是如何产生一个最新的SCN的？实际上，这个数字是由当时的timestamp转换过来的。每当需要产生一个最新的SCN到redo记录时，系统获取当时的timestamp，将其转换为数字作为SCN。
可以通过函数SCN_TO_TIMESTAMP（10g以后）将其转换回timestamp：
select dbms_flashback.get_system_change_number,SCN_TO_TIMESTAMP(dbms_flashback.get_system_change_number) fromdual;
也可以用函数timestamp_to_scn将一个timestamp转换为SCN：
select timestamp_to_scn(SYSTIMESTAMP) as scn from dual;
如果你想把DATE类型转换成TIMESTAMP类型，就使用CAST函数。
select cast(sysdate as timestamp) from dual;
看到这里似乎懂了一点点但是还是不是很清楚？？？？
继续看下面：
一、SCN内容
1、概念：SCN（The System Change Number）
system change number (SCN)是一个非常重要的标记，Oracle使用它来标记数据库在过去时间内的状态和轨迹。SCN就是ORACLE 数据库自己的时间，通过它特有的生成机制形成SCN，
SCN这个数字是由当时的timestamp转换过来的。每当需要产生一个最新的SCN到redo记录时，系统获取当时的timestamp，将其转换为数字作为SCN。
2、分类
a:系统检查点scn(system scn)
当一个检查点动作完成后，Oracle就把系统检查点的SCN存储到控制文件中。
select to_char(checkpoint_change#)system_scn from v$database;
针对数据库，只有一个SCN
b)数据文件检查点scn(datafile scn)
当一个检查点动作完成后，Oracle就把每个数据文件的scn单独存放在控制文件中。
select name,to_char(checkpoint_change#) data_scn from v$datafilewhere rownum<1;
针对数据文件，每个数据文件一个。
c)启动scn(start scn)
Oracle把这个检查点的scn存储在每个数据文件的文件头中，这个值称为启动scn，因为它用于在数据库实例启动时，
检查是否需要执行数据库恢复.
select name,to_char(checkpoint_change#) start_scn fromv$datafile_header where rownum<2;
针对数据文件，每个数据文件一个。
d)终止scn
每个数据文件的终止scn都存储在控制文件中
select name,to_char(checkpoint_change#)data_scn,to_char(last_change#) stop_scn from v$datafile;
针对数据文件，每个数据文件一个。
e)日志文件SCN( Lowest system change number (SCN) in the log)
select group#,sequence#,status,first_change# from v$log;
select first_change# from v$log
---当前日志组中的第一个SCN号。
f)当前current scn
select to_char(dbms_flashback.get_system_change_number) fromdual;---当前SCN号
select to_char(current_scn)system_scn from v$database;---当前SCN号
select to_char(TIMESTAMP_TO_SCN(SYSDATE)) from dual;
SELECT TO_CHAR(SCN_TO_TIMESTAMP(scn)) fromdual;
备注：SCN实际是和系统时间挂钩的，通过SYSDATE可以自动生成SCN号。
3、SCN工作理论
SCN有点类似于sequence，Oracle在SGA中增加它。当一个事务修改或者插入数据，Oracle首先写入一个新的SCN到回滚段中logwriter进程立刻把提交的记录写入到重做日志中，这条提交的记录将拥有唯一的SCN.事实上，把SCN写入到日志，就意味着一个事务的完成。每当数据库发生checkpoint，Oracle写一个START SCN命令到数据文件头。控制文件维护着每个数据文件的SCN，称为STOPSCN，通常是无穷大，每当实例正常关闭（SHUTDOWN NORMAL or SHUTDOWNIMMEDIATE），Oracle会复制数据文件头STARTSCN到控制文件的STOPSCN。如果是正常的重启数据库，是不需要恢复的，因为控制文件和数据文件的SCN是吻合的。反之，突然中断系统就没法同步SCN，SCN不匹配，Oracle就认为需要做恢复
二、CHECKPOINT内容
1、概念--什么是checkpoint
在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，通常数据库都是保证在提交（commit）完成之前要先保证日志都被写入到日志文件中，而脏数据块着保存在数据缓存（buffercache）中再不定期的分批写入到数据文件中。也就是说日志写入和提交操作是同步的，而数据写入和提交操作是不同步的。这样就存在一个问题，当一个数据库崩溃的时候并不能保证缓存里面的脏数据全部写入到数据文件中，这样在实例启动的时候就要使用日志文件进行恢复操作，将数据库恢复到崩溃之前的状态，保证数据的一致性。检查点是这个过程中的重要机制，通过它来确定，恢复时哪些重做日志应该被扫描并应用于恢复。
一般所说的checkpoint是一个数据库事件（event），checkpoint事件由checkpoint进程（LGWR/CKPT进程）发出，当checkpoint事件发生时DBWn会将脏块写入到磁盘中，同时数据文件和控制文件的文件头也会被更新以记录checkpoint信息。
2、checkpoint作用
保证数据库的一致性，这是指将脏数据写入到硬盘，保证内存和硬盘上的数据是一样的；
缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会很长，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。
通俗的说checkpoint就像word的自动保存一样。
3、分类
完全检查点（Normal checkpoint）
增量检查点（Incremental checkpoint）
4、相关概念
RBA（Redo Byte Address）, Low RBA（LRBA）, High RBA（HRBA）
RBA就是重做日志块（redo logblock）的地址，相当与数据文件中的ROWID，通过这个地址来定位重做日志块。RBA由三个部分组成：
日志文件序列号（4字节）
日志文件块编号（4字节）
重做日志记录在日志块中的起始偏移字节数（2字节）
通常使用RBA的形式有：
LRBA
数据缓存（buffer cache）中一个脏块第一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为LRBA。
HRBA
数据缓存（buffercache）中一个脏块最近一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为HRBA。
checkpoint RBA
当一个checkpoint事件发生的时候，checkpoint进程会记录下当时所写的重做日志块的地址即RBA，此时记录的RBA被称为checkpointRBA。从上一个checkpoint RBA到当前的checkpoint RBA之间的日志所保护的buffercache中的脏块接下来将会被写入到数据文件当中去。
topBuffer checkpoint Queues （BCQ）
Oracle将所有在数据缓存中被修改的脏块按照LRBA顺序的组成一个checkpoint队列，这个队列主要记录了buffercache第一次发生变化的时间顺序，然后有DBWn进程根据checkpoint队列顺序将脏块写入到数据文件中，这样保证了先发生变更的buffer能先被写入到数据文件中。BCQ的引入是为了支持增量checkpoint的。
topActive checkpoint Queue （ACQ）
ACQ中包含了所有活动的checkpoint请求。每次有新checkpoint请求是都会在ACQ中增加一条记录，ACQ记录中包含了相应的checkpointRBA。checkpoint完成以后相应的记录将被移出队列。
5、完全检查点 （normal checkpoint）完全检查点工作过程
一个checkpoint操作可以分成三个不同的阶段：
第一阶段，checkpoint进程开始一个checkpoint事件，并记录下checkpointRBA，这个通常是当前的RBA。
第二阶段，checkpoint进程通知DBWn进程将所有checkpoint RBA之前的buffercache里面的脏块写入磁盘。
第三阶段，checkpoint进程将checkpoint信息（SCN）写入/更新数据文件和控制文件中。
更新SCN的操作由CKPT进程完成，在Oracle8.0之后CKPT进程默认是被启用的，如果CKPT进程没有启用的话那相应的操作将由LGWR进程完成。
什么时候发生normal checkpoint
下面这些操作将会触发checkpoint事件：
日志切换，通过ALTER SYSTEM SWITCH LOGFILE。
DBA发出checkpoint命令，通过ALTER SYSTEM checkpoint。
对数据文件进行热备时，针对该数据文件的checkpoint也会进行，ALTER TABLESPACE TS_NAME BEGINBACKUP/END BACKUP。
当运行ALTER TABLESPACE/DATAFILE READ ONLY的时候。
SHUTDOWN命令发出时。
特别注意：
日志切换会导致checkpoint事件发生，但是checkpoint发生却不会导致日志切换。
日志切换触发的是normal checkpoint，而不是大家所说的增量checkpoint，只不过log switchcheckpoint的优先级非常低，当一个log switchcheckpoint发生的时候它并不会立即的通知DBWn进程去写数据文件，但是当有其它原因导致checkpoint或者是写入数据文件的RBA超过logswitch checkpoint的checkpoint RBA的时候，这次的log switchcheckpoint将会被标记成完成状态，同时更新控制文件和数据文件头。我们随后可以做个实验验证这个说法。
checkpoint和SCN有什么关系？
在Oracle中SCN相当于它的时钟，在现实生活中我们用时钟来记录和衡量我们的时间，而Oracle就是用SCN来记录和衡量整个Oracle系统的更改。
Oracle中checkpoint是在一个特定的“时间点”发生的，衡量这个“时间点”用的就是SCN，因此当一个checkpoint发生时SCN会被写入文件头中以记录这个checkpoint。
6、增量checkpoint
增量checkpoint工作过程
因为每次完全的checkpoint都需要把buffercache所有的脏块都写入到数据文件中，这样就是产生一个很大的IO消耗，频繁的完全checkpoint操作很对系统的性能有很大的影响，为此Oracle引入的增量checkpoint的概念，buffercache中的脏块将会按照BCQ队列的顺序持续不断的被写入到磁盘当中，同时CKPT进程将会每3秒中检查DBWn的写入进度并将相应的RBA信息记录到控制文件中。
有了增量checkpoint之后在进行实例恢复的时候就不需要再从崩溃前的那个完全checkpoint开始应用重做日志了，只需要从控制文件中记录的RBA开始进行恢复操作，这样能节省恢复的时间。
发生增量checkpoint的先决条件
恢复需求设定 （FAST_START_IO_TARGET/FAST_START_MTTR_TARGET）
LOG_checkpoint_INTERVAL参数值
LOG_checkpoint_TIMEOUT参数值
最小的日志文件大小
buffer cache中的脏块的数量
增量checkpoint的特点
增量checkpoint是一个持续活动的checkpoint。
没有checkpoint RBA，因为这个checkpoint是一直都在进行的，所以不存在normalcheckpoint里面涉及的checkpoint RBA的概念。
checkpoint advanced in memory only
增量checkpoint所完成的RBA信息被记录在控制文件中。
增量checkpoint可以减少实例恢复时间。
