oracle system change number(SCN) 下 检查点
一，概述
大多数关系型数据库都采用'在提交时并不强迫对数据块的修改完成‘而是’提交时保证修改记录(以重做日志的形式)写入日志文件的机制来获得性能上的提高，
也就是说，提交时，写数据文件是异步的，写日志文件是同步的。
checkpoint queu的概念：检查点发生后，触发DBWN，CKPT获取发生检查点发生时的scn,通知DBWn写到这个检查点为止
dbwn写dirty buffer是根据buffer在被首次modify的时候的时间顺序写出，也就是buffer被modify的时候回进入一个queue,
dbwn根据序列从其中批量写入到数据文件。
检查点发生以后，ckpt会检查checkpoint queue(脏块列表)是否过长，如果是，则触发dbwn,将一部分脏块写入到数据文件，从而缩短checkppointqueue
checkpoint发生时，以方便通知dbwr进行下一批写操作(dbwr写入的时候，一次写的块数是由一个批量写的隐藏参数控制)
另一方便，oracle采用了一个心跳的概念，以3秒的频率将dbwr写的进度反映到控制文件中，也就是dber刚写完的dirty buffer对应的scn,
写入数据文件头和控制文件，就是检查点scn.
二，触发条件
增量检查点(incremental checkpoint)
当checkpoint做一个full thread时，也就是将所有的数据写入到磁盘，会造成巨大的io对系统性能有一定影响，
checkpoint queue也正是为了解决这个问题，每一个dirty buffer会移入检查点队列，按照log rdb(第一次对此块修改对应的redo lblock address)来排列，
靠近检查点队列尾端的log rbd是最小的，当这些脏块被再次修改时他在队列中的顺序也不会改变，也就保证了越早修改的块越早的写入磁盘。
在以前事件，条件或者参数下会触发检查点(完全检查点)
1,shutdown immediate或者shutdown normal
2.通过设置初始化参数log_checkpoint_interval,log_checkpoint_timeout和fast_start_to_target强制时
3.管理员手动请求 alter system checkpoint,
alter tablespace ..offline
alter system switch logfile（日志切换将触发完全检查点的发生）
需要注意.alter database datafile ..offline 不会触发检查点进程，而offline tablespace才会触发文件检查点，这也是为什么
online datafile需要media recovery而online tablespace不需要，对于表空间的offiline和online，最好做个强制的检查点
触发增量检查点的情况
alter tablespace_name begin backup$end backup 会触发和该表空间和数据文件有关的局部检查点
alter tablespace tablespace_name read only;
alter tablespace tablespace_name offline normal;
记录一个场景
由于lgwr和dbwr写操作的速度不同，就产生了一个等待的问题，即当lgwr轮循一圈后，要进行日志切换，覆盖redo log file,但是此时dbwr还没有写完，那么lgwr就会出现等待，oracle也会hang住，这时候，alert文件中会提示一个相应的提示checkpoint not complete.等检查点完成后数据库才会恢复正常
当Log swtch时，会触发检查点，标记检查点时，dbwr要把log file中recovered by the log being checkpoint的数据写入到数据文件上，
如果dbwr没有写完，那么前一个logfile是不能被覆盖的，因此必须等检查点完毕，也就是说把脏块全部写入数据文件后，诶之文件才允许被覆盖
上面的情况如果发生，说明你的dbwr写如果满或者log file组数过少或者log file太小