CKPT检查点队列

检查点是一个数据库事件，它把修改的数据从高速缓存写入磁盘，并更新控制文件和数据文件。

检查点分为三类：

1）局部检查点：单个实例执行数据库所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。

触发命令：

svmrgrl>alter system checkpoint local;

这条命令显示的触发一个局部检查点。

2）全局检查点：所有实例（对应并行数据服务器）执行数据库所有所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。

触发命令

svrmgrl>alter system checkpoint global;

这条命令显示的触发一个全局检查点。

3）文件检查点：所有实例需要执行数据文件集的一个检查点操作，如使用热备份命令alter tablespace USERS begin backup，或表空间脱机命令alter tablespace USERS offline，将执行属于USERS表空间的所有数据文件的一个检查点操作。


检查点处理步骤：

1）获取实例状态队列：实例状态队列是在实例状态转变时获得，ORACLE获得此队列以保证检查点执行期间，数据库处于打开状态；

2）获取当前检查点信息：获取检查点记录信息的结构，此结构包括当前检查点时间、活动线程、进行检查点处理的当前线程、日志文件中恢复截止点的地址信息；

3）缓存区标识：标识所有脏缓存区，当检查点找到一个脏缓存区就将其标识为需进行刷新，标识的脏缓存区由系统进程DBWR进行写操作，将脏缓存区的内容写入数据文件；

4）脏缓存区刷新：DBWR进程将所有脏缓存区写入磁盘后，设置一标志，标识已完成脏缓存区至磁盘的写入操作。系统进程LGWR与CKPT进程将继续进行检查，直至DBWR进程结束为止；

5）更新控制文件与数据文件。

注：控制文件与数据文件头包含检查点结构信息。


在两种情况下，文件头中的检查点信息（获取当前检查点信息时）将不做更新：

1）数据文件不处于热备份方式，此时ORACLE将不知道操作系统将何时读文件头，而备份拷贝在拷贝开始时必须具有检查点SCN；

ORACLE在数据文件头中保留一个检查点的记数器，在正常操作中保证使用数据文件的当前版本，在恢复时防止恢复数据文件的错误版本；即使在热备份方式下，计数器依然是递增的；每个数据文件的检查点计数器，也保留在控制文件相对应数据文件项中。

2）检查SCN小于文件头中的检查点SCN的时候，这表明由检查点产生的改动已经写到磁盘上，在执行全局检查点的处理过程中，如果一个热备份快速检查点在更新文件头时，则可能发生此种情况。应该注意的是，ORACLE是在实际进行检查点处理的大量工作之前捕获检查SCN的，并且很有可能被一条象热备份命令 alter tablespace USERS begin backup进行快速检查点处理时的命令打断。

ORACLE在进行数据文件更新之前，将验证其数据一致性，当验证完成，即更新数据文件头以反映当前检查点的情况；未经验证的数据文件与写入时出现错误的数据文件都被忽略；如果日志文件被覆盖，则这个文件可能需要进行介质恢复，在这种情况下，ORACLE系统进程DBWR将此数据文件脱机。


检查点算法描述：

脏缓存区用一个新队列链接，称为检查点队列。对缓存区的每一个改动，都有一个与其相关的重做值。检查点队列包含脏的日志缓存区，这些缓存区按照它们在日志文件中的位置排序，即在检查点队列中，缓存区按照它们的低重做值进行排序。需要注意的是，由于缓存区是依照第一次变脏的次序链接到队列中的，所以，如果在缓存区写出之前对它有另外的改动，链接不能进行相应变更，缓存区一旦被链接到检查点队列，它就停留在此位置，直到将它被写出为止。


ORACLE系统进程DBWR在响应检查点请求时，按照这个队列的低重做值的升序写出缓存区。每个检查点请求指定一个重做值，一旦DBWR写出的缓存区重做值等于或大雨检查点的重做值，检查点处理即完成，并将记录到控制文件与数据文件。

由于检查点队列上的缓存区按照低重做值进行排序，而DBWR也按照低重做值顺序写出检查点缓存区，故可能有多个检查点请求处于活动状态，当DBWR写出缓存区时，检查位于检查点队列前端的缓存区重做值与检查点重做值的一致性，如果重做值小于检查点队列前缓存区的低重做值的所有检查点请求，即可表示处理完成。当存在未完成的活动检查点请求时，DBWR继续写出检查点缓存区。



