一：什么是checkpoint?

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

二：什么时候发生checkpoint?

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

1.当发生日志组切换的时候

2.当符合LOG_CHECKPOINT_TIMEOUT，

LOG_CHECKPOINT_INTERVAL，fast_start_io_target,fast_start_mttr_target参数设置的时间

3.当运行ALTER SYSTEM SWITCH LOGFILE的时候

4.当运行ALTER SYSTEM CHECKPOINT的时候

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

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

三：相关参数

先来看看这几个参数在官方文档中定义是怎样的

FAST_START_MTTR_TARGET

Property

Description

Parameter type                         Integer

Default value                          0

Modifiable                             ALTER SYSTEM       

Range of values                        0 to 3600 seconds

Basic                                  No

Real Application Clusters              Multiple instances can have different values, and you can change the values at runtime.

FAST_START_MTTR_TARGET enables you to specify the number of seconds the database takes to perform. crash recovery of a single instance. When specified, FAST_START_MTTR_TARGET is overridden by LOG_CHECKPOINT_INTERVAL.

LOG_CHECKPOINT_INTERVAL

Property

Description

Parameter type                            Integer

Default value                             0

Modifiable                                ALTER SYSTEM

Range of values                           0 to 231 - 1

Basic                                     No

Real Application Clusters                 Multiple instances can have different values.

LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints in terms of the number of redo log file blocks that can exist between an incremental checkpoint and the last block written to the redo log. This number refers to physical operating system blocks, not database blocks.

Regardless of this value, a checkpoint always occurs when switching from one online redo log file to another. Therefore, if the value exceeds the actual redo log file size, checkpoints occur only when switching logs. Checkpoint frequency is one of the factors that influence the time required for the database to recover from an unexpected failure.

Notes:

·Specifying a value of 0 (zero) for LOG_CHECKPOINT_INTERVAL has the same effect as setting the parameter to infinity and causes the parameter to be ignored. Only nonzero values of this parameter are considered meaningful.

·Recovery I/O can also be limited by setting the LOG_CHECKPOINT_TIMEOUT parameter or by the size specified for the smallest redo log. For information on which mechanism is controlling checkpointing behavior, query the V$INSTANCE_RECOVERY view.

LOG_CHECKPOINT_TIMEOUT--指定checkpoint发出的时间间隔

Property                  Description

Parameter type            Integer

Default value             1800

Modifiable                ALTER SYSTEM

Range of values           0 to 231 - 1

Basic                     No

Real Application Clusters Multiple instances can have different values.

LOG_CHECKPOINT_TIMEOUT specifies (in seconds) the amount of time that has passed since the incremental checkpoint at the position where the last write to the redo log (sometimes called the tail of the log) occurred. This parameter also signifies that no buffer will remain dirty (in the cache) for more than integer seconds.

Specifying a value of 0 for the timeout disables time-based checkpoints. Hence, setting the value to 0 is not recommended unless FAST_START_MTTR_TARGET is set.

Notes:

·A checkpoint scheduled to occur because of this parameter is delayed until the completion of the previous checkpoint if the previous checkpoint has not yet completed.

·Recovery I/O can also be limited by setting the LOG_CHECKPOINT_INTERVAL parameter or by the size specified for the smallest redo log. For information on which mechanism is controlling checkpointing behavior, query the V$INSTANCE_RECOVERY view.

实际上还有一个参数FAST_START_IO_START，不过我在我的10G官方文档Reference中已经找不到了，估计已经不支持了吧。在一个帖子里看到过一个朋友写过关于FAST_START_IO_START、LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT这三者的区别，觉得挺好的，在这里引用一下。

#########################################################################

首先明确几个概念：

1．Data block 是包含几个os block，也就是一对多的关系。

2．Data files 中的是 data block

　　Redo log files 中的 redo block 是os block

3．Data block 中记录的是完整的信息

Redo block 中记录的是最简单的信息

