Checkpoint和SCN的解析

Checkpoint

不少人都把checkpoint的概念给复杂化了，其实checkpoint这个数据库概念引入的真正意义就是用来减小在数据库恢复过程当中所花的时间(instance recovery),那么checkpoint是又谁来作的呢？咱们都知道数据库中有个CKPT进程，这个是个可选进程，可是真正执行检查点的任务并非有ckpt来完成的，而是ckpt在更新控制文件和数据文件头的有关信息后，通知DBWn进程，产生一个检查点，在产生检查点的时候，DBWn进程会将buffer cache中的脏数据(当前online redo log对应的脏数据)，写入咱们的数据文件当中。那么这个时候若是数据库此时崩溃（好比咱们作个shutdown abort），那么在进行实例恢复的时候就能够不须要当前online redo log的内容了，会很快就作完。所以ckpt进程只是个辅助进程，他的任务更多的是用来在系统作checkpoint的时候更新控制文件和数据文件头中的信息。其实在oracle 8i的时候呢，ckpt的任务通常都是由lgwr进程来完成，到了8i之后，随着CKPT进程的引入，lgwr的工做负担就减轻了不少(commit的速度加快了)

那么如何来产生检查点呢？

有三种方法，能够经过

1.alter system checkpoint

2.alter system switch logfile

3.DBWn进程写出脏块

SCN

在Oracle中理解为一个内部同步时钟，是系统改变号的缩写（system change number）,在Oracle数据库中咱们能够经过dbms_flashback包来查询当前系统的改变号：select dbms_flashback.get_system_change_number from dual;通常来说SCN主要是用来标识数据库所作的全部改变，这个SCN的改变是只能前进，不能回退，除非咱们打算重建库，数据库中的SCN永远不会归0，通常来讲SCN的前进触发是由commit来进行的，除了这些据我观察每隔3秒种系统也都会刷新一次SCN.

须要注意的是：

1.CKPT必定是是在checkpoint发生的时候将数据库当前的SCN更新入数据库文件头和控制文件当中，同时DBWn进程将buffer cache中的脏数据块（dirty block）写到数据文件当中(这个脏数据也必定是当前online redo log保护的那一部分)。2.同时CKPT进程还会在控制文件当中记录(redo block address)RBA，这个地址用来标志恢复的时候须要从日志中的那个位置开始。

在Oracle数据库中和checkpoint相关的SCN总共有4个

1.System checkpoint SCN (存在于控制文件)

在系统执行checkpoint后，Oracle会更新当前控制文件中的System checkpoint SCN。

咱们能够经过

select checkpoint_change# from v$database:

来查看

2.Datafile checkpoint SCN (存在于控制文件)

因为控制文件中记录了Oracle中各个数据库文件的位置和信息，其中固然也包括了Datafile checkpoint SCN，所以在执行checkpoint的时候，Oracle还会去更新控制文件中所记录的各个数据文件的datafile checkpoint SCN.

咱们能够经过

select checkpoint_change# from v$datafile;

来查看

3.Start SCN (存在于各个数据文件头)

在执行checkpoint时，Oracle会更新存放在各个实际的数据文件头的Start SCN（注意绝对不会是控制文件中），这个SCN存在的目的是用于检查数据库启动过程当中是否须要作media recovery(介质恢复)

咱们能够经过

select checkpoint_change# from v$datafile_header;

4.End SCN(存在于控制文件)

最后一类SCN,End SCN他也是记录在控制文件当中，每个所记录的数据文件头都有一个对应的End SCN,这个End SCN必定是存在于控制文件当中。这个SCN存在的绝对意义主要是用来去验证数据库启动过程当中是否须要作instance recovery。咱们能够经过

select name,last_change# from v$datafile

那么其实在数据库正常运行的状况下，对于read/write的online 数据文件这个SCN号为#FFFFFF(NULL).

下面来聊一聊SCN号于数据库的启动

