1.检查点（Checkpoint）的本质
许多文档把Checkpint描述得非常复杂，为我们正确理解检查点带来了障碍，结果现在检查点变成了一个非常复杂的问题。实际上，检查点只是一个数据库事件，它存在的根本意义在于减少崩溃恢复（Crash Recovery）时间。
当修改数据时，需要首先将数据读入内存中（Buffer Cache），修改数据的同时，Oracle会记录重做信息（Redo）用于恢复。因为有了重做信息的存在，Oracle不需要在提交时立即将变化的数据写回磁盘（立即写的效率会很低），重做（Redo）的存在也正是为了在数据库崩溃之后，数据就可以恢复。
最常见的情况，数据库可以因为断电而Crash，那么内存中修改过的、尚未写入文件的数据将会丢失。在下一次数据库启动之后，Oracle可以通过重做日志（Redo）进行事务重演，也就是进行前滚，将数据库恢复到崩溃之前的状态，然后数据库可以打开提供使用，之后Oracle可以将未提交的数据进行回滚。
在这个过程中，通常大家最关心的是数据库要经历多久才能打开。也就是需要读取多少重做日志才能完成前滚。当然用户希望这个时间越短越好，Oracle也正是通过各种手段在不断优化这个过程，缩短恢复时间。
检查点的存在就是为了缩短这个恢复时间。
当检查点发生时（此时的SCN被称为CheckPoint SCN），Oracle会通知DBWR进程，把修改过的数据，也就是Checkpoint SCN之前的脏数据（Dirty Data）从Buffer Cache写入磁盘，当写入完成之后，CKPT进程更新控制文件和数据文件头，记录检查点信息，标识变更。
Oracle SCN的相关知识可以参考我的另外一篇文章：DBA入门之认识Oracle SCN（System Change Number）
Checkpoint SCN可以从数据库中查询得到：
SQL> select file#,CHECKPOINT_CHANGE#,to_char(CHECKPOINT_TIME,'yyyy-mm-dd hh24:mi:ss') cpt from v$datafile;
FILE# CHECKPOINT_CHANGE# CPT
---------- ------------------ -------------------
1 913306 2011-11-16 16:06:06
2 913306 2011-11-16 16:06:06
3 913306 2011-11-16 16:06:06
4 913306 2011-11-16 16:06:06
SQL> select dbid,CHECKPOINT_CHANGE# from v$database;
DBID CHECKPOINT_CHANGE#
---------- ------------------
1294662348 913306
在检查点完成之后，此检查点之前修改过的数据都已经写回磁盘，重做日志文件中的相应重做记录对于崩溃/实例恢复不再有用。
下图标记了3个日志组，假定在T1时间点，数据库完成并记录了最后一次检查点，在T2时刻数据库Crash。那么在下次数据库启动时，T1时间点之前的Redo不再需要进行恢复，Oracle需要重新应用的就是时间点T1至T2之间数据库生成的重做日志（Redo）。
上图可以很轻易地看出来，检查点的频率对于数据库的恢复时间具有极大的影响，如果检查点的频率高，那么恢复时需要应用的重做日志就相对得少，检查时间就可以缩短。然而，需要注意的是，数据库内部操作的相对性极强，国语平凡的检查点同样会带来性能问题，尤其是更新频繁的数据库。所以数据库的优化是一个系统工程，不能草率。
更进一步可以知道，如果Oracle可以在性能允许的情况下，使得检查点的SCN主键逼近Redo的最新更新，那么最终可以获得一个最佳平衡点，使得Oracle可以最大化地减少恢复时间。
为了实现这个目标，Oracle在不同版本中一直在改进检查点的算法。
2.常规检查点与增量检查点
为了区分，在Oracle8之前，Oracle实时的检查点通常被称为常规检查点（Conventional Checkpoint）,这类检查点按一定的条件出发（log_checkpoint_interval、log_checkpoint_timeout参数设置及log switch等条件出发）。
从Oracle 8开始，Oracle引入了增量检查点（Inctrmental Checkpoint）的概念。
和以前的版本相比，在新版本中，Oracle主要引入了检查点队列（Checkpoinnt Queue）机制，在数据库内部，每一个脏数据块都会被移动到检查点队列，按照Low RBA的顺序（第一次对比数据块修改对应的Redo Byte Address）来排列，如果一个数据块进行过多次修改，该数据库在检查点队列上的顺序并不会发生变化。
当执行检查点时，DBWR从检查点队列按照Low RBA的顺序写出，实例检查点因此可以不断增进、阶段性的，CKPT进程使用非常轻量级的控制文件更新协议，将当前的最低RBA写入控制文件。
因为增量检查点可以连续地进行，因此检查点RBA可以比常规检查点更接近数据库的最后状态，从而在数据库的实例恢复中可以极大地减少恢复时间。
而且，通过增量检查点，DBWR可以持续进行写出，从而避免了常规检查点出发的峰值写入对于I/O的国度征用，通过下图可以清楚地看到这一改进的意义。
在数据库中，增量检查点是通过Fast-Start Checkpointing特性来实现的，从Oracle 8i开始，这一特性包含了Oracle企业版的Fast-Start Fault Recovery组件之中，通过查询v$option视图，了解这一特性：
SQL> select * from v$version where rownum<2;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – Prod
SQL> col parameter for a30
SQL> col value for a20
SQL> select * from V$option where Parameter='Fast-Start Fault Recovery';
PARAMETER VALUE
------------------------------ --------------------
Fast-Start Fault Recovery TRUE
该组件包含3个主要特性，可以加快系统在故障后的恢复，提高系统的可用性。
Fast-Start Checkpointing;
Fast-Start On-Demand Rollback;
Fast-Start Parallel Rollback;
Fast-Start Checkpointing 特性在Oracle 8i中主要通过参数FAST_START_IO_TARGET来实现，在Oracle 9i中，Fast-Start Checkpointing主要通过参数FAST_START_MTTR_TARGET来实现。
3.FAST_START_MTTR_TARGET
FAST_START_MTTR_TARGET参数从Oracle 9i开始被引入，该参数定义数据库进行Crash恢复的时间，单位是秒，取值范围是在0~3600秒之间。
在Oracle 9i中，Oracle推荐设置这个参数代替FAST_START_IO_TARGE、LOG_CHECKPOINT_TIMEROUT及LOG_CHECKPOINT_INSTERVAL参数。
缺省情况下，在Oracle 9i中，FAST_START_IO_TARGET和LOG_CHECKPOINT_INTERVAL参数已经被设置为0.
SQL> show parameter fast_start_io
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_io_target integer 0
SQL> show parameter interval
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_checkpoint_interval integer 0
在Oracle 9i R2开始，Oracle引入了一个新的视图提供MTTR建议：
SQL> select * from v$mttr_target_advice;
MTTR_TARGET_FOR_ESTIMATE ADVICE_STATUS DIRTY_LIMIT ESTD_CACHE_WRITES ESTD_CACHE_WRITE_FACTOR ESTD_TOTAL_WRITES ESTD_TOTAL_WRITE_FACTOR ESTD_TOTAL_IOS ESTD_TOTAL_IO_FACTOR
------------------------ ------------- ----------- ----------------- ----------------------- ----------------- ----------------------- -------------- --------------------
该视图评估在不同FAST_START_MATTR_TARGET设置下，系统需要执行的I/O次数等操作。用户可以根据数据库的建议，对FAST_START_MTTR_TARGET进行相应调整。
这个建议信息的手机收到Oracle 9i新引入的初始化参数statistics_level的控制，当该参数设置为Typical或ALL时，MTTR建议信息被手机：
SQL> show parameter statistics_level
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
statistics_level string TYPICAL
也可以通过v$statistics_level视图来查询MTTR_Advice的当前设置：
SQL> select * from v$statistics_level where STATISTICS_NAME='MTTR Advice';
STATISTICS_NAME DESCRIPTION SESSION_STATUS SYSTEM_STATUS ACTIVATION_LEVEL STATISTICS_VIEW_NAME SESSION_SETTABLE
---------------------------------------------------------------- -------------------------------------------------------------------------------- -------------- ------------- ---------------- ---------------------------------------------------------------- ----------------
MTTR Advice Predicts the impact of different MTTR settings on number of physical I/Os ENABLED ENABLED TYPICAL V$MTTR_TARGET_ADVICE NO
数据库当前的实例恢复状态可以通过视图v$instance_recovery查询得到：
SQL> select * from v$instance_recovery;
RECOVERY_ESTIMATED_IOS 53
ACTUAL_REDO_BLKS 376
TARGET_REDO_BLKS 184320
LOG_FILE_SIZE_REDO_BLKS 184320
LOG_CHKPT_TIMEOUT_REDO_BLKS
LOG_CHKPT_INTERVAL_REDO_BLKS
FAST_START_IO_TARGET_REDO_BLKS
TARGET_MTTR 0
ESTIMATED_MTTR 18
CKPT_BLOCK_WRITES 27
OPTIMAL_LOGFILE_SIZE
ESTD_CLUSTER_AVAILABLE_TIME
WRITES_MTTR 0
WRITES_LOGFILE_SIZE 0
WRITES_LOG_CHECKPOINT_SETTINGS 0
WRITES_OTHER_SETTINGS 0
WRITES_AUTOTUNE 104
WRITES_FULL_THREAD_CKPT 0
从v$instance_recovery视图，可以看到当前数据库估计的平均恢复时间（MTTR）参数：ESTIMATED_MTTR。
ESTIMATED_MTTR的估算值是基于Dirty Buffer 的数据量和日志块数量得出的，这个参数值告诉我们，如果此时数据库本亏，那么进行实例恢复将会需要的时间。
在V$instance_revovery视图中，TARGET_MTTR代表的是期望的恢复时间，通常改参数应该等于FAST_START_MTTR_TARGET参数设置值（但是如果FAST_START_MTTR_TARGET参数定义的值极大或极小，TARGET_MEER可能不等于FAST_START_MTTR_TARGET的设置）。
当ESTIMATED_MTTR接近或超过FAST_START_MTTR_TARGET参数设置（v$instance_recovery TARGET_MTTR）时，系统就会促发检查点，执行写出之后，系统恢复信息将会重新计算：
RECOVERY_ESTIMATED_IOS 24
ACTUAL_REDO_BLKS 43
TARGET_REDO_BLKS 184320
LOG_FILE_SIZE_REDO_BLKS 184320
LOG_CHKPT_TIMEOUT_REDO_BLKS
LOG_CHKPT_INTERVAL_REDO_BLKS
FAST_START_IO_TARGET_REDO_BLKS
TARGET_MTTR 0
ESTIMATED_MTTR 18
CKPT_BLOCK_WRITES 73
OPTIMAL_LOGFILE_SIZE
ESTD_CLUSTER_AVAILABLE_TIME
WRITES_MTTR 0
WRITES_LOGFILE_SIZE 0
WRITES_LOG_CHECKPOINT_SETTINGS 0
WRITES_OTHER_SETTINGS 0
WRITES_AUTOTUNE 183
WRITES_FULL_THREAD_CKPT 0
在繁忙的系统中，可能会观察到ESTIMATED_MTTR>TARGET_MTTR，这可能是因为DBWR正忙于写出，甚或出现Checkpoint不能及时完成的情况。
4. Oracle 10g自动检查点调整
从Oracle 10g开始，数据库可以实现自动调整的检查点，使用自动调整的检查点，Oracle数据库可以利用系统的低I/O负载时段写出内存中的脏数据，从而提高数据库的效率。因此，及时数据库管理员设置了不合理的检查点相关参数，Oracle仍然能够通过自动调整将数据库的Crash Recovery时间控制在合理的范围之内。
当FAST_START_MTTR_TARGET参数未设置，自动检查点调整生效。
通常，如果必须严格控制实例或节点恢复时间，那么可以设置FAST_START_MTTR_TARGET为期望时间值；如果恢复时间不严格控制，那么可以不设置FAST_START_MTTR_TARGET参数，从而启用Oracle 10g的自动调整特性。
当取消FAST_START_MTTR_TARGET参数设置之后：
SQL> show parameter fast_start_mttr
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
fast_start_mttr_target integer 0
在启动数据库的时候，可以从alter文件中看到如下信息：
Thu Nov 17 20:27:23 2011
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
检查v$instance_recovery视图，可以发现Oracle 10g的改变：
SQL> select * from v$instance_recovery;
RECOVERY_ESTIMATED_IOS 53
ACTUAL_REDO_BLKS 376
TARGET_REDO_BLKS 184320
LOG_FILE_SIZE_REDO_BLKS 184320
LOG_CHKPT_TIMEOUT_REDO_BLKS
LOG_CHKPT_INTERVAL_REDO_BLKS
FAST_START_IO_TARGET_REDO_BLKS
TARGET_MTTR 0
ESTIMATED_MTTR 18
CKPT_BLOCK_WRITES 27
OPTIMAL_LOGFILE_SIZE
ESTD_CLUSTER_AVAILABLE_TIME
WRITES_MTTR 0
WRITES_LOGFILE_SIZE 0
WRITES_LOG_CHECKPOINT_SETTINGS 0
WRITES_OTHER_SETTINGS 0
WRITES_AUTOTUNE 104
WRITES_FULL_THREAD_CKPT 0
在以上视图中，WRITES_AUTOTUNE字段数据就是指由于自动调整检查点执行的写出次数，而CK_BLOCK_WRITES指的则是由于检查点写出的Block的数量。
关于检查点的机制问题，我们侧重介绍了原理，至于具体的算法实现，不需要去追究过多，只要明白了这个原理性的规则，理解Oracle就会变成轻松的事情。
Oracle的算法改进是一种优化，对于数据库的调整优化也不外如此，借鉴Oracle的优化对于理解和优化Oracle数据库都具有极大的好处。
5.从控制文件获取检查点信息
在控制文件的转储中，可以看到关于检查点进程进度的记录：
***************************************************************************
CHECKPOINT PROGRESS RECORDS
***************************************************************************
(size = 8180, compat size = 8180, section max = 11, section in-use = 0,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 2, numrecs = 11)
THREAD #1 - status:0x2 flags:0x0 dirty:34
low cache rba:(0x23.19d5.0) on disk rba:(0x23.1a68.0)
on disk scn: 0x0000.000d847d 11/14/2011 15:25:37
resetlogs scn: 0x0000.0006ce7b 11/10/2011 22:40:23
heartbeat: 767211774 mount id: 1294947385
THREAD #2 - status:0x0 flags:0x0 dirty:0
low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
这里的low cache rba（Revovery block address）指在Cache中，最低的RBA地址，在实例恢复或者崩溃恢复中，需要从这里开始恢复。
On disk dba是磁盘上的最高的重做值，在进行恢复时应用重做至少要达到这个值。