在8i 以前的版本，只有两个参数用来影响recovery，那就是log_checkpoint_interval和log_checkpoint_time。以log_checkpoint_interval=10000举例。意思很简单，就是经过10000个redo block后就引发checkpoint,这样恢复时，就绝对是在这10000个redo block中。　　

　　但是这样做有个缺点，就是因为redo block（os block）不等于data block。假如datablock中的数据很小，比如1，修改成2，那么10000个redo block中包含的信息却可以是远远大于10000个data block，假如data block中的数据很大，比如123456789，修改成987654321，那么10000个redo block中包含的信息却可以是远远小于10000个data block。

　　这样，在恢复时，尽管是读10000个redo blcok，但是这个10000个redo block中所包含的data block有可能是很少，也有可能是很多，很难把握恢复的时间。

　　于是，在8i中就引进了fast_start_io_target这个参数来弥补这个不足。计算机自动计算redo block中所包含的data block的多少。例如fast_start_io_target=10000，t1（第一次checkpoint），在t1后有5000个redo block记录了，但是这个5000个redo block中只包含了7000个data block，那么redo block继续记录，到了redo block到8000个时，计算机发现这8000个redo block中包含了10000个data block，那么就引起t2（第二次checkpoint），凡是在t1和t2之间的任何crash，都可以保证recovery的时间肯定在这 10000个data block的读写时间之内（因为1个data block的I/O 是可以估算的）

　　所以说，设置fast_start_io_target比设置log_checkpoint_interval，log_checkpoint_time这个两个参数更为准确。假如3个参数一起设置，那么只要达到任一参数值时，就引发checkpoint。

　　例如：fast_start_io_target=10000，log_checkpoint_interval=10000，log_checkpoint_time=1800。

　　在redo block=10000时，所包含的data block却只有8000，就触发log_checkpoint_interval

　　在redo block=8000时，所包含的data block 却有10000，就触发fast_start_io_target

############################################################################################

他这里说说的log_checkpoint_time估计就是log_checkpoint_timeout，因为我在文档里也查不到log_checkpoint_time了，呵呵。

而现在一般都推荐使用FAST_START_MTTR_TARGET参数，直接将ORACLE在恢复的过程中花费的时间限定在一个特定的时间段内。

然而我在查看我数据库中此参数的时候又产生了新的疑惑

SQL> show parameter mttr

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

fast_start_mttr_target               integer     0

SQL>

为什么我的fast_start_mttr_target 会是0呢？如果是0的话，那么我数据库启动时进行恢复的时间又是被哪种机制来控制的呢？总不能无限期长时间恢复吧？上网搜到EYGLE写过的一篇文章，这里涉及到一个新的概念：自动调整的检查点

下面摘取文章中部分内容看看

############################################################################################

从Oracle10gR2开始，数据库可以实现自动调整的检查点.

使用自动调整的检查点，Oracle数据库可以利用系统的低I/O负载时段写出内存中的脏数据，从而提高数据库的效率。

因此，即使数据库管理员设置了不合理的检查点相关参数，Oracle仍然能够通过自动调整将数据库的Crash Recovery时间控制在合理的范围之内。

当FAST_START_MTTR_TARGET参数未设置时，自动检查点调整生效。

通常，如果我们必须严格控制实例或节点恢复时间，那么我们可以设置FAST_START_MTTR_TARGET为期望时间值；如果恢复时间不需要严格控制，那么我们可以不设置FAST_START_MTTR_TARGET参数，从而启用Oracle10g的自动检查点调整特性。

当取消FAST_START_MTTR_TARGET参数设置之后：

SQL> show parameter fast_start_mttr

NAME            TYPE        VALUE

------------------------------------ -----------

fast_start_mttr_target               integer     0

在启动数据库的时候，我们可以从alert文件中看到如下信息：

Wed Jan 11 16:28:12 2006

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

检查v$instance_recovery视图，我们可以发现Oracle10g中的改变：