这里应该是只更新控制文件，每3秒不是更新数据文件

说 记录 checkpoint 的执行情况，这个说法，没错，但不够详细，应该说，由于增量检查点和 checkpoint queue 的原理，ckpt 进程每次只是告诉 dbwr ，写dirty buffer将要一直写到最新这个位置，仅仅是告诉 dbwr 一个 checkpoint queue 中的结束点，而 ckpt 每3秒中，在控制文件中报告一下 dbwr 最新写入的位置。 这样使得，比如数据库要做恢复的时候（instance recovery）可以从这个最新位置开始做恢复，而不是从数据文件中的 checkpoint scn 开始做恢复，这样将缩短恢复时间，尤其是 instance crash 的情况下启动更快


另外要注意的是，检查点发生的时候，ckpt 去更新数据文件头和控制文件，并不是把当前检查点发生时候的 scn 更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的 scn 更新进去 ，也就是说，更新控制文件和数据文件头 是 滞后于检查点的发生的，这个从恢复的原理也很容易理解，因为检查点发生的时候 dirty buffer还没有写入，自然不能立即更新成当前的 scn 了。


检查点的作用一是建立数据的一致性。二是为数据库作一个标记。表示数据库可以恢复的最大限度。

由他触发dbwn，把数据写入DATAFILE。再由dbwn触发LGWn把scn写入datafile和control file。



incremental checkpoint的是否应用和间隔时间或间隔的块数应该由FAST_START_IO_TARGET 或FAST_START_MTTR_TARGET参数决定吧。

只是默认的情况是3秒。

但如果指定了FAST_START_IO_TARGET 或LOG_CHECKPOINT_INTERVAL 这两个参数。则FAST_START_MTTR_TARGET就失效了。。


增量检查点本身并不是 3 秒，3秒也和增量检查点不是一个概念

3秒 只是在控制文件中，ckpt 进程去更新当前 dbwr写到哪里了，这个对于 ckpt 进程来说叫 heartbeat

3秒可以看作 不停的检查并记录 检查点执行情况（DBWR的写进度）

DBWn：数据库块写入器（Database Block Writer）负责将脏块写入磁盘的后台进程。


CKPT：检查点进程（Checkpoint Process）只是更新数据文件的文件首部，以辅助建立检查点的进程（DBWn）。


LGWR：日志写入器（Log Writer）负责将SGA中重做日志缓冲区的内容刷新输出到磁盘。


其实这三个进程都是为了更好地完成一件事：安全高效地实现内存数据块写入数据文件，就是将内存中修改的数据反映到硬盘的数据文件上。


将内存数据块写入数据文件实在是一个相当复杂的过程，在这个过程中，首先要保证安全。所谓安全，就是在写的过程中，一旦发生实例崩溃，要有一套完整的机制能够保证用户已经提交的数据不会丢失；其次，在保证安全的基础上，要尽可能地提高效率。众所周知，I/O操作是最昂贵的操作，所以应该尽可能地将脏数据块收集到一定程度以后，再批量写入磁盘中。


直观上最简单的解决方法就是，每当用户提交的时候就将所改变的内存数据块交给DBWn，由其写入数据文件。这样的话，一定能够保证提交的数据不会丢失。但是这种方式效率最为低下，在高并发环境中，一定会引起I/O方面的争用。Oracle当然不会采用这种没有伸缩性的方式。Oracle引入了CKPT和LGWR这两个后台进程，这两个进程与DBWn进程互相合作，提供了既安全又高效的写脏数据块的解决方法。


如何保证安全？


用户进程每次修改内存数据块时，都会在日志缓冲区（log buffer）中构造一个相应的重做条目（redo entry），该重做条目描述了被修改的数据块在修改之前和修改之后的值。而LGWR进程则负责将这些重做条目写入联机日志文件。只要重做条目进入了联机日志文件，那么数据的安全就有保障了，否则这些数据都是有安全隐患的。LGWR是一个必须和前台用户进程通信的进程。LGWR 承担了维护系统数据完整性的任务，它保证了数据在任何情况下都不会丢失。


