oracle 检查点（checkpoint）

以下内容整理自网路，如有侵权，请联系我。

checkpoint扫盲

什么是checkpoint

在数据库系统中，写日志和写数据文件是数据库中IO消耗最大的两种操作，在这两种操作中写数据文件属于分散写，写日志文件是顺序写，因此为了保证数据库的性能，通常数据库都是保证在提交（commit）完成之前要先保证日志都被写入到日志文件中，而脏数据块着保存在数据缓存（buffer cache）中再不定期的分批写入到数据文件中。也就是说日志写入和提交操作是同步的，而数据写入和提交操作是不同步的。这样就存在一个问题，当一个数据库崩溃的时候并不能保证缓存里面的脏数据全部写入到数据文件中，这样在实例启动的时候就要使用日志文件进行恢复操作，将数据库恢复到崩溃之前的状态，保证数据的一致性。检查点是这个过程中的重要机制，通过它来确定，恢复时哪些重做日志应该被扫描并应用于恢复。

一般所说的checkpoint是一个数据库事件（event），checkpoint事件由checkpoint进程（LGWR/CKPT进程）发出，当checkpoint事件发生时DBWn会将脏块写入到磁盘中，同时数据文件和控制文件的文件头也会被更新以记录checkpoint信息。

checkpoint的作用

checkpoint主要2个作用：

1. 保证数据库的一致性，这是指将脏数据写入到硬盘，保证内存和硬盘上的数据是一样的；
2. 缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会很长，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。

通俗的说checkpoint就像word的自动保存一样。

检查点分类

• 完全检查点（Normal checkpoint）
• 增量检查点（Incremental checkpoint）

checkpoint相关概念术语

在说明checkpoint工作原理之前我们先了解一些相关的术语。

RBA（Redo Byte Address）, Low RBA（LRBA）, High RBA（HRBA）

RBA就是重做日志块（redo log block）的地址，相当与数据文件中的ROWID，通过这个地址来定位重做日志块。RBA由三个部分组成：

1. 日志文件序列号（4字节）——根据这个找到对应的日志文件地址。
2. 日志文件块编号（4字节）——根据这个找到对应日志条目所在的日志文件块。
3. 重做日志记录在日志块中的起始偏移字节数（2字节）——找到对应的日志条目。

通常使用RBA的形式有：

LRBA

数据缓存（buffer cache）中一个脏块第一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为LRBA。

HRBA

数据缓存（buffer cache）中一个脏块最近一次被更新的时候产生的重做日志记录在重做日志文件中所对应的位置就称为HRBA。

checkpoint RBA

当一个checkpoint事件发生的时候，checkpoint进程会记录下当时所写的重做日志块的地址即RBA，此时记录的RBA被称为checkpoint RBA。从上一个checkpoint RBA到当前的checkpoint RBA之间的日志所保护的buffer cache中的脏块接下来将会被写入到数据文件当中去。

Buffer checkpoint Queues （BCQ）

Oracle将所有在数据缓存中被修改的脏块按照LRBA顺序的组成一个checkpoint队列，这个队列主要记录了buffer cache第一次发生变化的时间顺序，然后有DBWn进程根据checkpoint队列顺序将脏块写入到数据文件中，这样保证了先发生变更的buffer能先被写入到数据文件中。BCQ的引入是为了支持增量checkpoint的。

Active checkpoint Queue （ACQ）

ACQ中包含了所有活动的checkpoint请求。每次有新checkpoint请求是都会在ACQ中增加一条记录，ACQ记录中包含了相应的checkpoint RBA。checkpoint完成以后相应的记录将被移出队列。

完全检查点 （normal checkpoint）

完全检查点工作过程

一个checkpoint操作可以分成三个不同的阶段：

• 第一阶段，checkpoint进程开始一个checkpoint事件，并记录下checkpoint RBA，这个通常是当前的RBA。
• 第二阶段，checkpoint进程通知DBWn进程将所有checkpoint RBA之前的buffer cache里面的脏块写入磁盘。
• 确定脏块都被写入磁盘以后进入到第三阶段，checkpoint进程将checkpoint信息（SCN）写入/更新数据文件和控制文件中。

