■实例恢复要把实例异常关闭前没有写到硬盘的脏数据通过日志进行恢复。

■如果脏块过多，实例恢复的时间也会过长，检查点的发生可以减少脏块的数量，从而减少实例

恢复的时间。

■通过LRBA（LOW REDO BUFFER ADRESS），HRBA（HIGH REDO BUFFER ADRESS），

HRBA是没有任何意义的，但是LRBA非常有意义了，CKPT会将最早脏块在redo记录里面位置

即LRBA写到控制文件里面去，下次实例恢复读取控制文件就知道从redo记录的哪个位置开始恢复数据块

    ■被修改过的块，在oracle中都被统称为脏块.所有的脏块被一个链表串起来,称做检查点队列.在buffercache中,每一个块都有一个buffer header 简称BH,在BH中有一个ckptq项。

    ■buffer header记录对应块在Buffer cache中的地址，脏块对应   的重做记录在日志文件中的位置，另外还有前一个节点、后一个节点的地址。

    ■ckptq项此项目中记录了指向检查点队列上一个块和下一个块的指针.如果某一个块不在检查点队列中,他的ckptq项为空.通过ckptq项oracle将所有的脏块串成了一个双向链表.这个双向链表就是检查点队列。

    ■只有脏块才会在检查点队列中,非脏块的ckptq为空。

    ■ 每个块在它变脏时，会被链接到检查点队列的末尾。就好像排队一样，9:00来的人站在第一位，9:05来的人排第二位，以后每来一个人都站在   队伍的末尾，这个队伍就是按来到的时间顺序排列的一个队列。检查点队列就是这样，块在变脏时会被按照Low RBA的顺序（第一次对比数据   块修改对应的Redo Byte Address）链到末尾。

    ■ 当块首次被更改时,块会立即被加进检查点队列.如果检查点队列中的脏块再次被修改,并不会改变其在
检查点队列中的位置。因此检查点队列是按块变脏的时间顺序，将块排成了一个队列。

    ■检查点队列就是这样，块在变脏时会被按照Low RBA的顺序（第一次对比数据   块修改对应的Redo Byte Address）链到末尾。其实,按照lrba来排列,就是按照块首次被修改的顺序来排列.

■检查点队列的头，又被称为检查点位置，Checkpoint postion。总之，检查点位置就是检查点队列头。检查点队列头节点（也就是检查点位置）的信息，Oracle会频繁的将它记录到控制文件中，而且会很频繁的记录。一般是每隔三秒，有一个专门的进程CKPT，会将检查点位置记录进控制文件。

■检查点位置对应的日志地址（RBA）又总是被记录在控制文件中。如果发生系统崩溃，这个最后的检查点位置就是实例恢复运用日志的起点

Oracle会定期唤醒DBWn从检查点队列头开始，沿着检查点队列的顺序，刷新脏块（数据缓冲区里的脏数据块），CKPT进程使用非常轻量级的控制文件更新协议，将当前的最低RBA写入控制文件。在刷新脏块的同时，仍可以不断的有新的脏块被链接到检查点队列的尾部。

定期唤醒DBWn刷新脏块的操作，Oracle就称为增量检查点。因为增量检查点可以连续地进行，因此检查点RBA可以比常规检查点更接近数据库的最后状态，从而在数据库的实例恢复中可以极大地减少恢复时间。

完全

检查

点

完全检查点发生时,将不能有新的脏块产生,直到完全检查点完成

1.记下当前的scn, 将此scn之前所有的脏块一次性写完

2.将该scn号同步更新控制文件和数据文件头。

3.把新的连机重做日志的第一重做记录的RBA写进数据文件头

可以引起完全检查点的四个动作  
a)正常关闭数据库:shutdown immediate
b)手动检查点切换:alter system checkpoint; 
c)日志切换：alter system switch logfile;
d)数据库热备模式：alter database begin backup; 

增量

检查点

1）增量检查点使检查点位置前移。进而缩短实例恢复需要的日志起点和终点之间的距离，触发增量检查点越频繁，实例恢复的时间越短，但数据库性能受到频繁IO影响会降低。 

2）增量检查点并不会去更新数据文件头，以及控制文件中数据库SCN以及数据文件条目的SCN信息，而只是每3秒由CKPT进程去更新控制文件中的lowcache rba信息， 也就是检查点的位置。

