扒了下Oracle的SCN核心机制，被狠狠的惊艳到了！
詹姆斯邦德007约 5 分钟SCN是Oracle内部的一个递增数字，用于唯一标识数据库的变更顺序，今天小编就带大家一起扒拉下CSN的核心机制。
相对我们人类用世纪、年月日、时分秒计时而言，SCN就相当于ORACLE的计时方法。SCN是一个数字，确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特 性确保了Oracle知道哪些应该被恢复、哪些应该被复制。
【关键术语】
System Change Number 系统更改号
System Checkpoint SCN 系统检查点 SCN
Datafile Checkpoint SCN 数据文件检查点 SCN
Start SCN 开始 SCN（Begin SCN）
Stop SCN 结束 SCN（End SCN）
1.数据变化是如何写入数据文件
1．事务开始；
2．在BUFFER CACHE中寻找需要的数据块，如果没有，则从数据文件读入数据块；
3．生成重做项写入REDO LOG BUFFER（重做日志缓冲区）中，修改BUFFER CACHE（数据库高速缓冲区），该区域被标识为“脏缓冲区”；
4．事务提交，LGWR进程将LOG BUFFER中的重做记录写入ONLINE REDO LOG FILE（联机重做日志文件）中；
5．当发生CHECKPOINT，CKPT进程更新所有数据库文件头的信息，DBWn进程将 BUFFER CACHE中的脏数据写入DATA FILE中。
2.SCN的变化历程
2.1 系统最新SCN
SQL> select current_scn from v$database;
CURRENT_SCN
----------------------
847164
通过查询可以发现，该 SCN 一直在发生变化，
是系统最新的 SCN 号。
2.2 系统检查点SCN
当checkpoin（检查点）完成后，ORACLE 将System Checkpoint SCN号（系统检查点SCN）存放在控制文件中。
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
-----------------------------------
846888
//通过查询可以发现，该 SCN 没有发生变化，
并且小于系统最新的 SCN 号。
//执行检查点
SQL> alter system checkpoint;
System altered.
//查询系统检查点 SCN
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------------------------
847491
//查询系统当前 SCN
SQL> select current_scn from v$database;
CURRENT_SCN
----------------------
847495
//通过以上实验可以发现，
系统检查点 SCN 根据检查点发生变化，
即当前数据库同步状态的 SCN。
2.3 数据文件检查点SCN
当checkpoint完成后，ORACLE 将Datafile Checkpoint SCN 号存放在控制文件中。
SQL> select name,checkpoint_change# from v$datafile;
NAME CHECKPOINT_CHANGE#
------------------------------------------------------------ ----------------------------------
/u01/app/oracle/oradata/orcl/system01.dbf 847491
/u01/app/oracle/oradata/orcl/sysaux01.dbf 847491
/u01/app/oracle/oradata/orcl/undotbs01.dbf 847491
/u01/app/oracle/oradata/orcl/users01.dbf 847491
/u01/app/oracle/oradata/orcl/example01.dbf 847491
我们发现，每个数据文件都有一个对应的数据文件检查点 SCN 号
2.4 Start SCN
ORACLE 将Start SCN号存放在数据文件头中。 这个 SCN 用于检查数据库启动过程是否需要做media recovery（介质恢复）.
介质恢复（Media Recovery）是在数据文件本身不一致（通常是由于物理损坏或从备份还原）时，需要人工干预的恢复过程，它利用备份、归档重做日志和在线重做日志将数据文件修复到事务一致的状态。
2.5 Stop SCN
ORACLE 将Stop SCN 号存放在控制文件中。 这个 SCN 号用于检查数据库启动过程是否需要做instance recovery（实例恢复）。
实例恢复（Instance Recovery），它发生在数据库实例异常关闭（如断电）后。此时，数据文件本身是完整的，但可能有一部分已提交事务的更改还留在内存中未来得及写入数据文件（需要前滚），也可能有一部分未提交事务的更改已写入数据文件（需要回滚）。实例恢复是Oracle实例自动完成的，不需要DBA干预。
3.网友问答
针对以上问题，我回答网友们的以下问答哈！
3.1 SCN 的变化机制是？
记录日志时，自动记录最新的 SCN 到日志中。因此，每一条日志都包含了一个时间。
当 DBWn 进程启动时，将依照日志记录写入一段数据。这一段日志记录的时间段必定有一个最早时间和一个最新（迟）时间。最早的时间我们称为 LOW SCN（即上次清空日志后的 第一条记录），最新时间我们称为 NEXT SCN（即下次日志清空前的最近一条记录）。
这 里 ，由 CKPT 进 程 将 NEXT SCN 的 值 同 步 更 新 到 START SCN 、 SYSTEM CHECKPOINT SCN 和 DATAFILE CHECKPOINT SCN 中，以确保所有文件的一致性。
3.2 最新的 SCN 如何生成？
系统是如何产生一个最新的SCN的？实际上，这个数字是由当时的timestamp转换过来的。每当需要产生一个最新的SCN到redo记录时，系统获取当时的timestamp，将其转换为 数字作为SCN。
3.3 SCN号与数据库启动的关系
检查是否需要介质恢复 在数据库启动过程中，当System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN 号都相同时，数据库可以正常启动，不需要做media recovery。三者当中有一个不同时，则需要做media recovery.
检查是否需要实例恢复 如果在启动的过程中，End SCN 号为NULL，则需要做instance recovery.ORACLE 在启动过程中首先检查是否需要media recovery，然后再检查是否需要instance recovery.
3.4 SCN 号与数据库关闭的关系
如果数据库的正常关闭的话，将会触发一个checkpoint，同时将数据文件的END SCN 号设置为相应数据文件的 Start SCN号。
当数据库启动时，发现它们是一致的，则不需要做instance recovery。在数据库正常启动后，ORACLE会将END SCN 号设置为NULL.
如果数据库异常关闭的话，则END SCN号将为NULL.
3.5 为什么需要System SCN号与Datafile 号
为什么 ORACLE会在控制文件中记录System checkpoint SCN 号的同时，还需要为每个数据文件记录Datafile Checkpoint SCN 号？
对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。这三个 SCN在表空间处于只读期间都将被冻结。
如果控制文件不是当前的控制文件，则System checkpoint会小于Start SCN或ENDSCN号。
记录这些SCN号，可以区分控制文件是否是当前的控制文件。