SQL> select RECOVERY_ESTIMATED_IOS REIOS,TARGET_MTTR TMTTR,

  2  ESTIMATED_MTTR EMTTR,WRITES_MTTR WMTTR,WRITES_OTHER_SETTINGS WOSET,

  3  CKPT_BLOCK_WRITES CKPTBW,WRITES_AUTOTUNE WAUTO,WRITES_FULL_THREAD_CKPT WFTCKPT

  4  from v$instance_recovery;

     REIOS      TMTTR      EMTTR      WMTTR      WOSET     CKPTBW      WAUTO    WFTCKPT

---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------

     49407          0         68          0          0    3649819    3506125    3130700

在以上视图中，WRITES_AUTOTUNE字段值就是指由于自动调整检查点执行的写出次数，而CKPT_BLOCK_WRITES指的则是由于检查点写出的Block的数量。

#########################################################################

了解了吧，这里虽然我的FAST_START_MTTR_TARGET没有设置，值为0，可是ORACLE是会通过自动检查点调整特性来控制启动时恢复的时间的，使它不会太久。

文档中还有两个相关的参数，既然写了，在这里也顺便提一下吧。

LOG_CHECKPOINTS_TO_ALERT

Property                  Description

Parameter type            Boolean

Default value             false

Modifiable                ALTER SYSTEM

Range of values           true | false

Basic                     No

LOG_CHECKPOINTS_TO_ALERT lets you log your checkpoints to the alert file. Doing so is useful for determining whether checkpoints are occurring at the desired frequency.

FAST_START_PARALLEL_ROLLBACK

Property                 Description

Parameter type           String

Syntax                   FAST_START_PARALLEL_ROLLBACK = { HI | LO | FALSE }

Default value            LOW

Modifiable               ALTER SYSTEM

Basic                    No

FAST_START_PARALLEL_ROLLBACK determines the maximum number of processes that can exist for performing parallel rollback. This parameter is useful on systems in which some or all of the transactions are long running.

Values:

FALSE indicates that parallel rollback is disabled

LOW limits the number of rollback processes to 2 * CPU_COUNT

HIGH limits the number of rollback processes to 4 * CPU_COUNT

第一个参数LOG_CHECKPOINTS_TO_ALERT就不说了，我们来看看第二个参数FAST_START_PARALLEL_ROLLBACK。

讲到这个参数，就不能不谈一下INSTANCE RECOVERY的过程。

Instance and crash recovery occur in two steps: cache recovery followed by transaction recovery.

看一下CACHE RECOVERY都做了些什么

The database can be opened as soon as cache recovery completes, so improving the performance of cache recovery is important for increasing availability.

The duration of cache recovery processing is determined by two factors: the number of data blocks that have changes at SCNs higher than the SCN of the checkpoint, and the number of log blocks that need to be read to find those changes.

Frequent checkpointing writes dirty buffers to the datafiles more often than otherwise, and so reduces cache recovery time in the event of an instance failure. If checkpointing is frequent, then applying the redo records in the redo log between the current checkpoint position and the end of the log involves processing relatively few data blocks. This means that the cache recovery phase of recovery is fairly short.

However, in a high-update system, frequent checkpointing can reduce runtime performance, because checkpointing causes DBWn processes to perform. writes.

从这里可以看到，CHECKPOINT也并不是越频繁越好，当然，也不是间隔越久越好，关键是要根据系统的具体情况来把握一个合理的“度”。

Cache Recovery (Rolling Forward)

During the cache recovery step, Oracle applies all committed and uncommitted changes in the redo log files to the affected data blocks. The work required for cache recovery processing is proportional to the rate of change to the database (update transactions each second) and the time between checkpoints.

     Transaction Recovery (Rolling Back)

To make the database consistent, the changes that were not committed at the time of the crash must be undone (in other words, rolled back). During the transaction recovery step, Oracle applies the rollback segments to undo the uncommitted changes.

