OracleSCN机制详细解读

深入剖析 - 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；