关于检查点的一点具体应用讨论(3)

scn,则跳过此change vector,否则redo。

数据块中ITL中还有SCN,但它的作用是用于产生一致性读快照。

commit的时候加一，其他很多时候也会加1，只要数据库发生了变化都会增加。很多时候，能否举一些例子？

解答：
dml一发生即使没有提交也会增加scn, job进程一样产生scn,只要对数据库中文件发生任何的改变都有可能产生scn,SCN: system change number, not system commit number .也就是系统发生变化所产生的一个时间点标志。不是提交的标志，只是因为提交也是系统的变化之一而已。
IXDBA.NET社区论坛

这句话我应该更准确第表达一下：
如果一个dml导致产生事务，则会产生一个scn。这个意思是说
如果一个事务包含多个dml，则只有第一个初始产生事务的dml产生scn，提交的时候又是一个scn。
如果一个事务只有一个dml，那么看起来就是dml产生一个scn，提交或者回滚产生一个scn。
所以可以把结论定义为事务的开始和事务的结束都会导致 SCN 的增加，同一个block上在一个事务中连续发生255个DML后scn也会增加。

检查点的发生和日志的关系：

解答：
检查点的发生，跟写日志文件是没有必然联系的。
检查点发生，通知 DBWR 写数据文件，写完后ckpt更新控制文件和数据文件头。
当DBWR 写数据块的时候若发现数据块的相关 RDBA (位于日志文件的位置) 的 log block 还没有被写入日志文件，则在dbwr写块之前必须通知llgwr把log buffer 中日志写入日志文件。

关于检查点等待事件：

有些事件的产生必须等待检查点的完成，才能开始数据库的其它操作：
日志文件切换就是其中一个事件，日志切换必须等待检查点完成。
log file switch (checkpoint incomplete) 这个等待事件本身也说明，日志切换时产生的检查点是需要等待的，这个日志文件所对应脏块全部写完后，检查点进程更新控制文件和数据头，然后这个检查点才能算完成。
也就是说日志切换必须等待检查点完成，而检查点在等待DBWn完成。
这种等待DBWn完成的检查点，最后一步写入控制文件和数据文件头的SCN，肯定是DBWn完成的最后一块的SCN。

检查点为什么要等待dbwr完成后才进行切换（log switch）？

log switch时，是不能立即switch到active状态的，log group必须等待。active表示该log group还没有完成归档（归档模式下）或者该log group有进行instance recovery的需要用到的日志。所以当checkpoint发生时，如果dbwr还没有写完它该写完的dirty buffers（该checkpoint时间点以前产生的dirty buffers, 靠scn判断），则该log group处于active状态，不会进行日志切换，当然也不会发生日志文件被覆盖的问题了。

如果没有设置archive log ，在检查点发生后，发生log switch一个轮回，log file是否会被覆盖掉？

当检查点发生后，会触发lgwr，lgwr会把此时SCN以前在redo buffer中的所有操作写到redo log file，同时lgwr也会触发dbwr进程，dbwr也开始把此刻以前database buffer中的dirty buffer队列中的操作写入data file。
其实检查点发生后，就是lgwr和dbwr写buffer到磁盘文件的过程，但是两者的读写速度时不同的，dbwr写buffer到数据文件的过程相对较慢，因为dbwr写过程是一个随机读取存储的过程。Lgwr写buffer到redo文件的过程比dbwr要快很多，因为lgwr是顺序读取写入的。
由于以上lgwr和dbwr写操作的速度不同，就产生了一个等待问题。即当lgwr
轮循一圈后，要进行日志切换，覆盖redo log file，但是此时dbwr还没有写完，那么