更新SCN的操作由CKPT进程完成，在Oracle 8.0之后CKPT进程默认是被启用的，如果CKPT进程没有启用的话那相应的操作将由LGWR进程完成。

什么时候发生normal checkpoint

下面这些操作将会触发checkpoint事件：

• 日志切换，通过ALTER SYSTEM SWITCH LOGFILE。
• DBA发出checkpoint命令，通过ALTER SYSTEM checkpoint。
• 对数据文件进行热备时，针对该数据文件的checkpoint也会进行，ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。
• 当运行ALTER TABLESPACE/DATAFILE READ ONLY的时候。
• SHUTDOWN命令发出时。

特别注意：

1. 日志切换会导致checkpoint事件发生，但是checkpoint发生却不会导致日志切换。
2. 日志切换触发的是normal checkpoint，而不是大家所说的增量checkpoint，只不过log switch checkpoint的优先级非常低，当一个log switch checkpoint发生的时候它并不会立即的通知DBWn进程去写数据文件，但是当有其它原因导致checkpoint或者是写入数据文件的RBA超过log switch checkpoint的checkpoint RBA的时候，这次的log switch checkpoint将会被标记成完成状态，同时更新控制文件和数据文件头。我们随后可以做个实验验证这个说法。

checkpoint和SCN有什么关系？

在Oracle中SCN相当于它的时钟，在现实生活中我们用时钟来记录和衡量我们的时间，而Oracle就是用SCN来记录和衡量整个Oracle系统的更改。

Oracle中checkpoint是在一个特定的“时间点”发生的，衡量这个“时间点”用的就是SCN，因此当一个checkpoint发生时SCN会被写入文件头中以记录这个checkpoint。

增量checkpoint

增量checkpoint工作过程

因为每次完全的checkpoint都需要把buffer cache所有的脏块都写入到数据文件中，这样就是产生一个很大的IO消耗，频繁的完全checkpoint操作很对系统的性能有很大的影响，为此Oracle引入的增量checkpoint的概念，buffer cache中的脏块将会按照BCQ队列的顺序持续不断的被写入到磁盘当中，同时CKPT进程将会每3秒中检查DBWn的写入进度并将相应的RBA信息记录到控制文件中。（关于CKPT进程每3秒进行修改控制文件的测试：http://blog.csdn.net/changyanmanman/article/details/7362528）

有了增量checkpoint之后在进行实例恢复的时候就不需要再从崩溃前的那个完全checkpoint开始应用重做日志了，只需要从控制文件中记录的RBA开始进行恢复操作，这样能节省恢复的时间。

发生增量checkpoint的先决条件

• 恢复需求设定 （FAST_START_IO_TARGET/FAST_START_MTTR_TARGET）
• LOG_checkpoint_INTERVAL参数值
• LOG_checkpoint_TIMEOUT参数值
• 最小的日志文件大小
• buffer cache中的脏块的数量

增量checkpoint的特点

• 增量checkpoint是一个持续活动的checkpoint。
• 没有checkpoint RBA，因为这个checkpoint是一直都在进行的，所以不存在normal checkpoint里面涉及的checkpoint RBA的概念。
• checkpoint advanced in memory only
• 增量checkpoint所完成的RBA信息被记录在控制文件中。
• 增量checkpoint可以减少实例恢复时间。

增量checkpoint相关参数设置

log_checkpoint_interval

设定两次checkpoint之间重做日志块（重做日志块和系统数据块是一样的）数，当重做日志块数量达到设定值的时候将触发checkpoint。

log_checkpoint_timeout

设定两次checkpoint之间的间隔时间，当超时值达到时增量checkpoint将被触发。Oracle建议不用这个参数来控制，因为事务（transaction）大小不是按时间等量分布的。将此值设置成0时将禁用此项设置。

fast_start_io_target

因为log_checkpoint_interval主要看的时候重做日志块的数量，并不能反应buffer cache中脏数据块的修改，因此Oracle又引入了这个参数来实现当脏数据块达到一定数量的时候触发checkpoint，不过此参数实际上控制的是恢复时所需IO的数量。

fast_start_mttr_target

