Oracle 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信息记录到控制文件中。
 
有了增量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的次数。
 

selectfile# 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_CNTfromv$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 */
 
 完全检查点
 

-- 我们先执行一个ALTERSYSTEMcheckpoint;
 
-- 下面是alert文件中的数据结果
 
 MonAug  422:22:082008
 
 BeginningglobalcheckpointuptoRBA [0x8.c9d4.10], SCN: 533714
 
 CompletedcheckpointuptoRBA [0x8.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-1216:51:53446075   2008-08-0422:22:08533714    662 
 
 2    ONLINE  UNDOTBS1               533790   2008-01-1216:51:53446075   2008-08-0422:22:08533714    293
 
 3    ONLINE  SYSAUX                    533790   2008-01-1216:51:53446075   2008-08-0422:22:08533714    664 
 
 4    ONLINE  USERS                      533790   2008-01-1216:51:53446075   2008-08-0422:22:08533714    655 
 
 5    ONLINE  EXAMPLE                  533790   2008-01-1216:51:53446075   2008-08-0422:22:08533714    25
 
 -- 看到了么，checkpoint时间和checkpoint的SCN已经被记录到数据文件头中了。
 
 日志切换时的检查点
 

-- 我们先做一次日志切换ALTERSYSTEMSWITCHLOGFILE;
 
   -- 然后看看alert里面的记录
 
 MonAug  422:31:392008BeginninglogswitchcheckpointuptoRBA [0x9.2.10], SCN: 534450
 
 Thread1advancedtologsequence9 
 
 Currentlog# 2 seq# 9 mem# 0: /u/app/oracle/oradata/orcl/redo02.log
 
 MonAug  422:35:582008CompletedcheckpointuptoRBA [0x9.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 
 
 1    ONLINE  SYSTEM                   534770   2008-01-1216:51:53446075   2008-08-0422:31:44534450    67 
 
 2    ONLINE  UNDOTBS1               534770   2008-01-1216:51:53446075   2008-08-0422:31:44534450    30 
 
 3    ONLINE  SYSAUX                   534770   2008-01-1216:51:53446075   2008-08-0422:31:44534450    67
 
 4    ONLINE  USERS                     534770   2008-01-1216:51:53446075   2008-08-0422:31:44534450    66 
 
 5    ONLINE  EXAMPLE                  534770   2008-01-1216:51:53446075   2008-08-0422:31:44534450    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