3）如果发生了实例崩溃，只需要在日志文件中找到检查点位置(low cache rba),从此处开始应用所有的重做日志文件，就完成了前滚操作。实例崩溃后，再次启动数据库，oracle会到控制文件中读取low cache rba， 这就是检查点位置。从此处开始应用重做日志，应用到on disk rba的位置。on diskrba是磁盘中重做日志文件的最后一条重做记录的rba.

select CPDRT,CPLRBA_SEQ||'.'||CPLRBA_BNO||'.'||CPLRBA_BOF "LowRBA",CPODR_SEQ||'.'||CPODR_BNO||'.'||
CPODR_BOF "0n disk RBA",CPODS,CPODT,CPHBT from x$kcccp;CPDRT Low RBA         On disk RBA     CPODS            CPODT                     CPHBT
---------- --------------- --------------- ---------------- -------------------- ----------35 686.124.0       686.220.0       2325376          03/02/2008 15:18:54   648319278CPDRT列是检查点队列中的脏块数目.
CPODS列是on disk rba的scn  
on disk rba是磁盘中重做日志文件的最后一条重做记录的rba.  如果某条命令的重做记录的rba高于on disk rba，那说明此重做记录还没有被写进日志文件中，崩溃发生时，他是不可能被恢复的.
on disk rba是oracle前滚操作的终点.
on disk    顾名思义 就是'在磁盘上'的意思.比这个更高的rba,都在log buffer中,还没有来的急被写进磁盘中的日志文件.所以是不能被用于恢复的.
CPODT列是on disk rba的时间戳
CPHBT列是心跳

SQL> alter system set log_checkpoints_to_alert=true;
系统已更改。
步骤2:将增量检查点的切换频率定为300秒.log_checkpoint_timeout
该参数用于表示检查点位置和重做日志尾之间的时间间隔,以秒为单位,
默认情况下是1800秒,
这个参数实际上表示了脏块保持脏状态的最长时间。
如果它被定为1800秒,没有脏块保持1800秒后,还是为脏
LOG_CHECKPOINT_INSTERVAL
该参数是表示检查点位置和重做日志末尾的块的数量.以OS表示.LOG_CHECKPOINT_TIMEROUT及LOG_CHECKPOINT_INSTERVAL参数，
根据这个参数，Oracle计算出在内存中累积的dirty buffer所需
的日志恢复时间，如果到达该参数指定的时间，则增量检查点进程
被触发。该参数如果为0，ORACLE则会根据，Oracle将根据产生脏
块的速度、存贮硬件的性能自动调节检查点的频率，让DBWN进程自
身尽量减少写入量，这样虽然实现了性能最大化，但实例恢复时间
可能会比较长
SQL> alter system set log_checkpoint_timeout=300;[单位是秒]
系统已更改。

触发命令：

SQL>alter system checkpoint local; 这条命令显示的触发一个局部检查点。

对于某些操作，局部检查点是必须的，并会自动执行。