• 此参数是在9i中引入用来代替前面的三个参数的，它定义了数据块崩溃后所需要的实例恢复的时间，Oracle在实际上内在的解释成两个参数:fast_start_io_target和log_checkpoint_interval.如果这两个参数没有显式的指定,计算值将生效.。
• fast_start_mttr_target可以设定的最大值是3600，即一个小时。它的最小值没有设限，但是并不是说可以设置一个任意小的值，这个值会受最小dirty buffer（最小为1000）的限制，同时还会受初始化时间以及文件打开时间的限制。
• 在设置此参数的时候要综合考虑系统的IO，容量以及CPU等信息，要在系统性能和故障恢复时间之间做好平衡。
• 将此参数设置成0时将禁用 fast-start checkpointing，这样能见效系统负载但同时会增加系统的恢复时间。
• 如果fast_start_io_target or log_checkpoint_interval被指定，他们会自动覆盖由fast_start_mttr_target参数计算出来的值。

在10g中，数据库能根据各种系统参数的设置值来自动调整检查点的执行频率，以获得最好的恢复时间以及系统的正常运行影响最小。通过自动checkpoint调整，Orach能在系统低IO操作的时候将脏块写入到数据文件中，因此即时DBA没有设置checkpoint相关的参数值或是设置了一个不合理的值的时候系统还是能获得一个很合理的系统恢复时间。

10g中的增量checkpoint更能体现它持续活动的特点，在10g中，增量checkpoint不是在某一个特定的条件下触发，而是由数据库根据系统参数设置自动触发。

与完全checkpoint的区别

• 完全checkpoint会将checkpoint的信息写入到控制文件以及数据文件头中
• 增量checkpoint只会将RBA信息写入到控制文件中。

查看系统的checkpoint动作

我们可以通过将LOG_checkpointS_TO_ALERT设置成TRUE来打开checkpoint的trace，这样就可以跟踪checkpoint的操作了。

ALTER   SYSTEM   SET   LOG_checkpointS_TO_ALERT = TRUE ;

这设置以后系统的checkpoint将会被记录alert_$SID.log文件中。

在V$DATAFILE_HEADER里面也保存了发生完全checkpoint的时候一些相关信息，包括checkpoint发生时间、对应SCN已经checkpoint的次数。

select   file # NO, status, tablespace_name, name, dbms_flashback.get_system_change_number CUR_SCN,
   to_char （ resetlogs_time ,  ' YYYY-MM-DD HH24:MI:SS ' ）  RST_DT , resetlogs_change # RST_SCN,
   to_char （ checkpoint_time ,  ' YYYY-MM-DD HH24:MI:SS ' ）  CKPT_DT , checkpoint_change # CKPT_SCN, checkpoint_count CKPT_CNT
from   v $ datafile_header ;
 
/**
NO  STATUS  TABLESPACE_NAME  CUR_SCN  RST_DT              RST_SCN  CKPT_DT             CKPT_SCN  CKPT_CNT
--- ------- ---------------- -------- ------------------- -------- ------------------- --------- ---------
1   ONLINE  SYSTEM           533541   2008-01-12 16:51:53 446075   2008-08-04 22:03:58 532354    65
2   ONLINE  UNDOTBS1         533541   2008-01-12 16:51:53 446075   2008-08-04 22:03:58 532354    28
3   ONLINE  SYSAUX           533541   2008-01-12 16:51:53 446075   2008-08-04 22:03:58 532354    65
4   ONLINE  USERS            533541   2008-01-12 16:51:53 446075   2008-08-04 22:03:58 532354    64
5   ONLINE  EXAMPLE          533541   2008-01-12 16:51:53 446075   2008-08-04 22:03:58 532354    24
*/

完全检查点

-- 我们先执行一个
ALTER   SYSTEM   checkpoint ;
 
-- 下面是alert文件中的数据结果
Mon   Aug    4   22 : 22 : 08   2008
Beginning   global   checkpoint   up   to   RBA  [ 0 x8 . c9d4 .10 ],  SCN :  533714
Completed   checkpoint   up   to   RBA  [ 0 x8 . c9d4 .10 ],  SCN :  533714
-- 我们能看到完全checkpoint发生的SCN 533714
 
