一、核心矛盾
缓冲区脏块数量直接制衡两大指标：
脏块多 → 实例崩溃恢复（Crash Recovery）耗时变长
频繁刷脏块 → 磁盘 I/O 压力陡增
Oracle 通过 ** 增量检查点（Incremental Checkpoint）** 动态平衡二者，也是该算法持续迭代的核心原因。
二、各版本特性演变
- Oracle 9i
正式引入 FAST_START_MTTR_TARGET 参数，手动指定实例恢复的目标耗时，以此控制增量检查点频率、约束脏块数量。 - Oracle 10g+
新增 ** 检查点自调优（Self-Tune Checkpointing）** 机制：
未设置 FAST_START_MTTR_TARGET：数据库自动根据脏块量调节检查点频率，优先压低 I/O 负载，代价是宕机恢复时间偏长。
隐含参数 _DISABLE_SELFTUNE_CHECKPOINTING = TRUE：关闭自调优，恢复为传统模式。
显式设置 FAST_START_MTTR_TARGET > 0：启用快速启动检查点，强制控制恢复时长，Oracle 主动提升刷脏块频率。
取值限制：最大 3600 秒；不能过小（要求 Buffer Cache 脏块数不低于 1000）。
设置 FAST_START_MTTR_TARGET = 0：关闭检查点自调优，DBWR 刷脏块频率降低，宕机恢复时间进一步拉长。
三、配套规则与视图 - 监控视图
通过 V$INSTANCE_RECOVERY 查看增量检查点、预估 MTTR（平均恢复时间）。 - 参数优先级 & 兼容要求
启用 FAST_START_MTTR_TARGET 时，必须移除 / 置 0以下旧参数（前两者优先级更高，会覆盖新参数）：
LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_TIMEOUT
FAST_START_IO_TARGET - 版本限制
Fast-Start Fault Recovery（快速启动故障恢复）特性仅 Oracle 企业版支持，可通过如下 SQL 验证：
sql
SELECT * FROM v$option WHERE PARAMETER='Fast-Start Fault Recovery';
返回 VALUE=TRUE 代表特性可用。
四、生产环境选型建议
业务优先低 I/O、可接受较长宕机恢复（非核心、低可用要求）：不配置 FAST_START_MTTR_TARGET，使用 10g + 默认自调优。
核心业务、要求快速宕机恢复（高可用场景）：合理设置 FAST_START_MTTR_TARGET（建议数十～数百秒），同时清理上述三类旧检查点参数。
极致降低刷盘 I/O、对恢复时长无要求：设置 FAST_START_MTTR_TARGET = 0