比如：表空间offline,数据文件offline,删除extent,表truncate,begin backup(将表空间置于备份模式）等。Oracle会根据需要自动执行

CKPT每3秒一次将检查点位置记录进控制文件,当然同时被记录进控制文件的还有'心跳'等其他信息.

CKPT每3秒一次的工作和CKPT定期触发DBWR，这两项操作合一起被称为--增量检查点.

该组件包含3个主要特性，可以加快系统在故障后的恢复，提高系统的可用性。

Fast-Start Checkpointing 特性在Oracle 8i中主要通过参数FAST_START_IO_TARGET来实现

fast_start_io_target
该参数用于表示数据库发生Instance Recovery 的时候需要产生的IO总数,他通过v$filestat的AVGIOTIM来估算的.比如我们一个数据库发生Instance Crash后需要在10分钟内恢复完毕,假定OS的IO每秒为500个,那么这个数据库发生Instance Recovery的时候大概产生500*10*60=30,000次IO,也就是我们将可以把fast_start_io_target设置为30000

在9i之前DBA主要靠fast_start_io_target间隔时间等方式来设置增量检查点的频率，比如可以让Oracle每10分钟发生一次增量检查点。如果这个数字设置不合适，对数据库性能的影响是很大的。而且有可能造成实例恢复时间过长

在Oracle 9i中，Fast-Start Checkpointing主要通过参数FAST_START_MTTR_TARGET来实现。

mttr是mean time to recovery的简写，该参数定义数据库进行Crash恢复的时间，单位是秒，取值范围是在0~3600秒之间。

在9i之后，特别是到了10g中，检查点已经相当的智能化了，很少会成为I/O问题的原凶。9i中设置fast_start_mttr_target参数为你所期望的实例恢复时间，系统将自动控制增量检查点的频率。比如，你希望实例恢复可以在5分钟内完成，你可以将此参数设置为300，也就是300

当设置了fast_start_mttr_target后,fast_start_io_target这个参数将不再生效,从9I后fast_start_io_target这个参数被oracle废除了

Oracle 10g自动检查点调整

从Oracle 10g开始，数据库可以实现自动调整的检查点，使用自动调整的检查点，Oracle数据库可以利用系统的低I/O负载时段写出内存中的脏数据，从而提高数据库的效率。因此，及时数据库管理员设置了不合理的检查点相关参数，Oracle仍然能够通过自动调整将数据库的Crash Recovery时间控制在合理的范围之内。

当FAST_START_MTTR_TARGET参数未设置，自动检查点调整生效。

通常，如果必须严格控制实例或节点恢复时间，那么可以设置FAST_START_MTTR_TARGET为期望时间值；如果恢复时间不严格控制，那么可以不设置FAST_START_MTTR_TARGET参数，从而启用Oracle 10g的自动调整特性

FAST_START_MTTR_TARGET

■如果此参数设置的值超出了硬件实际的限制，比如你将它设置为60，你期望无论在任何情况下，数据库都可以在1分钟内完成实例恢复，但根据数据库的脏块生成速度、存储设备的写性能，1分钟内根本无法完成实例恢复。这时候Oracle会自动设置合适的fast_start_mttr_target参数值，我们可以在参数文件中看到修正后的参数值，也可以在V$instance_recovery视图中的Target_mttr列中看到实际的值

■如果设置了FAST_START_MTTR_TARGET参数，就不要用早期的一些参数，容易引起冲突。

■注意点：如果将fast_start_mttr_target设置为非0

    1）将启用检查点自动调整机制。

    2）log_checkpoint_interval参数将被覆盖掉。

    3）90% OF SMALLEST REDO LOG(Oarcle 内部机制)，从上次切换后算起，累计日志为             一个日志组大小的90%时，做一次检查点切换。

     4）每3s查看checkpoint队列脏块的写出进度，这个3秒是Oracle强调的增量检查点特性之              一。注意，3s并不触发检查点，它只是记录当时的检查点位置，并将相关信息写入到              controlfile。

SQL> show parameter fast_start_io

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

fast_start_io_target integer 0

SQL> show parameter interval

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

log_checkpoint_interval integer 0

缺省情况下，在Oracle 9i中，FAST_START_IO_TARGET和LOG_CHECKPOINT_INTERVAL参数已经被设置为0.

在Oracle 9i R2开始，Oracle引入了一个新的视图提供MTTR建议

SQL> select * from v$mttr_target_advice;MTTR_TARGET_FOR_ESTIMATE ADVICE_STATUS DIRTY_LIMIT ESTD_CACHE_WRITES ESTD_CACHE_WRITE_FACTOR ESTD_TOTAL_WRITES ESTD_TOTAL_WRITE_FACTOR ESTD_TOTAL_IOS ESTD_TOTAL_IO_FACTOR------------------------ ------------- ----------- ----------------- ----------------------- ----------------- ----------------------- -------------- --------------------

该视图评估在不同FAST_START_MATTR_TARGET设置下，系统需要执行的I/O次数等操作。用户可以根据数据库的建议，对FAST_START_MTTR_TARGET进行相应调整。

这个建议信息的收到Oracle 9i新引入的初始化参数statistics_level的控制，当该参数设置为Typical或ALL时，MTTR建议信息被收集：

SQL> show parameter statistics_levelNAME TYPE VALUE------------------------------------ ----------- ------------------------------statistics_level string TYPICAL

也可以通过v$statistics_level视图来查询MTTR_Advice的当前设置：

SQL> select * from v$statistics_level where STATISTICS_NAME='MTTR Advice';STATISTICS_NAME DESCRIPTION SESSION_STATUS SYSTEM_STATUS ACTIVATION_LEVEL STATISTICS_VIEW_NAME SESSION_SETTABLE---------------------------------------------------------------- -------------------------------------------------------------------------------- -------------- ------------- ---------------- ---------------------------------------------------------------- ----------------MTTR Advice Predicts the impact of different MTTR settings on number of physical I/Os ENABLED ENABLED TYPICAL V$MTTR_TARGET_ADVICE NO