再次翻看eyle深入浅出，记录关于检查点和实例恢复的一些笔记

oracle 8I的增量检查点主要是通过fast_start checkpointing特性来实现，oracle 8I开始,fast_start checkpointing特性，包含在oracle企业版本的fast_start fault recovery组件中。

该组件还包括fast_start parallel rollback和fast_start on_demand rollback。

fast_start checkpointing特性主要是通过fast_start_mttr_target(instance 恢复期望时间)参数来实现,表示instance crash恢复所需的时间

增量检查点连续地进行，把checkpoint queue中最低的low rba写入disk中（dbwr会根据checkpoint queue的low rba顺序写入到disk），控制文件使用轻量级的控制文件更新协议将最低的low rba写入控制文件，这样不仅可以让rba更接近与数据库的最新状态，减少instance恢复时间，也能平衡常规检查点时的I/O冲突，checkpoint queue中的是按照low rba排序的。如果数据块进行多次修改，此dirty块在checkpoint queue的位置不会改变

SQL> select target_mttr,estimated_mttr,ckpt_block_writes from v$instance_recovery;

TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES

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

90 50 47

v$instance_recovery视图中的target_mttr表示的是instance恢复的期望时间，而estimated_mttr是根据redo和dirty buffer估算的instance恢复的时间，ckpt_block_writes则是检查点已经写出的数据块的数量，初始化参数fast_start_mttr_target设置较大或较小时，target_mttr参数值可能并不一定等于fast_start_mttr_target参数.

在v$instance视图中如果target_mttr<=estimated_mttr时，系统将会执行检查点。如果在繁忙系统中，target_mttr长时间大于estimated_mttr，很可能是系统正需要执行大规模写出，或者checkpoint incomplete.这时候进一步查看v$log查看checkpoint对于redolog切换检查点是否完成，利用linux的iostat工具查看磁盘I/O等信息，是否因为磁盘的I/O存在瓶颈，导致dbwr写入进程慢，而导致checkpoint没有及时完成，进而导致根据redo和dirty buffer计算而来的estimated_mttr大于target_mttr等。

从oracle 10g开始，数据库可以实现自动调整检查点，oracle数据库使用系统低I/O负载时写出dirty buffer，提高执行效率，设置fast_start_mttr_target=0，自动调整检查点将生效，如果希望严格控制crash恢复时间，可以设置fast_start_mttr_target值，控制instance恢复时间，反之则可以设置fast_start_mttr_target为0而启动10g的自动调整的检查点功能。

数据库异常关闭之后，下次启动时，oracle会自行进行instance recovery，实例恢复又可分为cache recovery和transaction recovery

Cache recovery

读取日志，从最后完成的检查点开始应用redo，这个过程就是前滚rolling forward，也称cache recovery，完成前滚后，数据库可以被打开访问。

Transaction recovery

Oracle回滚未提交的事务，oracle使用两个特性fast_start on_demand rollback和fast_start parallel rollback增加transaction recovery阶段效率，这也就是上面所提的oracle 8I企业版的组件fast_start fault recovery另外两个组成部分。

使用fast-start on-demand rollback特性，oracle允许在打开数据库之后开始新的事务，如果有用户进程访问那些未提交事务的记录，oracle再予以回滚，需要时再予以回滚，在fast-start on-demand rollback中，后台进程smon调度使用多个服务器进程parallel回滚一个事务集。

Fast-start parallel rollback主要对于长时间运行的dml等操作进行事务回滚，smon自动决定何时开始并行回滚并且在多个进程之间分配工作。Fast_start parallel rollback还可以用于内部事务恢复Intra-transaction recovery,在内部事务恢复中，一个大事务可以被拆分，分配给几个服务器进程并行回滚。

可以Fast_start_parallel_rollback来控制并行回滚：

False 禁止fast-start parallel rollback

Low 限制恢复进程不超过2倍的cpu_count

High 限制回顾进程不能超过4被的cpu_count