关于SCN

参考链接

1. 深入剖析 - Oracle SCN机制详细解读
2. 详解Oracle scn
3. Oracle SCN详解
4. oracle checkpoint检查点
5. Oracle查询SCN号---共三种方式
6. ORACLE中科学计数法显示问题的解决

背景

上一篇写了如何用SCN增量备份数据库，这里具体写写关于SCN的东西。要说SCN，还是先看看在事务中被修改的数据是如何写入到数据文件中的。

一、 事务对数据文件的更改

1. 事务开始；
2. 在buffer cache中找到需要的数据块，如果没找到，从数据文件中载入buffer cache中；
3. 事务修改buffer cache的数据块，该数据被标识为“脏数据”，并被写入log buffer中；
4. 事务提交，LGWR进程将log buffer中的“脏数据”的日志条目写入redo log file中；
5. 当发生checkpoint，CKPT进程更新所有数据文件的文件头中的信息，DBWn进程则负责将Buffer Cache中的脏数据写入到数据文件中。

二、 SCN相关

SCN(System Change Number)，用六个字节记录对数据库进行的更改，随着时间的推移不断增长。
下面总结下个人对于数据库当前SCN、控制文件中系统SCN、控制文件中数据文件SCN、数据文件头中SCN和在线重做日志文件中SCN的理解以及相应的查询方式。

1. 数据库当前SCN

数据库当前SCN就像个时钟一样一直往前走，但是这个SCN的增长也是有条件的，并不是想往上增长就能增长，从事务对数据文件修改的过程来看，一个当前SCN应该要在对应的对数据库进行更改的操作成功写入在线重做日志文件才能继续增长，这样才能确保数据库突然崩溃不会影响到已经发生的对数据库进行的更改。
数据库当前SCN查询：

SET numw 20    #此行语句用于解决科学计数法显示不完整问题

SELECT current_scn
FROM   v$database;

或者

SET numw 20

SELECT dbms_flashback.get_system_change_number AS current_scn
FROM   dual;

2. 控制文件中系统SCN

控制文件中系统SCN的更改发生在checkpoint执行之后，checkpoint的执行将数据库当前SCN写入控制文件和数据文件中，更改了控制文件中的系统SCN、数据文件SCN，以及数据文件头中的SCN。
控制文件中系统SCN查询：

SET numw 20

SELECT checkpoint_change#
FROM   v$database;

3. 控制文件中数据文件SCN

控制文件中数据文件SCN正常情况下与数据文件头中SCN是一致的，那么，明明数据文件头中已经有数据文件相关的SCN了，为什么控制文件中还要有一个呢，这个和控制文件的功能有关，在数据库正常启动时，需要根据控制文件打开相应的数据文件，如果控制文件中数据文件SCN与数据文件头中真实的SCN不一致，控制文件中SCN较小说明控制文件太旧了，需要新的控制文件，控制文件中SCN较大则说明数据文件需要进行恢复操作。
控制文件中数据文件SCN查询：

SET numw 20

SELECT DISTINCT checkpoint_change#
FROM   v$datafile;

4. 数据文件头中SCN

数据文件头中SCN是对数据文件的头部进行了读取获得的关于数据文件的真实的SCN信息，在做数据库的SCN的增量备份恢复时，应该用此SCN数据作为增量备份的起点SCN。
数据文件头中SCN查询：

SET numw 20

SELECT DISTINCT checkpoint_change#
FROM   v$datafile_header;

5. 在线重做日志文件中SCN

在线重做日志文件中记录有每个在线重做日志文件对应的SCN信息，即这个在线重做日志文件是从哪个SCN开始使用的，从哪个SCN开始结束。当前正在使用的在线重做日志文件结束SCN为最大值。
通过查看在线重做日志文件的起始结束SCN信息，可以在数据库异常崩溃后判断用的是哪个在线重做日志文件进行恢复，当然，这个恢复操作Oracle数据库自己会弄，不用你操心。
在线重做日志文件中SCN查询：

SET numw 20

SELECT group#,
       thread#,
       sequence#,
       status,
       first_change#,
       next_change#
FROM   v$log;

三、 SCN增量备份恢复中需要新控制文件的反思

文章链接：Oralce数据库SCN增量备份恢复
在SCN增量备份过程中使用了从主库中生成的新控制文件，当时在操作时并未思考这么多，突然想到这件问题，记录一下：
这个是因为recover操作是以控制文件为依据进行的，旧的控制文件不包含新的数据信息，所以recover操作无法进行，需要用新的控制文件。进一步推测，数据库restore操作和recover操作都是基于数据块，按数据块的SCN大小顺序进行的。

Emm，明天有空再学习总结下今年很火的headroom问题 ^_^