-- 下面我们再对照下V$DATAFILE_HEADER中的结果
NO    STATUS    TABLESPACE_NAME    CUR_SCN    RST_DT                RST_SCN   CKPT_DT               CKPT_SCN    CKPT_CNT
- -- ------- ---------------- -------- ------------------- -------- ------------------- --------- ---------
1     ONLINE    SYSTEM             533790     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 22 : 08   533714      66
2     ONLINE    UNDOTBS1           533790     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 22 : 08   533714      29
3     ONLINE    SYSAUX             533790     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 22 : 08   533714      66
4     ONLINE    USERS              533790     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 22 : 08   533714      65
5     ONLINE    EXAMPLE            533790     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 22 : 08   533714      25
 
-- 看到了么，checkpoint时间和checkpoint的SCN已经被记录到数据文件头中了。

日志切换时的检查点

-- 我们先做一次日志切换
ALTER   SYSTEM   SWITCH   LOGFILE ;
 
-- 然后看看alert里面的记录
Mon   Aug    4   22 : 31 : 39   2008
Beginning   log   switch   checkpoint   up   to   RBA  [ 0 x9 .2.10 ],  SCN :  534450
Thread   1   advanced   to   log   sequence   9
   Current   log # 2 seq# 9 mem# 0: /u/app/oracle/oradata/orcl/redo02.log
Mon   Aug    4   22 : 35 : 58   2008
Completed   checkpoint   up   to   RBA  [ 0 x9 .2.10 ],  SCN :  534450
 
-- 我们能看到checkpoint是在过了一段时间（这里是4分钟）之后才完成的
 
-- 接着我们来看下V$DATAFILE_HEADER中的结果
NO    STATUS    TABLESPACE_NAME    CUR_SCN    RST_DT                RST_SCN   CKPT_DT               CKPT_SCN    CKPT_CNT
- -- ------- ---------------- -------- ------------------- -------- ------------------- --------- ---------
1     ONLINE    SYSTEM             534770     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 31 : 44   534450      67
2     ONLINE    UNDOTBS1           534770     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 31 : 44   534450      30
3     ONLINE    SYSAUX             534770     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 31 : 44   534450      67
4     ONLINE    USERS              534770     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 31 : 44   534450      66
5     ONLINE    EXAMPLE            534770     2008 - 01 - 12   16 : 51 : 53   446075     2008 - 08 - 04   22 : 31 : 44   534450      26
 
-- 在这里我们能发现下V$DATAFILE_HEADER里面记录的SCN和日志切换发生的checkpoint的SCN是一样的，
-- 这就证明了日志切换是会更新数据文件头的，同时日志切换的checkpoint是一个级别比较低的操作，
-- 它不会立即完成，这也是出于性能上考虑的。

增量checkpoint查看

当前所知只有在LOG_checkpoint_TIMEOUT设置了非0值之后触发的增量checkpoint会在alert文件中有记录，其他条件触发的增量checkpoint都不会记录在alert文件中。

-- 下面是当LOG_checkpoint_TIMEOUT设置为1800s的时候所产生的增量checkpoint记录
Sun Aug  3 19:08:56 2008
Incremental checkpoint up to RBA [0x8.e17.0], current log tail at RBA [0x8.1056.0]
Sun Aug  3 19:39:00 2008
Incremental checkpoint up to RBA [0x8.1be0.0], current log tail at RBA [0x8.1c6e.0]
Sun Aug  3 20:09:04 2008
Incremental checkpoint up to RBA [0x8.2af5.0], current log tail at RBA [0x8.2b6a.0]
Sun Aug  3 20:39:07 2008
Incremental checkpoint up to RBA [0x8.3798.0], current log tail at RBA [0x8.3851.0]
Sun Aug  3 21:09:10 2008
Incremental checkpoint up to RBA [0x8.47b9.0], current log tail at RBA [0x8.48bb.0]
Sun Aug  3 21:39:14 2008
Incremental checkpoint up to RBA [0x8.548d.0], current log tail at RBA [0x8.5522.0]
Mon Aug  4 21:05:18 2008

查看fast_start_mttr_target

通过查看V$INSTANCE_RECOVERY动态性能视图可以查看一些MTTR相关的信息。

