Oracle SCN机制详细解读

2025-04-08 技术教程

深入剖析 - Oracle SCN机制详细解读

https://mp.weixin.qq.com/s?__biz=MjM5MDAxOTk2MQ==&mid=2650276971&idx=1&sn=b5fb89b351d5b5bedd6353ff9c0b2157&chksm=be479c7d8930156bf73bd87f0bac869029f7341b3fdb4ed26a838b4e401c811116669acd5499&mpshare=1&scene=24&srcid=0927zxmXBLuBo3yxm7qsFYOy#rd

http://blog.chinaunix.net/uid-20274021-id-1969571.html

SCN即系统改变号（System Change Number），是在某个时间点定义数据库已提交版本的时间戳标记。 Oracle为每个已提交的事务分配一个唯一的SCN。 SCN的值是对数据库进行更改的逻辑时间点。 Oracle使用此编号记录对数据库所做的更改。在数据库中，SCN也可以说是无处不在，数据文件头，控制文件，数据块头，日志文件等等都标记着SCN。也正是这样，数据库的一致性维护和SCN密切相关。不管是数据的备份，恢复都是离不开SCN的。

在理解这几种SCN之前，我们先看下oracle事务中的数据变化是如何写入数据文件的：

第一步：事务开始；

第二步：在buffer cache中找到需要的数据块，如果没找到，从数据文件中载入buffer cache中；

第三步：事务修改buffer cache的数据块，该数据被标识为“脏数据”，并被写入log buffer中；

第四步：事务提交，LGWR进程将log buffer中的“脏数据”的日志条目写入redo log file中；

第五步：当发生checkpoint，CKPT进程更新所有数据文件的文件头中的信息，DBWn进程则负责将Buffer Cache中的脏数据

写入到数据文件中。

经过上述5个步骤，事务中的数据变化最终被写入到数据文件中。但是，一旦在上述中间环节数据库意外宕机了，在重新启动时

如何知道哪些数据已经写入数据文件、哪些没有写呢？（同样，在DG、streams中也存在

类似疑问：redolog中哪些是上一次同步已经复制过的数据、哪些没有）

SCN机制就能比较完善的解决上述问题。 SCN是一个数字，确切的说是一个只会增加、不会减少的数字。正是它这种只会增

加的特性确保了 Oracle知道哪些应该被恢复、哪些应该被复制。

首先这里我们先介绍四个SCN概念。

1、系统检查点scn (System Checkpoint SCN)

当一个checkpoint检查点动作完成后，Oracle就把系统检查点的SCN存储到控制文件中。

select checkpoint_change# from v$database;

2，数据文件检查点scn (Datafile Checkpoint SCN)

当一个checkpoint动作完成后，Oracle就把每个数据文件的Datafile Checkpoint SCN单独存放在控制文件中。

select name,checkpoint_change# from v$datafile;

3，启动scn (Start SCN)

Oracle把这个检查点的scn存储在每个数据文件的文件头中，这个值称为启动scn，这个SCN用于用于在数据库实例启动时，检查是否需要执行数据库恢复media recovery。

select name,checkpoint_change# from v$datafile_header;

4、终止scn (Stop SCN)

每个数据文件的终止scn都存储在控制文件中。这个SCN号用于检查数据库启动过程是否需要做instance recovery。

select name,last_change# from v$datafile;

5.media recovery和instance recovery

1).media recovery是需要利用以前的备份来进行恢复的，而INSTANCE RECOVERY是不需要的。

2).media recovery通常发生在数据库的数据文件之类发生损坏，需要利用以前的备份来进行的恢复，需要人工处理。

3).instance recovery则是发生在实例不正常关闭情况下的恢复，是INSTANCE自己来的，不需要人工干预的。

6、在数据库运行期间的scn值

1).在数据库打开并运行之后，控制文件中的系统检查点、控制文件中的数据文件检查点scn和每个数据文件头中的启动scn都是相同的。控制文件中的每个数据文件的终止scn都为null.

2).在安全关闭数据库的过程中，系统会执行一个检查点动作，这时所有数据文件的终止scn都会设置成数据文件头中的那个启动scn的值。

3).在数据库重新启动的时候，Oracle将文件头中的那个启动scn与数据文件检查点scn进行比较，如果这两个值相互匹配，oracle接下来还要比较数据文件头中的启动scn和控制文件中数据文件的终止scn。如果这两个值也一致，就意味着所有数据块多已经提交，所有对数据库的修改都没有在关闭数据库的过程中丢失，因此这次启动数据库的过程也不需要任何恢复操作，此时数据库就可以打开了。当所有的数据库都打开之后，存储在控制文件中的数据文件终止scn的值再次被更改为null，这表示数据文件已经打开并能够正常使用了。

7.SCN与数据库启动

在数据库启动过程中，当System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN都相同时，数据库可以正常启动，不需要做media recovery。三者当中有一个不同时，则需要做media recovery.如果在启动的过程中，End SCN为NULL，则需要做instance recovery。Oracle在启动过程中首先检查是否需要media recovery，然后再检查是否需要instance recovery。

8.SCN与数据库关闭

如果数据库的正常关闭的话，将会触发一个checkpoint，同时将数据文件的END SCN设置为相应数据文件的Start SCN。当数据库启动时，发现它们是一致的，则不需要做instance recovery。在数据库正常启动后，ORACLE会将END SCN设置为NULL.如果数据库异常关闭的话，则END SCN将为NULL。

9.恢复数据库时什么时候需要using backup controlfile

数据文件检查点scn(Datafile Checkpoint SCN)

select checkpoint_change# from v$datafile;

启动scn(Start SCN)

select checkpoint_change# from v$datafile_header;

如果查询结果数据文件检查点scn >= 启动scn,则不需要使用using backup controlfile；

如果查询结果数据文件检查点scn < 启动scn,则需要使用using backup controlfile；