SCN、checkpoint、redo log

LGWR触发条件：

   1. 用户提交  
   2. 有 1/3 重做日志缓冲区未被写入磁盘  
   3. 有大于 1M 的重做日志缓冲区未被写入磁盘  
   4. 3秒超时  
   5. DBWR  需要写入的数据的 SCN 大于 LGWR 记录的 SCN，DBWR  触发LGWR 写入。  

说明：

1、即使用户未commit，被修改的数据文件对于的redo日志依然可能会被写入redo log文件中，从而导致前滚后需要进行回滚。

2、当数据文件要下盘，即DBWR刷盘时，如果被修改数据对应的日志文件还未下盘，则DBWR触发LGWR把redo buffer中的数据写到redo log文件中（即使该数据未commit），保证被修改的数据下盘前，其对应的redo buffer中的日志已被写到redo log文件中。

 

触发DBWR 进程的条件有：  
  1.  DBWR 超时，大约 3秒  
  2. 系统中没有多余的空缓冲区来存放数据
  3.  CKPT  进程触发 DBWR
 
checkpoint 有两个目的：
1、确保数据一致性。
2、使数据库能快速地恢复。
 
Checkpoint期间会有下面进程发生：
1. DBWR 写所有脏数据到数据文件；
2. CKPT 更新控制文件和数据文件的SCN。

 

注意：
  1. alter system switch logfile 也将触发完全检查点的发生。
  2. alter database datafile ... offline  不会触发检查点进程。
 
  如果是单纯的 offline datafile，那么将不会触发文件检查点，只有针对 offline tablespace的时候才会触发文件检查点。

 

检查点等待事件：

日志切换必须等待检查点完成，而检查点在等待DBWn 完成。

 

redo log switch时，不能立即switch到active状态的redo log文件（即redo log文件循环复用，发生覆盖），log group必须等待该active状态的redo log对应的变化数据被DBWR下盘后，才能被覆盖。

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

其实检查点发生后，就是 lgwr 和 dbwr 写 buffer 到磁盘文件的过程， dbwr写data buffer到data file是一个随机存储的过程，较慢；Lgwr 写redo buffer 到 redo file 文件是顺序写的过程，较快，这就产生了一个等待问题。 即当lgwr 轮循一圈后，要进行日志切换，覆盖 redo log file，但是此时dbwr还没有写完，那么lgwr就会出现等待，oracle也会hang在那里，同时 alter文件中会提示一个相应的提示checkpoint not complete。等检查点完成后数据库自动恢复正常。

因此，最好建立多组redo file文件，并且，redo file设置较大，避免lgwr循环一圈后，check point过程中出现等待事件。

SCN查询：

select checkpoint_change# from v$database; system scn

select name,checkpoint_change#, last_change# from v$datafile; datafile scn和stop SCN

select name,checkpoint_change# from v$datafile_header ; start scn