ORACLE在恢复的过程中，首先读取日志，从最后完成的检查点开始，应用所有重做记录，这个过程成为前滚。也就是CACHE RECOVERY过程，完成前滚之后，就可以打开数据库提供访问和使用了。

此后进入实例恢复的第二阶段，ORACLE回滚未提交的事务，也就是TRANSACTION RECOVERY。ORACLE使用两个特点来增加这个恢复阶段的效率，这两个特点是FAST-START ON-DEMAND ROLLBACK和FAST-START PARALLEL ROLLBACK（这些特点是FAST-START FAULT RECOVERY的组成部分，仅在oracle 8i之后的企业版中可用）。

使用FAST-START ON-DEMAND ROLLBACK特点，ORACLE自动允许在数据库打开之后开始新的事务，这通常只需要很短的CACHE RECOVERY时间。如果一个用户试图访问被异常中止进程锁定的记录，ORACLE回滚那些新事务请求的记录，也就是说，因需求而回滚。因而，新事务不需要等待漫长的事务回滚时间。在FAST-START ON-DEMAND ROLLBACK中，后台进程SMON充当一个调度员，使用多个服务器进程并行回滚一个事务集。

FAST-START PARALLEL ROLLBACK主要对于长时间运行的未提交事务有效，尤其是并行INSERT,UPDATE和DELETE操作。SMON自动决定何时开始并行回滚并且自动在多个进程之间分散工作。

FAST-START PARALLEL ROLLBACK的一个特殊形式是内部事务恢复(INTRA-TRANSACTION RECOVERY)。在内部事务恢复中，一个大的事务可以被拆分，分配给几个服务器进程并行回滚。这个时候就可以通过我们前面说到的那个FAST_START_PARALLEL_ROLLBACK来控制并行回滚。

前面还涉及到一个概念，FAST-START FAULT RECOVERY，在这里引用网上一个朋友的文章简单的解释一下。

######################################################

从Oracle8i开始，Oracle在企业版中引入了Fast-Start Fault Recovery选项。

该选项包含三个主要增强:

1.Fast-Start Checkpointing

2.Fast-Start On-Demand Rollback

3.Fast-Start Parallel Rollback.

这三个选项，都是为了加快系统在故障后的恢复，提高系统的可用性。

从v$option视图中，我们可以找到这个选项:

SQL> select * from v$version where rownum <2;

BANNER

----------------------------------------------------------------

Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

SQL> select * from v$option

   2   where Parameter='Fast-Start Fault Recovery';

PARAMETER                                           VALUE

-------------------------------------------------- ---------------

Fast-Start Fault Recovery                           TRUE

######################################################

在使用FAST_START_MTTR_TARGET的时候需要注意的事情

You must disable or remove the FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL, and LOG_CHECKPOINT_TIMEOUT initialization parameters when using FAST_START_MTTR_TARGET. Setting these parameters interferes with the mechanisms used to manage cache recovery time to meet FAST_START_MTTR_TARGET.

Practical Values for FAST_START_MTTR_TARGET

The maximum value for FAST_START_MTTR_TARGET is 3600 seconds (one hour). If you set the value to more than 3600, then Oracle rounds it to 3600.

四：增量检查点（incremental checkpoint）

oracle8以后推出了incremental checkpoint的机制，在以前的版本里每次checkpoint时都会做一个full thread checkpoint,这样的话所有脏数据会被写到磁盘，巨大的i/o对系统性能带来很大影响。为了解决这个问题，oracle引入了checkpoint queue机制，每一个脏块会被移到检查点队列里面去，按照low rdb（第一次对此块修改对应的redo block address）来排列，靠近检查点队列尾端的数据块的low rba值是最小的，而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变，这样就保证了越早修改的块越早写入磁盘。每隔3秒钟ckpt会去更新控制文件和数据文件，记录checkpoint执行的情况。

增量检查点并不去更新数据文件头，只是在控制文件中记录了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 了。

四：数据字典

完全检查点

select * from X$KCCRT where indx=0;

