影响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]