1.在数据库的启动过程当中，当System Checkpoint SCN=Datafile Checkpoint SCN=Start SCN的时候，Oracle数据库是能够正常启动的，而不须要作任何的media recovery。而若是三者当中有一个不一样的话，则须要作media recovery

2.那何时须要作instance recovery呢？其实在正常open数据库的时候，oracle会将记录在控制文件中的每个数据文件头的End SCN都设置为#FFFFFF(NULL)，那么若是数据库进行了正常关闭好比(shutdown or shutdown immediate)这个时候，系统会执行一个检查点，这个检查点会将控制文件中记录的各个数据文件头的End SCN更新为当前online数据文件的各个数据文件头的Start SCN,也就是End SCN=Start SCN,若是再次启动数据库的时候发现两者相等，则直接打开数据库，并再次将End SCN设置为#FFFFFF(NULL),那么若是数据库是异常关闭，那么checkpoint就不会执行，所以再次打开数据库的时候End SCN<>Start SCN这个时候就须要作实例恢复。

说了那么多更新SCN操做什么的，这个更新操做究竟是由谁作的呢？其实刚才已经说过了，就是咱们的CKPT进程，他不只仅会更新SCN，并且还会通知DBWn作他的事情。

再说一下System Checkpoint SCN和Datafile Checkpoint SCN,这两个SCN都是记录在控制文件当中的。可是这两个SCN有什么做用呢？

logzgh有段论述，我本身的想了一下，仍是学习一下他的结论：

1.对只读表空间，其数据文件的Datafile Checkpoint SCN、Start SCN和END SCN号均相同。这三个SCN在表空间处于只读期间都将被冻结。

2.若是控制文件不是当前的控制文件(其实就是说，想比当前redo log的SCN来说，控制文件已通过时了)，则System checkpoint SCN会小于Start SCN(Start SCN是来自实际的数据文件头，有比较依据)。记录这些SCN号，能够区分控制文件是不是当前的控制文件。当有一个Start SCN(从当前各个在线数据文件中得到)号超过了System Checkpoit SCN号时，则说明控制文件不是当前的控制文件，所以在作recovery时须要采用using backup controlfile。这是为何须要记录SystemCheckpoint SCN的缘由之一。

当咱们重建控制文件的时候，重建方式分两种（resetlogs 和 noresetlogs）

1.使用resetlogs选项时，System Checkpoint SCN为被归为0，而其中记录的各个数据文件的Datafile Checkpoint SCN则来自于Start SCN（也就是说可能会从冷备份的数据文件的数据文件头中获取）。根据上述的描述，此时须要采用using backup controlfile作recovery. 所以状况是 System Checkpoint SCN=0 < Start SCN = Datafile Checkpoint SCN

2.使用noresetlogs选项时，有一个前提就是：必定要有online redo log的存在。不然就要使用resetlogs选项。这个时候控制文件重建好时，其system checkpoint SCN=Datafile Checkpoint SCN=Lastest Checkpoint SCN in online redo log,咱们能够看到Datafile Checkpoint SCN并无从Start SCN中读取。而是读取了最新的日志文件中的SCN做为本身的数据。此时重建的控制文件在恢复中的做用跟最新的控制文件相似，System Checkpoint SCN(已经读取最新的redo log的checkpoint SCN信息)可能会>Start SCN （由于数据文件可能会从冷备份中恢复），恢复时就不须要加using backup controlfile子句了

关于backup controlfile的补充：backup controlfile只有备份时刻的archive log信息，并无DB crash时刻的archive log信息，因此并不会自动应用online redo log,而是提示找不到序号为Lastest Archive log sequence + 1 的archive log,尽管你能够手动指定online redo log来实现彻底恢复，但由于一旦使用了using backup controlfile子句，Oracle就视为不彻底恢复，必须open resetlogs! 实际上，假如你有旧的控制文件又不想resetlogs，那很简单，使用旧的控制文件mount而后 backup to trace ，而后手工建立控制文件，使用 reuse database ... noresetlogs .这样就能够 recover database 自动恢复并open database 而不用 resetlogs 了