http://www.cnblogs.com/yifan268/archive/2008/07/15/1243418.html 转自
SCN和Checkpoint
SCN ：system change number。作为数据库内部的逻辑时钟，用来标识数据库在某个确切时刻提交的版本，存在于控制文件、数据文件头、数据块、日志文件头、日志文件change vector。
数据文件头中包含该数据文件的checkpoint SCN。
Checkpoint ：只是一个数据库事件，根本意义在于减少崩溃恢复时间（Crash Recovery）。
当Checkpoint 发生时，Oracle 会通知DBWR 进程，把之前的Dirty Data 从Buffer cache写入磁盘，写入完成后，CKPT 进程更新控制文件和数据文件头，记录检查点信息，表示变更。
那么如何来产生检查点呢？有三种方法，可以通过
1.alter system checkpoint
2.alter system switch logfile
3.DBWn进程写出脏块
每个checkpoint都记录一系列获得活跃的事务和记录最近的事务的日志的地址。一次checkpoint包含以下步骤:
l 把redo buffers的内容刷到redo log中。
l 在redo log file中留下一个checkpoint记录。
l 把database buffer cache的变更刷新到磁盘。
l 在checkpoint完成后，更新数据文件头和控制文件。
FAST_START_MTTR_TARGET 参数从9i开始引入，该参数定义数据库进行Crash 恢复的时间，单位是秒，取值范围在0～3600之间。
数据库当前的实例恢复时间可以通过v$instance_recovery, 可以看到当前数据库估计的平均恢复时间（MTTR）：ESTIMATED_MTTR，TARGET_MTTR 表示期望的平均恢复时间。当ESTIMATED_MTTR > = TARGET_MTTR时，系统就会触发检查点，系统恢复信息后重新计算。
SELECT TARGET_MTTR,ESTIMATED_MTTR FROM v$instance_recovery;
LGWR 写log buffer à log files
1、 user commit a transaction
2、 redo log buffer 1/3 full
3、 changed record 接近 1M，不包括deleted or inserted records
4、 LGWR 空闲时间超过3秒
在Oracle数据库中和checkpoint相关的SCN总共有4个
1.System checkpoint SCN (存在于控制文件)
在系统执行checkpoint后，Oracle会更新当前控制文件中的System checkpoint SCN。我们可以通过select checkpoint_change# from v$database来查看。
2.Datafile checkpoint SCN (存在于控制文件)
由于控制文件中记录了Oracle中各个数据库文件的位置和信息，其中当然也包括了Datafile checkpoint SCN，因此在执行checkpoint的时候，Oracle还会去更新控制文件中所记录的各个数据文件的datafile checkpoint SCN.
我们可以通过select checkpoint_change# from v$datafile;来查看
3.Start SCN (存在于各个数据文件头)
在执行checkpoint时，Oracle会更新存放在各个实际的数据文件头的Start SCN（注意绝对不会是控制文件中），这个SCN存在的目的是用于检查数据库启动过程中是否需要做media recovery(介质恢复)。
我们可以通过select checkpoint_change# from v$datafile_header;
4.End SCN(存在于控制文件)
最后一类SCN,End SCN他也是记录在控制文件当中，每一个所记录的数据文件头都有一个对应的End SCN,这个End SCN一定是存在于控制文件当中。这个SCN存在的绝对意义主要是用来去验证数据库启动过程中是否需要做instance recovery。我们可以通过
select name,last_change# from v$datafile
那么其实在数据库正常运行的情况下，对于read/write的online 数据文件这个SCN号为#FFFFFF(NULL).
需要注意的是：
1.CKPT一定是是在checkpoint发生的时候将数据库当前的SCN更新入数据库文件头和控制文件当中，同时DBWn进程将buffer cache中的脏数据块（dirty block）写到数据文件当中(这个脏数据也一定是当前online redo log保护的那一部分)。
2.同时CKPT进程还会在控制文件当中记录(redo block address)RBA，这个地址用来标志恢复的时候需要从日志中的那个位置开始。
SCN和Checkpoint
SCN ：system change number。作为数据库内部的逻辑时钟，用来标识数据库在某个确切时刻提交的版本，存在于控制文件、数据文件头、数据块、日志文件头、日志文件change vector。
数据文件头中包含该数据文件的checkpoint SCN。
Checkpoint ：只是一个数据库事件，根本意义在于减少崩溃恢复时间（Crash Recovery）。
当Checkpoint 发生时，Oracle 会通知DBWR 进程，把之前的Dirty Data 从Buffer cache写入磁盘，写入完成后，CKPT 进程更新控制文件和数据文件头，记录检查点信息，表示变更。
那么如何来产生检查点呢？有三种方法，可以通过
1.alter system checkpoint
2.alter system switch logfile
3.DBWn进程写出脏块
每个checkpoint都记录一系列获得活跃的事务和记录最近的事务的日志的地址。一次checkpoint包含以下步骤:
l 把redo buffers的内容刷到redo log中。
l 在redo log file中留下一个checkpoint记录。
l 把database buffer cache的变更刷新到磁盘。
l 在checkpoint完成后，更新数据文件头和控制文件。
FAST_START_MTTR_TARGET 参数从9i开始引入，该参数定义数据库进行Crash 恢复的时间，单位是秒，取值范围在0～3600之间。
数据库当前的实例恢复时间可以通过v$instance_recovery, 可以看到当前数据库估计的平均恢复时间（MTTR）：ESTIMATED_MTTR，TARGET_MTTR 表示期望的平均恢复时间。当ESTIMATED_MTTR > = TARGET_MTTR时，系统就会触发检查点，系统恢复信息后重新计算。
SELECT TARGET_MTTR,ESTIMATED_MTTR FROM v$instance_recovery;
LGWR 写log buffer à log files
1、 user commit a transaction
2、 redo log buffer 1/3 full
3、 changed record 接近 1M，不包括deleted or inserted records
4、 LGWR 空闲时间超过3秒
在Oracle数据库中和checkpoint相关的SCN总共有4个
1.System checkpoint SCN (存在于控制文件)
在系统执行checkpoint后，Oracle会更新当前控制文件中的System checkpoint SCN。我们可以通过select checkpoint_change# from v$database来查看。
2.Datafile checkpoint SCN (存在于控制文件)
由于控制文件中记录了Oracle中各个数据库文件的位置和信息，其中当然也包括了Datafile checkpoint SCN，因此在执行checkpoint的时候，Oracle还会去更新控制文件中所记录的各个数据文件的datafile checkpoint SCN.
我们可以通过select checkpoint_change# from v$datafile;来查看
3.Start SCN (存在于各个数据文件头)
在执行checkpoint时，Oracle会更新存放在各个实际的数据文件头的Start SCN（注意绝对不会是控制文件中），这个SCN存在的目的是用于检查数据库启动过程中是否需要做media recovery(介质恢复)。
我们可以通过select checkpoint_change# from v$datafile_header;
4.End SCN(存在于控制文件)
最后一类SCN,End SCN他也是记录在控制文件当中，每一个所记录的数据文件头都有一个对应的End SCN,这个End SCN一定是存在于控制文件当中。这个SCN存在的绝对意义主要是用来去验证数据库启动过程中是否需要做instance recovery。我们可以通过
select name,last_change# from v$datafile
那么其实在数据库正常运行的情况下，对于read/write的online 数据文件这个SCN号为#FFFFFF(NULL).
需要注意的是：
1.CKPT一定是是在checkpoint发生的时候将数据库当前的SCN更新入数据库文件头和控制文件当中，同时DBWn进程将buffer cache中的脏数据块（dirty block）写到数据文件当中(这个脏数据也一定是当前online redo log保护的那一部分)。
2.同时CKPT进程还会在控制文件当中记录(redo block address)RBA，这个地址用来标志恢复的时候需要从日志中的那个位置开始。
