影响Incremental checkpoint position的条件

一:fast_start_io_target,这个参数在9i中被废了，所以不讨论了，而且在10gR2的官方文档中也找不到此参数的任何信息，不过可以show parameter看到此参数。

二:log_checkpoint_timeout,该参数默认值为1800 seconds，也就是说每个半小时会执行一次incremental checkpoint，注意观察alert log的告警信息(想要在alert log中看到此信息，需要设置log_checkpoints_to_alert=TRUE)，每个半小时就会执行一次Incremental checkpoint。

Mon Dec 28 13:11:32 2009
Incremental checkpoint up to RBA [0x4e.1b8c.0], current log tail at RBA [0x4e.1c82.0]
Mon Dec 28 13:41:38 2009
Incremental checkpoint up to RBA [0x4e.20c8.0], current log tail at RBA [0x4e.21c4.0]
Mon Dec 28 14:11:45 2009
Incremental checkpoint up to RBA [0x4e.2b39.0], current log tail at RBA [0x4e.2bdf.0]
Mon Dec 28 14:41:51 2009
Incremental checkpoint up to RBA [0x4e.2fe8.0], current log tail at RBA [0x4e.30a0.0]

SQL> show parameter log_checkpoint_timeout;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ---------------
log_checkpoint_timeout               integer     1800

三：fast_start_mttr_target,该参数在10gR2中默认为0，也就是说让ORACLE进行自动检查点调整，如果要严格控制在一定时间内恢复数据库，那么就可以设置fast_start_mttr_target。如果设置了参数log_checkpoint_interval，那么fast_start_mttr_target会被log_checkpoint_interval覆盖。

四：log file switch，会触发一个增量检查点，不过它会更新datafile header

SQL> select cpdrt dirty,cpods on_disk_scn,cpodt on_disk_time,cphbt from x$kcccp where indx=0;

     DIRTY ON_DISK_SCN      ON_DISK_TIME              CPHBT
---------- ---------------- -------------------- ----------
        51 1964144          12/28/2009 15:41:41   706772766

SQL> alter system switch logfile;            

System altered

SQL> select cpdrt dirty,cpods on_disk_scn,cpodt on_disk_time,cphbt from x$kcccp where indx=0;

     DIRTY ON_DISK_SCN      ON_DISK_TIME              CPHBT
---------- ---------------- -------------------- ----------
        51 1964151         12/28/2009 15:41:53 706772770 ---logfile switch 不是full checkpoint，因为还存在dirty block

可以看到switch logfile之后，依然有51个dirty的block在buffer cache中，说明没有执行full checkpoint，因为执行full check point之后buffer cache中是不会有dirty 的block的，下面执行一个FULL checkpoint;

SQL> select cpdrt dirty,cpods on_disk_scn,cpodt on_disk_time,cphbt from x$kcccp where indx=0;

     DIRTY ON_DISK_SCN      ON_DISK_TIME              CPHBT
---------- ---------------- -------------------- ----------
        43 1964223          12/28/2009 15:44:29   706772822

SQL> alter system checkpoint;

System altered

SQL> select cpdrt dirty,cpods on_disk_scn,cpodt on_disk_time,cphbt from x$kcccp where indx=0;

     DIRTY ON_DISK_SCN      ON_DISK_TIME              CPHBT
---------- ---------------- -------------------- ----------
         0 1964229          12/28/2009 15:44:44   706772826    ---可以看到full checkpoint之后dirty block为0了

五:log_checkpoint_interval,该参数在10gR2中默认为0，该参数表示最后一次增量检查点以来，累积的日志块数(注意，这里的日志块数表示操作系统的块，非oracle的块，此块大小可以通过x$kccle.lebsz查到)，如果达到了设定值，那么将触发增量检查点，该参数会覆盖fast_start_mttr_target 请看测试:

SQL> select max(lebsz) from x$kccle;

MAX(LEBSZ)
----------
       512                 

日志块为512byte,那么设置log_checkpoint_interval=2048,也就是说产生了1M的redo 就会触发一个增量检查点，下面来验证下，首先我切换一下日志文件

SQL> alter system switch logfile;

System altered

SQL> alter system set log_checkpoint_interval=2048;

System altered

SQL> create table test as select * from dba_objects;

表已创建。

由于创建表test会产生多余1M的日志，所以，会引发一个增量检查点，我们查看alert 日志

ALTER SYSTEM SET log_checkpoint_interval=2048 SCOPE=BOTH;
Mon Dec 28 16:04:51 2009
Completed checkpoint up to RBA [0x51.2.10], SCN: 1965065   ----此处果然引发了一个增量检查点

六:ORACLE内部有这样一个限制：当生成的重做日志达到了阀值 0.9*(sum(v$log.bytes)-max(v$log.bytes))，就会引发一个增量检查点，通常情况下这个限制难以达到，因为生产库上会有多个日志组，在达到这个阀值之前就会产生logfile switch。

要通过实验手段看到这个限制条件，可以把日志组设置为2，然后再进行实验。

为了进行实验，我将logfile group 1设置为20M，将group 2 设置为200M;

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARCHIVED STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- -------- ---------------- ------------- -----------
         1          1         91   20971520          2 YES      INACTIVE               2011443 12/28/2009
         2          1         92  209715200          2 NO       CURRENT                2011445 12/28/2009

然后将200m的日志文件设置为current ，然后再进行一个大事物，然后运行如下SQL

SQL> select le.leseq    current_sequence,round(100*cp.cpodr_bno/le.lesiz,2)||'%' percentage,le.lesiz*512/1024/1024||'Mb' log_file_size,
  2  round((le.lesiz*512/1024/1024)*(cp.cpodr_bno/le.lesiz),2)||'Mb' used_size
  3  from x$kcccp cp,x$kccle le where le.leseq =cp.cpodr_seq and le.lesiz>0;

CURRENT_SEQUENCE PERCENTAGE                                LOG_FILE_SIZE        USED_SIZE
---------------- ----------------------------------------- -------------------- ------------------------------------------
              92 23.12%                                    200Mb                46.23Mb
查看当前log 的使用率，到了一定阀之后就会出现增量检查点，我这里的logfile 已经使用了46.23M才产生增量检查点，按理说应该是达到18M就会产生的，可能是机器还没反应过来吧，总之产生了增量检查点，这个与上面的理论相符合。

Mon Dec 28 17:52:24 2009
Incremental checkpoint up to RBA [0x5c.119fd.0], current log tail at RBA [0x5c.17167.0]