SELECT TARGET_MTTR,ESTIMATED_MTTR,CKPT_BLOCK_WRITES,CKPT_BLOCK_WRITES FROM V$INSTANCE_RECOVERY

TARGET_MTTR

用户设置的参数FAST_START_MTTR_TARGET的值.

ESTIMATED_MTTR

根据目前脏块数目和日志块数目,评估的现在进行恢复所需要的时间.

CKPT_BLOCK_WRITES

检查点写完的块数目.

CKPT_BLOCK_WRITES

额外的因为检查点引起的数据库写入操作 （因为不必要的检查点的产生,设置一个非常小的系统恢复时间将会对性能产生负面影响,为了帮助管理员监测这个参数设置较小时对数据库的影响,这个视图显示了这个列）

相关视图

V$视图

V$DATAFILE_HEADER

查看数据文件的完全checkpoint信息。

V$INSTANCE_RECOVERY

查看fast_start_mttr_target设置以及系统MTTR相关信息。

X$视图

X$BH

用于查看脏块的LRBA和HRBA（There is also a recovery RBA which is used to record the progress of partial block recovery by PMON.） 。

X$TARGETRBA

查看增量checkpoint RBA，target RBA和on-disk RBA。

X$KCCCP

这里面也有增量checkpoint RBA，target RBA的信息。

X$KCCRT

完全checkpoint（full thread checkpoint）RBA信息。

补充说明

