Checkpoint Completed等待事件表示会话正等待已触发但尚未完成的增量检查点结束，典型表现为LGWR日志切换时因DBWn未刷完脏块而阻塞，伴随告警“Checkpoint not complete”。
Checkpoint Completed等待事件的真实含义
这个等待事件不是“检查点完成”本身在等，而是会话在等待一个**已经触发但尚未落地的增量检查点结束**。典型场景是：lgwr正要切换日志，发现目标日志组仍为 active，因为 dbwn 还没把对应范围的脏块刷完——此时会话就卡在 checkpoint completed 上，所有 dml 暂停。
它和 log file switch (checkpoint incomplete) 是同一问题的两种表现，只是 Oracle 19c 更倾向用前者记录告警日志。关键判断依据是告警日志里是否出现类似：
Thread 1 cannot allocate new log, sequence 12345 - Checkpoint not complete
一旦看到这句，说明增量检查点推进已滞后于 redo 生成速度。
查清当前检查点进度与瓶颈点
别只看 v$sysstat 里的检查点计数，得定位“谁慢了”。优先执行以下查询：
-
SELECT * FROM v$instance_recovery;—— 关注ACTUAL_REDO_BLKS和TARGET_REDO_BLKS的差值，差得越大，说明 DBWn 落后越多 -
SELECT * FROM v$kcccp;—— 查CPLRBA_SEQ（Low RBA）和CPODR_SEQ（On Disk RBA），两者差距超过 2~3 个日志序列，就是明显延迟 -
SELECT event, time_waited_micro/1000000 sec FROM v$session_event WHERE event = 'Checkpoint Completed' ORDER BY time_waited_micro DESC;—— 看单次等待是否持续数秒以上
如果 v$instance_recovery 显示 ESTIMATED_MTTR > FAST_START_MTTR_TARGET，说明 Oracle 已判定当前写速跟不上要求，正在被动加速 DBWn，但 I/O 或 CPU 已成为瓶颈。
调整增量检查点频率的实操要点
Oracle 19c 中，FAST_START_MTTR_TARGET 是主控参数，它比 log_checkpoint_timeout 和 log_checkpoint_interval 更智能、更推荐使用。但直接设小值不等于有效：
- 设为
300（5 分钟）前，先确认磁盘吞吐能否支撑：DBWn 需在 5 分钟内写完当前脏块量，若数据文件在高延迟存储（如 NFS 或慢 SAN），反而引发更多write complete waits -
FAST_START_MTTR_TARGET不是硬上限，Oracle 会根据v$sysstat中的db block gets from cache和consistent gets from cache动态估算脏块生成速率，再反推写压力 - 禁用过时参数：
log_checkpoint_timeout在 19c 中仅作兼容保留，设了也基本不生效；log_checkpoint_interval若按 OS 块计算，容易因文件系统对齐问题误判，建议留默认值 0 - 观察效果必须看
v$instance_recovery的OPTIMAL_LOGFILE_SIZE：如果该值持续大于当前 online redo 日志大小，说明日志太小，频繁切换进一步挤压 DBWn 时间窗口
最容易被忽略的底层影响
增量检查点是否“平滑”，不只取决于参数，更取决于 Buffer Cache 内部结构和 I/O 调度能力：
- 检查点队列（Checkpoint Queue）头尾距离过大（可通过
x$bh中LRU_FLAG和CKPTQ字段估算），说明脏块老化不均，DBWn 总在追着写冷块，而新脏块又不断涌入——这时调小FAST_START_MTTR_TARGET只会让 DBWn 更忙，却不解决根本 - DBWn 进程数不足：19c 默认
db_writer_processes=1，但若数据文件数 > 8 或使用 ASM，应设为2或更高，并确认io_disk_speed统计值是否稳定 - 控制文件更新频率：CKPT 每 3 秒把 On Disk RBA 写入控制文件，若控制文件放在慢盘或高争用路径，会导致 CKPT 自身延迟，间接拖慢整个检查点推进节奏
真正有效的优化，往往始于看清 v$kcccp 和 v$instance_recovery 的实时差值，而不是一上来就改参数。
