checkpoint completed 高表明DBWR写不过来，根因是I/O慢、脏块多或DB_WRITER_PROCESSES不足；v$log中ACTIVE组不释放、归档慢或FAST_START_MTTR_TARGET过小会加剧该问题。
checkpoint completed 等待本身不是直接阻塞业务的等待事件，但它在高峰期频繁出现，往往意味着底层已出现严重压力——真正卡住 DML 的是 log file switch (checkpoint incomplete)，而 checkpoint completed 是它的“前兆”或“伴生信号”。
查 v$log 状态：ACTIVE 组长期不释放就是根因
高峰期日志切换密集，如果 v$log 里多个组反复卡在 ACTIVE 状态（不是 CURRENT，也不是 INACTIVE），说明 DBWR 没来得及把脏块刷完，检查点就一直没完成。
执行这个语句看实时状态：
SELECT group#, bytes/1024/1024 size_mb, status, sequence# FROM v$log ORDER BY group#;重点关注
status = 'ACTIVE' 的组是否持续存在、序列号是否长时间不推进。这不是参数能调出来的，是 I/O 或写入节奏跟不上。
别只盯 LGWR，DBWR 写不过来才是真瓶颈
checkpoint completed 等待的本质是 CKPT 进程通知 DBWR 写完后，还要等 DBWR 实际落盘并更新文件头。所以它高，大概率是因为：
- 数据文件所在磁盘延迟高（
db file parallel write平均等待 > 5ms 就危险） - 脏块太多且集中（比如批量 UPDATE 大表、无索引 DELETE）
-
DB_WRITER_PROCESSES设置过低（默认 1，OLTP 建议 ≥ 4） - 缓冲区命中率骤降（查
v$sysstat中physical writes突增，db block gets from cache比例下降）
CKPT 不写数据，它只是发号施令；真干活的是 DBWR，别错怪进程。归档路径慢会连带拖垮 checkpoint
即使你没开归档，只要设置了 LOG_ARCHIVE_DEST_1（哪怕指向本地目录），归档进程 ARCH 就会启动。如果归档目标在 NFS、慢速 SATA 盘或空间不足，log file switch (archiving needed) 就会堆积，间接导致 LGWR 等待归档完成，进而让下一轮检查点无法及时触发——于是 checkpoint completed 耗时拉长，v$log 里 ACTIVE 组越积越多。
验证方式：
SELECT dest_id, status, destination, archived_thread#, archived_seq# FROM v$archive_dest WHERE status = 'VALID';再结合
v$archive_dest_status 看 error 列有没有报错。
FAST_START_MTTR_TARGET 设得太激进会雪上加霜
这个参数本意是控制崩溃恢复时间，但它会强制 Oracle 更频繁地触发增量检查点。设成 30 秒？那每 30 秒 DBWR 就可能被唤起刷一波脏块——高峰期并发一高，多个检查点重叠，I/O 队列直接打满。
检查当前值：
SHOW PARAMETER FAST_START_MTTR_TARGET;如果值 checkpoint completed 在高峰时段集中爆发，大概率就是它在作祟。建议先设为 0（关闭自动 MTTR 目标），观察
v$sysstat 中 background checkpoints completed 是否回落。
真正要命的从来不是等待事件的名字，而是 ACTIVE 状态卡住的日志组背后，DBWR 正在排队等一个永远不返回的 I/O 完成通知。