写完这篇文章之后又看了写在itpub上的讨论，更新下观点。(http://www.itpub.net/viewthread.php?tid=1053847)

关于增量checkpoint和完全的checkpoint的区别这方面的争论里来不少，特别是对于日志切换到底是增量还是完全的争论更是如此，但是其实翻遍Oracle的文档就没有发现有提到增量checkpoint(incremental checkpoint)或是完全checkpoint(full checkpoint)这两个概念。

我的观点是根本就没有必要可以的区分是增量还是完全，真正要理解的是不同情况下的checkpoint都会有些什么样的行为，然后根据这些行为来对数据库进行配置，设置相应的参数，制定相应的备份/恢复策略，就此而已。
下面列出写常见的checkpoint行为：

1. 类似于alter system checkpoint这样的语句所产生的，先记录下当前的scn，然后推动DBWn进程去写脏数据，当写到所记录的scn时候检查点结束，然后ckpt进程将记录的scn写入到控制文件和数据文件头。
2. 设置参数log_checkpoint_timeout之后产生的，在超时值达到的时候，ckpt进程记录当时DBWn写脏数据的进度，也就是写到那个scn了，此时检查点信息只记录到控制文件中，同时如果设置了LOG_checkpointS_TO_ALERT的话我们会在alert中得到这样的信息：
   Sun Aug  3 19:08:56 2008
   Incremental checkpoint up to RBA [0x8.e17.0], current log tail at RBA [0x8.1056.0]
3. ckpt进程每3s起来一次记录checkpoint的进度到控制文件中，这种情况跟上面的类似，只不过在alert里面是看不到的，而且也不是每次唤醒都会写控制文件的，而是有就记，没有就拉倒。
4. 类似于alter system switch logfile所产生的，先记录下发出命令时刻的scn，ckpt进程不会推动DBWn去写脏数据，而是让DBWn按照自己的状态去写脏数据，等到写到记录的scn时，chpt进程再去更新控制文件和数据文件头。这种情况在alert也能看到信息：
   Mon Aug  4 22:31:39 2008
   Beginning log switch checkpoint up to RBA [0x9.2.10], SCN: 534450
   Thread 1 advanced to log sequence 9
     Current log# 2 seq# 9 mem# 0: /u/app/oracle/oradata/orcl/redo02.log
   Mon Aug  4 22:35:58 2008
   Completed checkpoint up to RBA [0x9.2.10], SCN: 534450

参考文档

• Metalink: Automatic checkpoint Tuning
• Metalink: checkpoint Tuning and Troubleshooting Guide
• Metalink: 8i Parameters that Influence checkpoints
• 《Oracle 9i&10G编程艺术》
• 《checkpointing in Oracle》
  /files/Checkpointing_in_Oracle.pdf
• Redo Byte Address （RBA）
  http://www.ixora.com.au/notes/rba.htm]
• 关于fast_start_io_target，log_checkpoint_interval，log_checkpoint_time的一点看法
  http://www.itpub.net/148219.html
• Oracle 9i新特性研究系列之七
  http://oracle.chinaitlab.com/serial/18638.html
• checkpoint说明
  http://airlgc.blog.51cto.com/161810/26175
• Oracle checkpoint
  http://www.adp-gmbh.ch/ora/concepts/checkpoint.html

由于 Oracle中LGWR和DBWR工作的不一致，Oracle引入了检查点的概念，用于同步 数据库，保证数据库的一致性。在Oracle里面，检查点分为两种：完全检查点和增量检查点。下面我们分别介绍这两种检查点的作用：

1、 完全检查点

在Oracle8i之前，数据库的发生的检查点都是完全检查点，完全检查点会将数据缓冲区里面所有的脏数据块写入相应的数据文件中，并且同步数据文件头和控制文件，保证数据库的一致。完全检查点在8i之后只有在下列两种情况下才会发生：

（1、）DBA手工执行alter system checkpoint的命令；

（2、）数据库正常shutdown（immediate,transcational,normal）。

由于完全检查点会将所有的脏数据库块写入，巨大的IO往往会影响到数据库的性能。因此Oracle从8i开始引入了增量检查点的概念。

2、 增量检查点
Oracle从8i开始引入了检查点队列这么一种概念，用于记录数据库里面当前所有的脏数据块的信息，DBWR 根据这个队列而将脏数据块写入到数据文件中。检查点队列按时间先后记录着数据库里面脏数据块的信息，里面的条目包含RBA（Redo Block Address，重做日志里面用于标识检查点期间数据块在重做日志里面第一次发生更改的编号）和数据块的数据文件号和块号。在检查点期间不论数据块更改几次，它在检查点队列里面的位置始终保持不变，检查点队列也只会记录它最早的RBA，从而保证最早更改的数据块能够尽快写入。当DBWR将检查点队列里面的脏数据块写入到数据文件后，检查点的位置也要相应地往后移。

先看一下checkpoint queue（检查点队列）的概念，检查点发生后，触发DBWn进程，ckpt获取发生检查点时对应的scn，通知DBWn要写到这个scn为止，DBWR与dirty buffer（脏数据缓冲区）是根据数据块被首次更改的时间顺序写出的，也就是说，数据块被更改后会进入一个检查点队列，DBWR进程就根据队列的顺序批量的写入到数据文件中，写到哪个数据块时，那个数据块的首次变化的scn就是当前所有数据文件block的最新scn，但是由于无法适时地的将dbwr进度记录下来，所以oracle选择了一些策略，其中就包括ckpt进程的检查点和心跳。

  检查点发生后，ckpt进程检查checkpoint queue是否过长，如果是，则触发dbwr，将一部分脏块写入数据文件，从而缩短checkpoint queue。

  checkpoint发生时，一方面通知dbwr进行下一批次的写操作，另一方面，oracle采用了一个心跳的概念，以3秒的频率将dbwr写的进度反应到控制文件中，也就是把dbwr刚写完的对应的数据块的scn写入数据文件头和控制文件，这就是检查点scn。这个3秒和增量检查点不是一个概念，3秒只是在控制文件中，ckpt进程去更新dbwr写到哪里了。这个对于ckpt进程来说叫做heartbeat（心跳）我们可以理解为每间隔3秒不停的检查并记录dbwr的进度。

检查点发生之后数据库的文件、控制处于一致状态含义 是不需要 进行介质恢复，只表示数据文件头一致但是并不表示数据文件内容一致，因为 数据文件内容可能在没有发生检查点的 其它情况下dbwr 写数 据文件，这样数据文件内容就不一致，若掉电需要进行崩溃恢复。

CKPT进程每三秒会在控制文件中记录检查点的位置，以表示Instance Recovery时开始恢复的日志条目，这个概念称为检查点的“心跳”（heartbeat）。检查点位置发生变更后，Oracle里面通过4个参数用于控制检查点位置和最后的重做日志条目之间的距离。在这里面需要指出的是，多数人会将这4个参数看作控制增量检查点发生的时间。事实上这是错误的，这4个参数是用于控制检查点队列里面的条目数量，而不是控制检查点的发生。

（1）、fast_start_io_target
该参数用于表示数据库发生Instance Recovery的时候需要产生的IO总数，它通过v$filestat的AVGIOTIM来估算的。比如我们一个数据库在发生Instance Crash后需要在10分钟内恢复完毕，假定OS的IO每秒为500个，那么这个数据库发生Instance Recovery的时候大概将产生500*10*60=30,000次IO，也就是我们将可以把fast_start_io_target设置为 30000。

（2）、fast_start_mttr_target
我们从上面可以看到fast_start_io_target来估算检查点位置比较麻烦。Oracle为了简化这个概念，从9i开始引入了 fast_start_mttr_target这么一个参数，用于表示数据库发生Instance Recovery的时间，以秒为单位。这个参数我们从字面上也比较好理解，其中的mttr是mean time to recovery的简写，如上例中的情况我们可以将fast_start_mttr_target设置为600。当设置了 fast_start_mttr_target后，fast_start_io_target这个参数将不再生效，从9i后 fast_start_io_target这个参数被Oracle废除了。

v$instance_recovery.estimated_mttr 显示当前估计需要恢复的秒数。这个值会 显示即使 FAST_START_MTTR_TARGET 没有被指定。 

v$instance_recovery.target_mttr 表明在短时间内 MTTR 的目标。 

v$mttr_target_advice显示这个当前 显示这个当前 MTTR 设置的 工作量产生I/O 数量和其他 I/O 。 这个视图帮助用户评定在优化和恢复之前的平衡

（3）、log_checkpoint_timeout
该参数用于表示检查点位置和重做日志文件末尾之间的时间间隔，以秒为单位，默认情况下是1800秒。

（4）、log_checkpoint_interval
该参数是表示检查点位置和重做日志末尾的重做日志块的数量，以OS块表示。

（5）、90% OF SMALLEST REDO LOG
除了以上4个初始化参数外，Oracle内部事实上还将重做日志文件末尾前面90%的位置设为检查点位置。在每个重做日志中，这么几个参数指定的位置可能不尽相同，Oracle将离日志文件末尾最近的那个位置确认为检查点位置。

oracle 9i instance recovery
1. 增量检查点
在checkpoint queue的基础上实现了增量检查点，每3秒发生一次checkpoint heartbeat，记录dbwr上次写成功的最大RBA(redo block address)。这样的话做instance recovery的时候就从这个rba开始，而不是从上次checkpoint scn开始，大大节省了恢复时间。
 
2. twice scan of redo log
在应用redo之前，redo将会被操作两次，第一次去扫描哪些redo record需要被应用，因为9i在redo里添加了dbwr写数据块的信息，所以dbwr发生前的日志将不会被应用。第二步就是选出需要被应用的日志然后开始rollforward。
 
3. rollforward
在做instance recovery时必须先定位到redo log 然后应用所有日志到datafile，这时候包括了committed和uncommitted的数据。当做完rollward，数据库就可以open了。
 
4. rollback
因 为rollforward产生了uncommitted数据，所以必须回滚这些数据。这将由smon和on-demand rollback来实现。smon将会扫描undo segment header去标志所有活动事务为dead，然后会逐渐去回滚这些事务。另外on-demand rollback提供了前台进程进行rollback，当前台进程企图获得被dead事务占用row lock，这时候前台进程将会去undo segment取得before image去回滚这个块，至于其他被这个dead事务lock的块就等待smon去回滚。
 
另外，如果 在数据库打开的过程中process crash导致transaction dead，resource不能被释放的情况，这时候如果另一个进程需要这些resource，那么这个进程将会等待直到pmon清理dead process释放出resource。

如果数据库Crash，重新启动，很久远以前的未提交事务并不在Redo的恢复序列中。
但是未提交事务一定在回滚段事务表上存在，并且State＝10，为活动事务。这就够了。

数据库启动之后，这些事务会被SMON逐个标记为Dead（不可能再活过来了），然后由SMON慢慢去回滚这些事务；也存在另外一种情况，后来的进程会去读这些未提交数据，发现Dead事务未提交，则主动进行回滚。

1. 一个数据块发生更新，必然写回滚
2. 回滚段的block变化也记录在redo中

一份未提交的数据必定在回滚中有相应的前镜像，任何正常的恢复都一定会把这些变化重新构建出来。

想像一下

1. update事务1更新了block 1
2. 回滚段1记录了block1的前镜像
3. checkpoint
4. update事务2更新了block2
5. 回滚段2记录了block2的前镜像
6. instance crash

现在重启数据库

1. 根据redo重新构建block2
2. 根据redo重新构建回滚段2
3. database open
4. SMON用回滚段2的数据回滚block2，SMON用回滚段1的数据回滚block1

最后一步也可能是
在另外一个select检索到block1或者block2的时候，发现这两个block的数据都是未提交的，此时再回滚block1和block2。

所以，只要有相应的回滚数据存在，无论什么时候oracle都可以找到一致的数据，oracle只需要知道这个事务是提交了的还是没提交了的，而这点在block header ITL中有记录。

 http://spaces.msn.com/roujiaweize/blog/cns!9745F14B4AEB3B72!328.entry

对SCN和CKPT的一点理解

scn (system change number，系统改变号)，它提供 oracle 的内部时钟机制，定义数据库在某个确切时刻提交的版本，其作用是维护数据库的数据的一致性。

ckpt (checkpoint，检查点)，它是一个数据库事件，它将已修改的数据从高速缓存刷新写入磁盘，并更新控制文件和数据文件。在一个检查点之后，重做日志文件中的重做记录对于崩溃/实例恢复不再有用。

控制文件为每个数据文件保存有一个：checkpoint scn， stop scn，只有数据文件中有 stop   scn
select name,checkpoint_change#,last_change# from v$datafile;

系统检查点 scn (这个看别人写的，不懂)
select checkpoint_change# from v$database;
当一个检查点动作完成后，oracle就把系统检查点的 scn存储到控制文件中。

数据文件头：数据库 checkpoint scn
select name,checkpoint_change# from v$datafile_header;(这个是数据库正常打开时从控制文件中查的，因为数据库正常打开时这两个相等，数据文件头真正的 scn，oracle自己读檔头)

控制文件为每个 redo线程保存有一个：checkpoint scn
select thread#,checkpoint_change# from v$thread;

当一个检查点动作完成后，oracle更新控制文件中的这些 checkpoint scn (控制檔中一个，所有数据文件头在控制文件中的存储，redo在控制文件中的信息)，以及数据文件头中的checkpoint scn。所以可以理解，上面这些值都是从控制檔中取出来的。

当数据库用 normal或者 immediate选项关闭时，执行检查点，更新控制文件中数据文件的 stop scn，等于数据文件头中的 checkpoint scn。

下次启动数据库时，oracle要进行两次检查。第一次看数据文件头中的 checkpoint scn与控制文件中数据文件的 checkpoint scn。如果相等，进行第二次检查，检查数据文件头中的checkpoint scn 与控制文件中数据文件的 stop scn。如果相等，不需要对这个檔恢复。每个数据文件都做这样的检查，然后打开数据库，将每个 stop scn 重新置为无穷大。

如果用 abort关闭数据库，则不执行检查点处理，控制文件中数据文件的 stop scn仍为无穷大。

下次启动时做两次检查。如第一次相等，再比较第二个。这时，数据文件头中的 checkpoint scn一定是小于控制文件中数据文件的 stop scn的，需要进行崩溃/实例恢复，进行前滚和回滚。

如果用备份代替了数据文件再启动数据库，这时做第一次检查时，数据文件头中的 checkpoint scn一定小于控制文件中数据文件的 checkpoint scn；或者用备份的控制檔代替了控制文件再启动数据库，这时数据文件头中的 checkpoint scn 一定大于控制文件中数据文件的 checkpoint scn。只要这两个不相等，就需要介质恢复。

还有一种情况，如果控制文件和数据文件都是备份的，而这两个 checkpoint scn正好相等，第一次比较通过，那么再看第二次比较了。其实这个时候在第一次比较之前，会先比较控制檔中 redo线程的 checkpoint scn的和 online log的 scn，如果相等，继续，如果不相等(小于)，提示控制檔是旧的需要介质恢复。