一：什么是checkpoint?
checkpoint是一个数据库事件，它将已修改的数据从高速缓存刷新到磁盘，并更新控制文件和数据文件。

二：检查点分为几类？

检查点分为三类：
1）局部检查点：单个实例执行数据库所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。alter system checkpoint local;这条命令显示的触发一个局部检查点。
2）全局检查点：所有实例（对应并行数据服务器）执行数据库所有所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件。alter system checkpoint global;这条命令显示的触发一个全局检查点。
3）文件检查点：所有实例需要执行数据文件集的一个检查点操作，如使用热备份命令alter tablespace USERS begin backup，或表空间脱机命令alter tablespace USERS offline，将执行属于USERS表空间的所有数据文件的一个检查点操作。

增量检查点与完全检查点：
当执行增量检查点时，控制文件会将检查点队列中的脏块顺序写入数据文件，I/O较小，不会对数据库性能造成影响。

增量检查点并不去更新数据文件头，只是在控制文件中记录了checkpoint progress record这个区域，记下low rba,on-disk rba等信息。这些信息就可以用来快速恢复。

而执行完全检查点时，则会将数据缓冲区的全部脏块立刻写入数据文件，此时I/O较大，会对数据库性能造成一些影响。

三：什么时候发生checkpoint?
我们知道了checkpoint会刷新脏数据，但什么时候会发生checkpoint呢？以下几种情况会触发checkpoint。

1.当发生日志组切换的时候（或手动执行alter system switch logfile），会执行增量检查点。

当日志需要切换时，LGWR会将当前日志组状态从current变为active，而inactive的日志组会变为current，来继续记录日志，变为active的日志陆续将脏块写入数据文件，
此时的日志是不能记录的，当active的日志组把所有缓冲区日志都写入数据文件后会执行检查点操作，active会变为inactive，此时就又可以继续接收日志了。

2.当符合log_checkpoint_timeout，log_checkpoint_interval，fast_start_io_target,fast_start_mttr_target参数设置的时候

log_checkpoint_timeout 表示两次增量检查点之间的间隔时间，默认1800秒，当到达时间点时，会触发增量检查点进行更新。

log_checkpoint_interval 就是数据库根据上一次checkpoint的位置，根据log_checkpoint_interval所指定的数据块的大小，决定在下一次在那里发生checkpoint的位置。
具体何时发生还要参考其他参数，但最多不能超过这个值。

fast_start_io_targetoracle 系统崩溃或例程恢复时需要的IO数量，值是从0到1000，oracle已经建议弃用该参数替代参数为:fast_start_mttr_target。很明显，IO次数难以计算，还是用时间参数比较容易。

fast_start_mttr_target 是一个加快实例恢复的参数，我们可以根据服务级别来定义一个合理的、可接受的值，该值的单位为秒。比如设定为60s，即2分钟。
假定该值处于合理的情况之下，则一旦实例崩溃，在60s以内实例应当能够被恢复。合理即是该值不能太大，也不能太小。太大则实例恢复所需的时间较长，太小则导致大量数据的及时写入，增加了系统的I/O。
默认0表示不启动该功能。

默认值如下：
SQL> show parameter log_checkpoint;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------
log_checkpoint_interval              integer     0
log_checkpoint_timeout               integer     1800
log_checkpoints_to_alert             boolean     FALSE
SQL> show parameter fast;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------
fast_start_io_target                 integer     0
fast_start_mttr_target               integer     0
fast_start_parallel_rollback         string      LOW

3.当手动运行ALTER SYSTEM CHECKPOINT的时候或者shutdow时，此时会执行完整检查点。

4.当运行alter tablespace XXX begin backup，end backup的时候

6.当运行alter tablespace ,datafile offline的时候;

三：触发检查点时都发生了什么？

触发检查点进程（ckpt）时，会更新系统中相关的SCN号，使二者保持一致。

控制文件中的数据文件检查点SCN（select checkpoint_change# from v$datafile）
数据文件中的数据文件头SCN（select checkpoint_change# from v$datafile_header）。

并不是所有检查点进程触发时，都会更新系统中相关的SCN号，准确说只有执行完整检查点时，才会这样做，而只有ALTER SYSTEM CHECKPOINT或者shutdow时，才会执行完整检查点。

而如果是增量检查点，每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。
则ckpt只是在控制文件中记录了checkpoint progress record这个区域，记下low rba,on-disk rba等信息。这些信息就可以用来快速恢复。

（解释）每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。
这里应该是只更新控制文件，每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 了。

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