Checkpoint之一

在Oracle中进行数据修改时，首先将数据读取到内存中（buffer cache），修改数据的同时oracle会记录重做（redo）用于恢复，所以不必再事务提交（commit）时将数据写回到磁盘。重做日志也使在数据库在崩溃之后可以恢复。检查点的存在就是为了缩短恢复的时间。

我们看一下检查点的scn：

SQL> select file#, checkpoint_change#,to_char(checkpoint_time, 'yyyy-mm-dd hh24-mi-ss') CPT
  2  from v$datafile;

     FILE# CHECKPOINT_CHANGE# CPT
---------- ------------------ -------------------
         1            1020756 2009-07-15 20-55-20
         2            1020756 2009-07-15 20-55-20
         3            1020756 2009-07-15 20-55-20
         4            1020756 2009-07-15 20-55-20
         5            1020756 2009-07-15 20-55-20
         6            1020756 2009-07-15 20-55-20

6 rows selected.

 

  1  select dbid, checkpoint_change#
  2* from v$database
SQL> /

      DBID CHECKPOINT_CHANGE#
---------- ------------------
3312617616            1020756

 

检查点的频率对数据库恢复的时间具有很大的影响，如果检查点的频率高，那么恢复所需的时间就比较短，但是频繁的检查点会带来性能的问题。

 

在之前，我们讲的都是常规检查点，自从oracle 8 之后引入了增量检查点。

在数据库内部，每个脏数据块都会被记录到检查点队列中，按照LRBA（low RBA，redo byte address）。CKPT在进行轻量级更新的时候，并不会改写控制文件的数据文件检查点以及数据文件头信息,而只是记录控制文件检查点并根据增量检查点来确定恢复的起点。

在oracle10g中除了检查点队列还有文件检查点队列（FILEQ）和对象检查点队列（OBJQ）。每个文件都包含一个FILEQ，在执行表空间检查请求时需要使用FILEQ，通常当表空间执行offline时候触发。

这些队列以链表的形式组织的，通过下面的转储buffer cache信息可以看出：

bash-3.00$ grep ckptq uep_ora_561.trc | grep -v NULL
      ckptq: [563eb8cc,55ff17b8] fileq: [563eb8d4,55ff17c0] objq: [55ff183c,563eb950]
      ckptq: [5b7f5b38,6058e580] fileq: [5b7f5b40,6058e5a8] objq: [5ef3007c,5b7f5bbc]
      ckptq: [5b7f645c,5a3ec2a4] fileq: [57fe9444,5a3ec2ac] objq: [5efb0678,5efb0678]
      ckptq: [55ff1434,59fef1c0] fileq: [6058c62c,5a3e6258] objq: [5efb0ee8,5efb0ee8]
      ckptq: [59fedb40,5a3e6250] fileq: [59bf797c,59ff4bc8] objq: [5efb0fd8,5efb0fd8]
      ckptq: [5a3ec2a4,5aff1920] fileq: [5a3e6258,5aff1928] objq: [57feea88,5aff129c]
      ckptq: [57feea04,5aff1380] fileq: [5b7f5ec4,55ff1928] objq: [55ff19a4,5b7f5f40]
      ckptq: [59fede10,5a3eb764] fileq: [59fede18,59fe8b20] objq: [5efb10c8,5efb10c8]
      ckptq: [5b7f5d54,55ff1920] fileq: [57feea0c,6058e594] objq: [5ef4b284,57feea88]
      ckptq: [59fef5f8,55ff7104] fileq: [5aff9ca4,5aff1220] objq: [5ef5b794,5ef5b794]
      ckptq: [55ff1650,57fe943c] fileq: [59fef1c8,57fe9444] objq: [5ef5aee8,5ef5aee8]
      ckptq: [5aff9c9c,59fede10] fileq: [6058e5bc,59fede18] objq: [59fede94,5efb0f60]
      ckptq: [5b7f5bec,5b7f591c] fileq: [5b7f5bf4,5b7f5924] objq: [5b7f59a0,5b7f5c70]
      ckptq: [59fe8b18,55ff14e8] fileq: [5b7f5924,55ff14f0] objq: [55ff1788,55ff16d4]
      ckptq: [6058c618,59bf618c] fileq: [6058c640,55ff143c] objq: [5b7f5d24,5b7f5bbc]
      ckptq: [5b7f591c,6058e580] fileq: [59fef600,6058e5bc] objq: [5ef5b398,5ef5b398]
      ckptq: [5a3eb764,55ff186c] fileq: [5b7f5ca8,55ff1874] objq: [55ff18f0,55ff14b8]
      ckptq: [59bf3c48,59bf4350] fileq: [59bf3c50,59bf4358] objq: [5efb036c,5efb036c]

 

再看一下控制文件以及增量检查点协同工作，转储两次控制文件后比较：

bash-3.00$ diff uep_ora_691.trc uep_ora_735.trc
1c1
< /export/home/oracle/admin/uep/udump/uep_ora_691.trc
---
> /export/home/oracle/admin/uep/udump/uep_ora_735.trc
13c13
< Unix process pid: 691, image: oracle@liweiah (TNS V1-V3)
---
> Unix process pid: 735, image: oracle@liweiah (TNS V1-V3)
15,17c15,16
< *** 2009-07-15 22:47:52.552
< *** SERVICE NAME:(SYS$USERS) 2009-07-15 22:47:52.552
< *** SESSION ID:(159.18) 2009-07-15 22:47:52.552
---
> *** SERVICE NAME:(SYS$USERS) 2009-07-15 22:55:55.147
> *** SESSION ID:(159.42) 2009-07-15 22:55:55.147
95,97c94,96
< THREAD #1 - status:0x2 flags:0x0 dirty:59
< low cache rba:(0x11.5a20.0) on disk rba:(0x11.5ad8.0)
< on disk scn: 0x0000.000fa8d8 07/15/2009 22:47:25
---
> THREAD #1 - status:0x2 flags:0x0 dirty:37
> low cache rba:(0x11.5b21.0) on disk rba:(0x11.5b7f.0)
> on disk scn: 0x0000.000fa9b8 07/15/2009 22:55:51
99c98
< heartbeat: 692284131 mount id: 3314504111
---
> heartbeat: 692284290 mount id: 3314504111

 

可以看到，dirty buffer从59降到37，low cache rba从0x11.5a20.0增进到0x11.5b21.0。low cache rba是前滚恢复的起点，on disk rba是已经写入磁盘的rba地址，这是前滚恢复能够到达的终点。

后面是个heartbeat信息，每隔3秒更新一次验证实例存活。

 

通过上面分析可以看到，增量检查点可以连续进行，所以检查点rba可以比常规检查点更接近数据库的最后状态，减少恢复和似箭。

 

从oracle8i开始，完全检查仅仅在以下两种情况出现：

alter system checkpoint；

shutdown（除abort方式外）；

log switch通常是出发增量检查点，但是log switch触发检查点会促使数据文件头与控制文件信息同步。

 

 

在数据库open之后，可以看到Controlfile Checkpointed at scn:  0x0000.001000fd 07/16/2009 10:23:49是等于on disk scn: 0x0000.001000fd 07/16/2009 10:23:47的，标志了恢复的终点，即最新的redo日志。