原址如下：
http://blog.chinaunix.net/uid-21943216-id-4070854.html
ORACLE Checkpoint(检查点)
1定义：
ORACLE数据库采用“提交时并不强迫针对数据块的修改完成”，而是“提交是保证修改记录（以重做日志形式）写入日志文件”的机制，来获得性能优势。即
用户发出COMMIT时，写数据文件是异步的，但是写日志文件是同步的。
数据库实例崩溃时，内存中buffer中的修改过的数据，可能没有写入到数据块中。数据库重新打开时，需要进行修复，来恢复buffer中的数据状态，并确保
已经提交的数据被写入到数据块中。
检查点是这个过程中的保证机制，通过它来确定恢复时，哪些重做日志应该被扫描并应用于恢复。
check queue:检查点发生后，触发DBWn，CKPT获取发生检查点时对应的SCN，通过DBWn写到这个SCN为止，DBWR写dirty buffer中的数据，是根据buffer在首次被修改的时间的顺序写出，
也就是buffer被modify的时候会进入一个queue(checkpoint queue)，DBWR就根据queue中的顺序批量写入到数据文件。由于无法适时将dbwr的进度记录，所以采用了
ckpt进程的检查点和heartbeat。
检查点发生后，CKPT进程将检查checkpoing queue是否过长，如果是，则触发DBWn,将一部分数据写入数据文件，缩短checkpoint queue.Checkpoint发生时，一面通过DBWn进行下一
批写操作（每次写的块数是有一个批量写的隐藏参数控制），另一方面，采用了heartbeat概念，每3秒钟将DBWn写的进度反应到控制文件中，也就是把DBWn当前刚写完的dirty buffer
对应的SCN写入到数据文件头和控制文件，这就是检查点SCN。
检查点发生后的数据库的数据文件、控制文件处理一致的状态的含义是不需要进行介质恢复，只表示数据文件头一致，但是不表示数据文件内容一致，因为数据文件内容可能包括在没有发生
检查点的其它情况下的dbwr写数据文件。这样文件内容就可能不一致，如果断电则要进行恢复。
触发DBWn进程的条件有：
1.DBWn超时。
2.系统中没有多余的缓冲区来存储数据。
3.CKPT触发DBWn
checkpoint 目的：
1.确保数据一致性
2.使数据库快速恢复。
checkpoint期间如下进程发生
1.DBWn写所有的脏数据到数据文件
2.LGWR更新控制文件和数据文件的SCN
2.checkpoint优化参数。
所有的数据文件在checkpoint期间会被冻结。频繁的checkpoints可以快速恢复数据库。优化checkpoint有如下几个参数
1.fast_start_mttr_target
2.log_checkpoint_interval
3.log_checkpoint_timeout
4.log_checkpoints_to_alert
2.1 fast_start_mttr_target
9i以来fast_start_mttr_target是调整checkpoint的首先方法，它可以指定单实例恢复需要的秒数。v$instance_recovery.estimated_mttr显示当前估计需要的秒数，
这个值会显示，即使fast_start_mttr_target没有被指定。instance_recovery.target_mttr表明短时间内MTTR的目标。v$mttr_target_advice显示这个当前MTTR设置
的工作量产生的I/O数量和其他I/O。帮助用户评定在优化和恢复之前平衡。
2.2 log_checkpoint_interval
log_checkpoint_interval指定这个最大的重做块的间隔数目。如果fast_start_mttr_target被指定，则log_checkpoint_interval不能设置为0.log_checkpoint_interval
会影响checkpoint频率。这个参数影响数据库向前回滚的时间，实际的恢复时间也基于这个时间，当然还有失败的类型和需要归档日志的数量。
2.3 log_checkpoint_timeout
指每N秒发生一个checkpoint,不顾事务提交的频率，这可能导致一些没有必要的checkpoint。
2.4 log_checkpoints_to_alert
设置为真，可以在警告日志中观察到增量检查点的触发。
3.触发完全检查点
触发完全检查点，促使DBWn将检查点时刻前的所有的脏数据写入数据文件，一般运行期间的数据库不会产生完全检查点。
3.1.正常事务处理或立即选项关闭例程时shutdown immediate 和 shutdown normal
3.2.设置初始化参数：
log_checkpoint_interval,log_checkpoint_timeout,fast_start_io_target强制时。
3.3.DBA手动请求时
alter system checkpoint;
alter tablespace XXX offline;
3.4 日志切换时
alter system switch logfile;
注意:
alter databae datafile xxx offline 不会触发检查点进程。单纯的 datafile offline不会触发文件检查点，只有针对 tablespace offline才会触发检查点，这也是online datafile 需要介质
恢复，而online tablespace 不需要的原因。当然对于表空间offline 再online的情况 ，最好做个强制checkpoint;
4.触发增量检查点
4.1 联机热备份数据文件前，要求该数据文件中被修改的块从BUFFER写入数据文件，所以发出如下命令
alter tablespace XXX begin backup(end backup);也会触发和该表空间的数据文件有关的局部检查点。
4.2 其他命令
aler tablespace XXX readonly;
alter tablespace xxx offline normal
会触发增量检查点。
5.检查点等待事件。
日志切换必须等检查点完成。log file switch(checkpoint incomplete)，这个等待事件本身也说明，日志切换时产生的检查点是需要等待的。
这个日志文件对应的脏块全部写完后，检查点更新控制文件和数据头，检查点才完成。也就是说，日志切换必须等待检查点完成，而检查点等待
DBWn完成。这种等待DBWn完成的检查点，最后一步写入控制文件和数据文件头的SCN，肯定是DBWn完成的最后一块的SCN。
log switch时，不能立即切换到active状态，log group 必须等待。active表示该log group 还没有完成归档（归档模式下），或者该log group有进行
实例恢复时需要用到的日志，所以当checkpoint发生时，如果DBWn还没有写完它该写完的dirty buffer,则log group 处于active状态，不会进行日志切换，当然
也不会发生日志文件被覆盖的问题。
检查点发生后，就是lgwr和dbwr写buffer到磁盘文件的过程，但是两者的读写速度不同，dbwr写buffer到数据文件的过程较慢，因为此过程是一个随机读取存储的过程。而
lgwr写buffer到redo文件的过程比dbwr要快得多，因为是顺序读取写入的。因为此两者速度不同，就会产生等待问题，当LGWR轮循一圈后，进行日志切换，覆盖redo log file,
如果此时dbwr没有写完，则lgwr会等待，oracle 会挂起，同时在alter日志中会提示一个checkpoint not complete，检查点结束后数据库会自动恢复。
6.checkpoint 与 scn关系
checkpoint发生的目的就是要把储存的buffer内的已提交的事务写入到Disk，提交一个事务时，立刻将redo buffer 写入到redo log file中，但是不一定马上将dirty buffer
写入到disk datafile中，这是为了减少I/O考虑，所以采用BATCH方式写入。
checkpoint发生时，会把SCN写入到以下四个地方，三个位于控制文件，一个位于数据文件头。
control file三个地方：
1.system checkpoint scn
SQL> select checkpoint_change# from v$database;
CHECKPOINT_CHANGE#
------------------
9369637
2.datafile checkpoint scn
SQL> select name,checkpoint_change# from v$datafile where name like '%users01%';
NAME CHECKPOINT_CHANGE#
-------------------------------------------------------------------------------- ------------------
/u01/app/oracle/oradata/orcl/users01.dbf 9369637
3.stop scn
SQL> select name,last_change# from v$datafile where name like '%users01%';
NAME LAST_CHANGE#
-------------------------------------------------------------------------------- ------------
/u01/app/oracle/oradata/orcl/users01.dbf
正常datafile在read_write模式下，last_change#一定是NULL
4.start scn 在datafile header
SQL> select name,checkpoint_change# from v$datafile_header where name like '%users01%';
NAME CHECKPOINT_CHANGE#
-------------------------------------------------------------------------------- ------------------
/u01/app/oracle/oradata/orcl/users01.dbf 9369637
7.crash recovery 和 media recovery
启动数据库时，如果发现stop scn = NULL,则表示需要进行crash recovery
启动数据库时，如果发现datafile header 的start scn 不等于存储于控制文件中的datafile scn ，则要进行media recovery.
8.recovery database两种问题
8.1.recovery database until cancel => open database resetlog
此种情况下datafile header中的scn一定小于control file 的datafile scn，必须进行media recovery，重做archive log直到相等。
restore datafile 后，可以mount database ，然后检查controlfile and datafile header的上SCN。
SQL> select 'controlfile' "SCN location",name,checkpoint_change#
from v$datafile
where name like '%users01%'
union
select 'file header',checkpoint_change#
from v$datafile_header
where name like '%users01%';
SCN location NAME CHECKPOINT_CHANGE#
------------- -------------------------------------------------------------------------------- ------------------
controlfile /u01/app/oracle/oradata/orcl/users01.dbf 9369637
file header /u01/app/oracle/oradata/orcl/users01.dbf 9369637
8.2 recover database until cancel using backup controlfile => open database resetlog
这种情况下的的datafile header中的SCN一定大于controlfile中的datafile scn，因为控制文件是旧的，所以它保存的信息也是以前的。
如果某个表被DROP掉，没有破坏整体结构，可以用不完全恢复解决。
如果某个tablespace或datafile被DROP掉，因为数据库整体结构破坏，所以controlfile已经没有该数据文件的信息，就算restore datafile 再进行不完全恢复
也无法未回文件。此种情况下只好restore之前备份的controlfile(里面被drop 掉的datafile metadata此时还存在)，不过restore controlfile,此时controlfile
中的SYSTEM SCN 小于目前datafile header scn,也不会等待目前存储于log file内的SCN，此时必须使用recover database until cancel using backup controlfile 到
drop datafile or drop tablespace之前的SCN。
