如果说switch logfile不做检查点，那何来的checkpoint not complete问题？
如果说switch logfile做检查点，那为何做完switch logfile之前之后,
select checkpoint_change# from v$database;
select checkpoint_change# from v$datafile;
select checkpoint_change# from v$datafile_header;
查出来的值都没变过？

on-disk RBA和low RBA都在控制文件中，Oracle不会去频繁写数据文件头部的。
否则容易出现性能问题。

Redo Byte Address (RBA)

Recent entries in the redo thread of an Oracle instance are addressed using a 3-part redo byte address, or RBA. An RBA is comprised of
the log file sequence number (4 bytes)
the log file block number (4 bytes)
the byte offset into the block at which the redo record starts (2 bytes)
RBAs are not necessarily unique within their thread, because the log file sequence number may be reset to 1 in all threads if a database is opened with the RESETLOGS option.
RBAs are used in the following important ways.

With respect to a dirty block in the buffer cache, the low RBA is the address of the redo for the first change that was applied to the block since it was last clean, and the high RBA is the address of the redo for the most recent change to have been applied to the block.
Dirty buffers are maintained on the buffer cache checkpoint queues in low RBA order. The checkpoint RBA is the point up to which DBWn has written buffers from the checkpoint queues if incremental checkpointing is enabled -- otherwise it is the RBA of last full thread checkpoint. The checkpoint RBA is copied into the checkpoint progress record of the controlfile by the checkpoint heartbeat once every 3 seconds. Instance recovery, when needed, begins from the checkpoint RBA recorded in the controlfile. The target RBA is the point up to which DBWn should seek to advance the checkpoint RBA to satisfy instance recovery objectives.

The on-disk RBA is the point up to which LGWR has flushed the redo thread to the online log files. DBWn may not write a block for which the high RBA is beyond the on-disk RBA. Otherwise transaction recovery (rollback) would not be possible, because the redo needed to undo a change is always in the same redo record as the redo for the change itself.

The term sync RBA is sometimes used to refer to the point up to which LGWR is required to sync the thread. However, this is not a full RBA -- only a redo block number is used at this point.

The low and high RBAs for dirty buffers can be seen in X$BH. (There is also a recovery RBA which is used to record the progress of partial block recovery by PMON.) The incremental checkpoint RBA, the target RBA and the on-disk RBA can all be seen in X$TARGETRBA. The incremental checkpoint RBA and the on-disk RBA can also be seen in X$KCCCP. The full thread checkpoint RBA can be seen in X$KCCRT.

我只是要回答你第二个问题
“如果说switch logfile做检查点，那为何做完switch logfile之前之后,查出来的值都没变过？”只是想告诉你，switch logfile后scn的值是变化的。

额，chenyu，你查的是一个归档的起始scn与结束scn。与增量检查点纪录rba有什么关系呢？与v$datafile中的checkpoint_change#更是没什么关系。因为一般来说，你查出来的值会远远小于当前v$datafile中的checkpoint_change#。退一步来说，就算不是归档模式，logfile 还是要switch的。

如果说switch logfile做检查点，那为何做完switch logfile之前之后,
select checkpoint_change# from v$database;
select checkpoint_change# from v$datafile;
select checkpoint_change# from v$datafile_header;
查出来的值都没变过？

你应该查v$archived_log，因为switch logfile会导致archive，controlfile会记录这个信息，而checkpoint正是要把lrba记录到controlfile中，v$archived_log可以体现出这个变化，你还可以通过转储control file来验证这一点；这个scn和v$database 的SCN是不一样的，我的理解是v$database、v$datafile等的SCN是ORACLE控制的，有很多原因可以引起他的改变如事务的commit等。但是和checkpoint可能没有必然的联系。
SQL> select max(FIRST_CHANGE#) FIRST_CHANGE#,max(NEXT_CHANGE#) NEXT_CHANGE# from v$archived_log;

FIRST_CHANGE# NEXT_CHANGE#
------------- ------------
       673698       674563

SQL> alter system switch logfile;

System altered.

SQL> select max(FIRST_CHANGE#) FIRST_CHANGE#,max(NEXT_CHANGE#) NEXT_CHANGE# from v$archived_log;

FIRST_CHANGE# NEXT_CHANGE#
------------- ------------
       674563       674842

我问的是oracle做了什么动作后遇到了什么问题会发生checkpoint incomplete
oracle在发生switch logfile时->遇到了将被覆盖的logfile是active状态->checkpoint incomplete，其本质原因是上一次lgwr写入redo log已经完成了，但是dbwr还没有把dirty blocks写入data file，结果又发生几次switch logfile，结果导致当前的log file还是active，这时发生checkpoint incomplete

incremental checkpoint每三秒一次，我行我素，和switch logfile 应该没什么关系
没错，但是增量检查点还有其他的触发机制即在switch logfile时也会触发增量检查点的；这可以通过更改log_checkpoints_to_alert来观察，如下alert日志：

Tue Nov 23 15:32:02 2010
ALTER SYSTEM SET log_checkpoints_to_alert=TRUE SCOPE=BOTH;  //设置参数后，在客户端执行alter system switch logfile，就会发现触发checkpoint.
Tue Nov 23 15:32:25 2010
Beginning log switch checkpoint up to RBA [0xc.2.10], SCN: 674563
Thread 1 advanced to log sequence 12
  Current log# 1 seq# 12 mem# 0: /u01/app/oracle/oradata/PROD/disk1/redo01.log
  Current log# 1 seq# 12 mem# 1: /u01/app/oracle/oradata/PROD/disk2/redo01.log

还有，incremental checkpoint每三秒一次，我行我素，和switch logfile 应该没什么关系。
switch logfile 时的checkpoint：
Beginning log switch checkpoint up to RBA [0xaa.2.10], SCN: 31836587
incremental的checkpoint:
Incremental checkpoint up to RBA [0xa7.6b2.0], current log tail at RBA [0xa7.2574.0]

这么说来，datafile header中记录的确实应该是恢复起点rba。
虽然rba与检查点总是同时出现，不过这里貌似rba和我说的问题并没有什么联系吧。
“这时ORACLE会把lrba记录到control file 和 data file中，所以switch logfile 会触发增量检查点"。
我不是问发生switch log 时oracle做了什么，我问的是oracle做了什么动作后遇到了什么问题会发生checkpoint incomplete

kevin.zhang 发表于 2010-11-23 14:14
还有，据我所知，low-rba是纪录到controlfile上，标志着恢复的起点，但是datafile 中的是on-disk rba，标志 ...

恢复的终点始终在在current log中，在正常shutdown immediate之前恢复终点的scn是不知道的，又怎么会写入到data file中。