假如DBWR在写脏数据块的过程中，突然发生实例崩溃时，该怎么办？我们已经知道，用户提交时，Oracle是不一定会把提交的数据块写入数据文件的。那么实例崩溃时，必然会有一些已经提交但是还没有被写入数据文件的内存数据块丢失了。当实例再次启动时，Oracle需要利用日志文件中记录的重做条目在buffer cache中重新构造出被丢失的数据块，从而完成前滚和回滚的工作，并将丢失的数据块找回来。于是这里就存在一个问题，就是Oracle在日志文件中找重做条目时，到底应该找哪些重做条目？换句话说，应该在日志文件中从哪个起点开始往后应用重做条目？注意，这里所指的日志文件可能不止一个日志文件。


这个起点意义重大，在日志文件中位于这个起点之前的重做条目所对应的在buffer cache中的脏数据块已经被写入了数据文件，从而在实例崩溃以后的恢复中不需要去考虑。而这个起点以后的重做条目所对应的脏数据块实际还没有被写入数据文件，如果在实例崩溃以后的恢复中，需要从这个起点开始往后，依次取出日志文件中的重做条目进行恢复。考虑到目前的内存容量越来越大，buffer cache也越来越大，buffer cache中包含几百万个内存数据块也是很正常的现象的前提下，如何才能最有效的来定位这个起点呢？


为了能够确定这个最佳的起点，Oracle引入了名为CKPT的后台进程，通常也叫作检查点进程（checkpoint process）。这个进程与DBWn共同合作，从而确定这个起点。同时，这个起点也有一个专门的名字，叫做检查点位置（checkpoint position，该检查点位置记录在控制文件里）。Oracle为了在检查点的算法上更加的具有可扩展性（也就是为了能够在巨大的buffer cache下依然有效工作），引入了检查点队列（checkpoint queue），该队列上串起来的都是脏数据块所对应的buffer header。而每次DBWn写脏数据块时，也是从检查点队列上扫描脏数据块，并将这些脏数据块实际写入数据文件的。当写完以后，DBWn会将这些已经写入数据文件的脏数据块从检查点队列上摘下来。这样即便是在巨大的buffer cache下工作，CKPT也能够快速的确定哪些脏数据块已经被写入了数据文件，而哪些还没有写入数据文件，显然，只要在检查点队列上的数据块都是还没有写入数据文件的脏数据块。同时为了能够尽量减少实例崩溃后恢复的时间，Oracle还引入了增量检查点（incremental checkpoint），www.linuxidc.com从而增加了检查点启动的次数。如果每次检查点启动的间隔时间过长的话，再加上内存很大，可能会使得恢复的时间过长。因为前一次检查点启动以后，标识出了这个起点。然后在第二次检查点启动之前，DBWn可能已经将很多脏数据块已经写入了数据文件，而假如在第二次检查点启动之前发生实例崩溃，导致在日志文件中，所标识的起点仍然是上一次检查点启动时所标识的，导致Oracle不知道这个起点以后的很多重做条目所对应的脏数据块实际上已经写入了数据文件，从而使得Oracle在实例恢复时重复地处理一遍，效率低下，浪费时间。


上面说到了有关CKPT的两个重要的概念：检查点队列（包括文件队列）和增量检查点。检查点队列上的buffer header是按照数据块第一次被修改的时间的先后顺序来排列的。越早修改的数据块的buffer header排在越前面，同时如果一个数据块被修改了多次的话，在该链表上也只出现一次。而且，检查点队列上的buffer header还记录了脏数据块在第一次被修改时，所对应的重做条目在重做日志文件中的地址，也就是LRBA（Low Redo Block Address），Low表示第一次修改时对应的RBA。每个检查点都会由checkpoint queue latch来保护。


上面所描述的概念，用一句话来概括，其实就是DBWn负责写检查点队列上的脏数据块，而CKPT负责记录当前检查点队列的第一个数据块所对应的的重做条目在日志文件中的地址。而到底应该写哪些脏数据块，写多少脏数据块，则要到检查点队列上才能确定的。


在Oracle中理解为一个内部同步时钟，是系统改变号的缩写（systemchange numb）

在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 ，然后手工创建控制文件，使用use database ... noresetlogs .这样就可以

recover database 自动恢复并open database 而不用 resetlogs 了

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30166976/viewspace-1486751/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30166976/viewspace-1486751/