背景：生产系统上有一个9i的库，采用了standby，每天全备。由于平时联机业务量很小，甚至一天不产生一个archive，而批量时间产生的redo日志又相对较多，所以设置了archive_lag_target参数，强制其20分钟切一次日志，以保证一旦主库发生问题，丢失的数据在20分钟以内。经查看，每二十分钟的日志大小大概在1M多一点。
该库有三组redo日志。经过观察我发现一个现象。比如当前状态下，三组日志是如下状态：
Group 1Active
Group 2Current
Group 3Inactive
当20分钟之后，切换日志时，我发现日志变成了以下状态：
Group 1Inactive
Group 2Active
Group 3Current
而且我尝试手工切日志数次，发现每次三组日志都是保持一组Active，一组Inactive的状态。
在9i ocp的fundamentals I上面写到以下几种情况触发checkpoint:
A checkpoint occurs, for example, in the following situations:
? At every log switch
? When an instance has been shut down with the normal, transactional, or immediate
option
? When forced by setting the initialization parameter FAST_START_MTTR_TARGET.
? When manually requested by the database administrator
? When the ALTER TABLESPACE [OFFLINE NORMAL|READ ONLY|BEGIN BACKUP] cause checkpointing on specific data files.
我的FAST_START_MTTR_TARGET参数设置为300。
我是不是可以这样理解，由于系统联机时业务量很小，数据库一旦crash掉，恢复的时间不超过FAST_START_MTTR_TARGET参数指定的300秒，所以触发checkpoint的只有日志切换的时刻？可是为什么日志切换时做checkpoint的只有当前日志的上上一组日志所覆盖的数据，而对上一组日志却始终没有做checkpoint呢？当切换日志时触发的checkpoint操作对哪些日志做checkpoint这个量是怎么来定的呢？是不是就是对上上一组日志作checkpoint呢？还有FAST_START_MTTR_TARGET这个参数指的“the number of seconds the database takes to perform crash recovery of a single instance”这个时间好象也很模糊，很难确定啊？
最初由 chenyan995 发布
[B]背景：生产系统上有一个9i的库，采用了standby，每天全备。由于平时联机业务量很小，甚至一天不产生一个archive，而批量时间产生的redo日志又相对较多，所以设置了archive_lag_target参数，强制其20分钟切一次日志，以保证一旦主库发生问题，丢失的数据在20分钟以内。经查看，每二十分钟的日志大小大概在1M多一点。
该库有三组redo日志。经过观察我发现一个现象。比如当前状态下，三组日志是如下状态：
Group 1Active
Group 2Current
Group 3Inactive
当20分钟之后，切换日志时，我发现日志变成了以下状态：
Group 1Inactive
Group 2Active
Group 3Current
而且我尝试手工切日志数次，发现每次三组日志都是保持一组Active，一组Inactive的状态。
在9i ocp的fundamentals I上面写到以下几种情况触发checkpoint:
A checkpoint occurs, for example, in the following situations:
? At every log switch
? When an instance has been shut down with the normal, transactional, or immediate
option
? When forced by setting the initialization parameter FAST_START_MTTR_TARGET.
? When manually requested by the database administrator
? When the ALTER TABLESPACE [OFFLINE NORMAL|READ ONLY|BEGIN BACKUP] cause checkpointing on specific data files.
我的FAST_START_MTTR_TARGET参数设置为300。
我是不是可以这样理解，由于系统联机时业务量很小，数据库一旦crash掉，恢复的时间不超过FAST_START_MTTR_TARGET参数指定的300秒，所以触发checkpoint的只有日志切换的时刻？可是为什么日志切换时做checkpoint的只有当前日志的上上一组日志所覆盖的数据，而对上一组日志却始终没有做checkpoint呢？当切换日志时触发的checkpoint操作对哪些日志做checkpoint这个量是怎么来定的呢？是不是就是对上上一组日志作checkpoint呢？还有FAST_START_MTTR_TARGET这个参数指的“the number of seconds the database takes to perform crash recovery of a single instance”这个时间好象也很模糊，很难确定啊？ [/B]
Q:所以触发checkpoint的只有日志切换的时刻？
A:
每次日志切换时；
当已通过正常事务处理或者立即选项关闭例程时；
当通过设置初始化参数LOG_CHECKPOINT_INTERVAL、LOG_CHECKPOINT_TIMEOUT 和FAST_START_IO_TARGET 强制时；
当数据库管理员手动请求时；(alter system checkpoint)
Q:可是为什么日志切换时做checkpoint的只有当前日志的上上一组日志所覆盖的数据，而对上一组日志却始终没有做checkpoint呢？
A:肯定做了checkpoint,因为你日志switch
Q:当切换日志时触发的checkpoint操作对哪些日志做checkpoint这个量是怎么来定的呢？
A:对当前日志的上一个日志文件
这个回答不是不对，我测试了一下！
Q:还有FAST_START_MTTR_TARGET这个参数指的“the number of seconds the database takes to perform crash recovery of a single instance”这个时间好象也很模糊，很难确定啊？
A:这个参数设置可以通过v$mttr_target_advice和statistics_level来进行设置！
不是这样的
During a checkpoint:
? A number of dirty database buffers covered by the log being checkpointed are written to
the data files by DBWn.
也就是说，对一部份日志作checkpoint，是把被这部分日志覆盖的数据块的修改写回到磁盘。我想问的是，日志切换时，为什么我观察到的情况好像不是对刚被切换掉的那一组日志作checkpoint，而是对那组日志之前的一组日志作checkpoint
