一、CHECKPIONT分为三类：

1）局部CHECKPIONT：
单个实例执行数据库所有数据文件的一个CHECKPIONT操作，属于此实例的全部脏缓存区写入数据文件。
触发命令：SQL>alter system checkpoint local;
这条命令显示的触发一个局部检查点。

2）全局CHECKPIONT：
所有实例（对应并行数据服务器）执行数据库所有数据文件的一个CHECKPIONT操作，属于此实例的全部脏缓存区写入数据文件。
触发命令：SQL>alter system checkpoint global;
这条命令显示的触发一个全局检查点。

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

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

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

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

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

5）更新控制文件与数据文件。
注：控制文件与数据文件头包含CHECKPIONT结构信息。
 
三、CHECKPIONT事件

CHECKPIONT事件是数据库的一个很重要的内部事件，只有了解它的运行机制，才能很好的掌握数据库的内部运行，才能很好的掌握备份与恢复，也才能在紧急的时候解决必要的问题……

CHECKPIONT事件的触发，将使得数据库将已经修改的数据（脏数据）写到磁盘，同时还将修改控制文件和数据库头，同步它们的scn号，它的触发条件是：
当发生日志组切换的时候
当符合LOG_CHECKPOINT_TIMEOUT，LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target参数设置的时候
当运行ALTER SYSTEM SWITCH LOGFILE的时候
当运行ALTER SYSTEM CHECKPOINT的时候
当运行alter tablespace XXX begin backup，end backup的时候
当运行alter tablespace ,datafile offline的时候;
运行alter tablespace、datafile offline的时候，它们存在着一定的区别：
alter datafile offline：
在offline、online的时候，系统将不会修改所有datafile的scn
alter tablespace offline：
offline的事件，就会修改scn号；在online的时候，系统也将修改该ts下的所有datafile的scn
这正是为什么online datafile需要recovery，而online tablespace就不需要。

其实当检查点发生的时候，CKPT获取发生检查点时对应的SCN，通知DBWn要写到这个SCN为止，CKPT将最近一次(可能是上次也可能是上上次)DBWn成功完成写Dirty Buffer时对应的SCN更新到控制文件和数据文件头 (增量检查点时不写数据文件头)。至此检查点事件完成。剩下的工作就交给DBWn了。期间，CKPT检查checkpoint queue(也就是脏块链表)是否过长，如果是，则触发DBWn，DBWn将开始工作，他将一部分脏块写入数据文件，从而缩短checkpoint queue。但是为了恢复过程的迅速，CKPT进程以3秒的频率将DBWn写的进度反应到控制文件中，就是CKPT进程每三秒钟向控制文件写一次DBWn的执行情况，也就是把DBWn当前刚写完的dirty buffer对应的scn 写入数据文件头和控制文件。因此，可以看出，CKPT更新数据文件和控制文件，不是使用当前检查点的scn，而是使用上一次检查点过程中DBWn进程成功写完成dirty buffer队列中某个block 对应的scn 。

如果在DBWn写dirty buffer时候，发生掉电，则恢复过程肯定是：首先从控制文件中找到，上次检查点发生后最后成功写入那个block块对应的scn往后进行恢复。也就是CKPT进程在掉电前那最后一个三秒钟轮回，向控制文件写如的scn为恢复的前界限，往后进行恢复。

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

在两种情况下，文件头中的检查点信息（获取当前检查点信息时）将不做更新：
1）数据文件不处于热备份方式，此时ORACLE将不知道操作系统将何时读文件头，而备份拷贝在拷贝开始时必须具有检查点SCN；ORACLE在数据文件头中保留一个检查点的记数器，在正常操作中保证使用数据文件的当前版本，在恢复时防止恢复数据文件的错误版本；即使在热备份方式下，计数器依然是递增的；每个数据文件的检查点计数器，也保留在控制文件相对应数据文件项中。
2）检查SCN小于文件头中的检查点SCN的时候，这表明由检查点产生的改动已经写到磁盘上，在执行全局检查点的处理过程中，如果一个热备份快速检查点在更新文件头时，则可能发生此种情况。应该注意的是，ORACLE是在实际进行检查点处理的大量工作之前捕获检查SCN的，并且很有可能被一条象热备份命令 alter tablespace USERS begin backup进行快速检查点处理时的命令打断。

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

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

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

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

算法特点：
1）DBWR能确切的知道为满足检查点请求需要写那些缓存区；
2）在每次进行检查点写时保证指向完成最早的（具有最低重做值的）检查点；
3）根据检查点重做值可以区别多个检查点请求，然后按照它们的顺序完成处理