ADDR           INDX    INST_ID      RTNUM      RTSTA RTCKP_SCN        RTCKP_TIM             RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB         RTOTF      RTOTB      RTNLF      RTLFH      RTLFT      RTCLN      RTSEQ RTENB            RTETS    RTDIS            RTDIT                     RTLHP RTSID            RTOTS

-------- ---------- ---------- ---------- ---------- ---------------- -- --------------------

4084B228          0          1          1         15 720368521        06/25/2004 18:49:37           1           949             2     16 0600000000000000          2          0          3          1          3          1        949 1                05/16/2004 13:29:03  0                                               1389 tbdb2in1         06/12/2004 12:30:50

这里显示了上一次的完全检查点是在06/25/2004 18:49:37发生，所以我们推断06/25/2004 18:49:37发生了一次日志切换，再去操作系统上去看生产的归档，果然18：49有一个归档生产。

-rw-r-----    1 oracle   oinstall 83532800 Jun 25 18:49 1_948.dbf

增量检查点

SQL> select * from X$KCCCP where indx=0;

ADDR           INDX    INST_ID      CPTNO      CPSTA      CPFLG      CPDRT      CPRDB CPLRBA_SEQ CPLRBA_BNO CPLRBA_BOF  CPODR_SEQ  CPODR_BNO  CPODR_BOF CPODS                CPODT                   CPODT_I      CPHBT CPRLS                 CPRLC      CPMID  CPSDR_SEQ  CPSDR_BNO  CPSDR_ADB

-------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------

4084B45C          0          1          1          2          0      10762      29753        949      76847          0        949     106814              0 721554970        06/25/2004 21:05:10   529794310  529036227 1                 526310932 1413781667        949              1          0

这里显示了low-rba,on-disk rba,checkpoint time等信息。

案例分析：

各位前辈，看到此章，非常有感，，，

但有一事请各位帮忙，我们单位现在数据库老是有时快，有时慢，是不是跟这个有关系。我该从哪方面开始查！

答：不能肯定是他拉，你慢是指什么意思？是不是同一个语句有时慢有时快吗，如果是这样，那要结合你的statspack来分析，一般来说每个应用都有高峰期和低峰期，看你慢的时候，你的事务量是不是很高（可以在这段时间增加statspack的频率），load的情况如何，是不是有什么耗资源的应用定期在跑（找出这些语句，需要优化他），每秒的重做量是不是很高。io的使用情况，是不是有很多序列读等待还是序列写等待，来合理优化索引

  你说的检查点是不是是一个可能的原因，当然有可能，如果没有合理的设置log_buffer大小，logfile放在读写比较差的磁盘上，检查点的频繁程度，合理设置fsfr_start_mttr_target,看看在statspack中存在下面的等待事件

1.log file switch(archiving needed)

     日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题，

  可增大日志文件和增加日志组，调整log_archive_max_processes(checkpoint incomplete)

     当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成，  通常是io有严重问题，可增大日志文件和增加日志组

2.log file sync(这个到可能是log_buffer太大的反作用)

     当用户commit的时候通知lgwr写日志，但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时间太长（可能是因为一次log io size 太大），可调整 _log_io_size，

结合log_buffer,使得

(_log_io_size*db_block_size)*n = log_buffer,

这样可避免和增大log_buffer引起冲突;

 放置日志文件于高速磁盘上

3.log file single write

     指出写入到日志文件的标题块.可能表示检查点中等待

4.另外dbwr写是不是存在瓶径

cache buffers lru chain  是否需要增加

需要异步IO吗还是增加从dbwr

问一下，上面说了ckpt每隔3秒只是更新了控制文件的checkpoint progress record这个区域，那么它是什么时候进行数据文件更新的？当更新了控制文件后，正在更新数据文件时，掉电，会出现什么样的情况呢？

答：数据文件是有dbwr来写的，跟ckpt并没有实质关系。更新控制文件是在更新数据文件之后的动作，所以不用担心，这个时候断电会从上次的ckpt点开始恢复。