OracleSCN实现机制总结

OracleSCN实现机制总结

SCN（System Chang Number）作为oracle中的一个重要机制，在数据恢复、Data Guard、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进程则负责将Buffer Cache中的脏数据写入到数据文件中。

　　经过上述5个步骤，事务中的数据变化最终被写入到数据文件中。但是，一旦在上述中间环节时，数据库意外宕机了，在重新启动时如何知道哪些数据已经写入数据文件、哪些没有写呢（同样，在DG、streams中也存在类似疑问：redo log中哪些是上一次同步已经复制过的数据、哪些没有）？SCN机制就能比较完善的解决上述问题。

　　SCN是一个数字，确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特性确保了Oracle知道哪些应该被恢复、哪些应该被复制。

　　这四个分别是：1.System Checkpoint SCN当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询：select checkpoint_change# from v$database；2.Datafile Checkpoint SCN当checkpoint完成后，ORACLE将Datafile Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt 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和Start SCN号都相同时，数据库可以正常启动，不需要做media recovery.三者当中有一个不同时，则需要做media recovery.如果在启动的过程中，End SCN号为NULL，则需要做instance recovery.ORACLE在启动过程中首先检查是否需要media recovery，然后再检查是否需要instance recovery. SCN号与数据库关闭如果数据库的正常关闭的话，将会触发一个checkpoint，同时将数据文件的END SCN号设置为相应数据文件的Start SCN号。

　　当数据库启动时，发现它们是一致的，则不需要做instance recovery.在数据库正常启动后，ORACLE会将END SCN号设置为NULL.如果数据库异常关闭的话，则END SCN号将为NULL.为什么需要System checkpoint SCN号与Datafile Checkpoint SCN号为什么ORACLE会在控制文件中记录System checkpoint SCN号的同时，还需要为每个数据文件记录Datafile Checkpoint SCN号？

　　原因有二：1.对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。

　　这三个SCN在表空间处于只读期间都将被冻结。

　　2.如果控制文件不是当前的控制文件，则System checkpoint会小于Start SCN或END SCN号。记录这些SCN号，可以区分控制文件是否是当前的控制文件。

　　Recovery database using backup controlfile当有一个Start SCN号超过了System Checkpoit SCN号时，则说明控制文件不是当前的控制文件，因此在做recovery时需要采用using backup controlfile.这是为什么需要记录SystemCheckpoint SCN的原因之一。

　　这里需要一提的是，当重建控制文件的时候，System Checkpoint SCN为0，Datafile Checkpoint SCN的数据来自于Start SCN.根据上述的描述，此时需要采用using backup controlfile做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） from dual；也可以用函数timestamp_to_scn将一个timestamp转换为SCN：select timestamp_to_scn（SYSTIMESTAMP） as scn from dual；如果你想把DATE类型转换成TIMESTAMP类型，就使用CAST函数。

　　select cast（sysdate as timestamp） from dual；

　　Oracle SCN 实现机制总结author：润明 2012-2-4  QQ：226399587  /runming918 SCN（System Chang Number）作为oracle中的一个重要机制，在数据恢复、Data Guard、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进程则负责将Buffer Cache中的脏数据写入到数据文件中。

　　经过上述5个步骤，事务中的数据变化最终被写入到数据文件中。但是，一旦在上述中间环节时，数据库意外宕机了，在重新启动时如何知道哪些数据已经写入数据文件、哪些没有写呢（同样，在DG、streams中也存在类似疑问：redo log中哪些是上一次同步已经复制过的数据、哪些没有）？SCN机制就能比较完善的解决上述问题。

　　SCN是一个数字，确切的说是一个只会增加、不会减少的数字。正是它这种只会增加的特性确保了Oracle知道哪些应该被恢复、哪些应该被复制。

　　这四个分别是：1.System Checkpoint SCN当checkpoint完成后，ORACLE将System Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询：select checkpoint_change# from v$database；2.Datafile Checkpoint SCN当checkpoint完成后，ORACLE将Datafile Checkpoint SCN号存放在控制文件中。我们可以通过下面SQL语句查询所有数据文件的Datafile Checkpoinnt 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和Start SCN号都相同时，数据库可以正常启动，不需要做media recovery.三者当中有一个不同时，则需要做media recovery.如果在启动的过程中，End SCN号为NULL，则需要做instance recovery.ORACLE在启动过程中首先检查是否需要media recovery，然后再检查是否需要instance recovery. SCN号与数据库关闭如果数据库的正常关闭的话，将会触发一个checkpoint，同时将数据文件的END SCN号设置为相应数据文件的Start SCN号。

　　当数据库启动时，发现它们是一致的，则不需要做instance recovery.在数据库正常启动后，ORACLE会将END SCN号设置为NULL.如果数据库异常关闭的话，则END SCN号将为NULL.为什么需要System checkpoint SCN号与Datafile Checkpoint SCN号为什么ORACLE会在控制文件中记录System checkpoint SCN号的同时，还需要为每个数据文件记录Datafile Checkpoint SCN号？

　　原因有二：1.对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。

　　这三个SCN在表空间处于只读期间都将被冻结。

　　2.如果控制文件不是当前的控制文件，则System checkpoint会小于Start SCN或END SCN号。记录这些SCN号，可以区分控制文件是否是当前的控制文件。

　　Recovery database using backup controlfile当有一个Start SCN号超过了System Checkpoit SCN号时，则说明控制文件不是当前的控制文件，因此在做recovery时需要采用using backup controlfile.这是为什么需要记录SystemCheckpoint SCN的原因之一。

　　这里需要一提的是，当重建控制文件的时候，System Checkpoint SCN为0，Datafile Checkpoint SCN的数据来自于Start SCN.根据上述的描述，此时需要采用using backup controlfile做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） from dual；也可以用函数timestamp_to_scn将一个timestamp转换为SCN：select timestamp_to_scn（SYSTIMESTAMP） as scn from dual；如果你想把DATE类型转换成TIMESTAMP类型，就使用CAST函数。

　　select cast（sysdate as timestamp） from dual；