enq: ko - fast object checkpoint 是真实存在的等待事件，由 direct path read 触发对象级检查点导致；enq: ro - fast object reuse 与之不同，发生在 truncate 等 ddl 后空间重用时，二者机制、根源及处理方式均不相同。
enq: ro - fast object checkpoint 这个等待事件在 oracle 12c 中并不存在——你看到的很可能是误记或混淆。真实存在的、常被拼错/看混的是：
-
enq: KO - fast object checkpoint（正确，K-O，代表 Kernel Object） -
enq: RO - fast object reuse（R-O，出现在 TRUNCATE 或 DROP 操作后对象空间快速重用时）
而标题里写的 enq: RO - fast object checkpoint 是一个无效组合：RO 锁与 checkpoint 逻辑不搭；checkpoint 相关的 enqueue 类型是 KO，不是 RO。
所以第一步必须确认：你实际查到的等待事件到底是哪一个。
怎么确认当前真实的等待事件名
别靠眼睛扫，直接查 v$session_wait 或 v$session：
SELECT sid, event, p1raw, p2raw, seconds_in_wait FROM v$session_wait WHERE event LIKE 'enq:%';
重点看 event 列完整值，尤其是中间两个字母（KO / RO / TC / US 等）。Oracle 的 enqueue 名称是固定两位大写字母，RO 对应的是 ReUse，不是 Checkpoint。
- 如果输出是
enq: KO - fast object checkpoint→ 说明是 direct path read 触发的对象级检查点阻塞，和全表扫描、并行查询、大结果集 FETCH 相关 - 如果输出是
enq: RO - fast object reuse→ 说明是TRUNCATE或DROP后空间立即重用引发的锁争用，常见于高并发 DDL 场景
enq: RO - fast object reuse 的典型场景与处理
这个事件发生在 TRUNCATE TABLE（尤其带 REUSE STORAGE）之后，Oracle 需要快速标记段中 Extent 可被新插入复用，但多个会话同时尝试分配空间时会抢同一个 RO 锁。
- 常见于批量作业中频繁
TRUNCATE + INSERT /*+ APPEND */的 ETL 流程 - 现象：TRUNCATE 执行很快，但后续第一条 INSERT 卡住几秒，
v$session_wait显示enq: RO - fast object reuse，seconds_in_wait较高 -
p1是锁类型编号（RO=114），p2是对象号（obj#），可关联dba_objects定位具体表 - 它不反映 IO 或 DBWR 压力，而是内存中 extent map 重用路径的轻量级串行化控制
解决思路不是“优化截断”，而是绕开重用争用：
- 改用
TRUNCATE TABLE ... DROP STORAGE（默认行为），释放全部空间，下次 INSERT 会重新分配新 extent，避开 RO 锁 - 若必须复用存储（如防止高水位上涨），可提前执行
ALTER TABLE ... ALLOCATE EXTENT预分配几个空 extent，降低首次 INSERT 争用概率 - 避免在高峰期密集触发 TRUNCATE；加应用层排队或错峰
- 不推荐调隐藏参数（如
_smu_debug_mode），风险高且 Oracle 12c 后已收敛该路径
为什么不能把 KO 当成 RO 来处理
两者底层机制完全不同：
-
enq: KO是 CKPT → DBWR → 磁盘写入链路卡住，根源在 IO 子系统或 checkpoint 配置（如FAST_START_MTTR_TARGET过小、日志切换太勤、存储写延迟高） -
enq: RO是内存中 extent 位图操作的短暂互斥，无磁盘 IO，不涉及 DBWR/CKPT，纯内存结构同步 - 对
enq: KO去调_serial_direct_read或关 direct path，可能让全表扫描变慢十倍；对enq: RO去调 IO 参数则完全无效
一旦混淆，排查方向就全偏了：你会去查 v$session_wait 里 DBW0 的 db file async I/O submit，但它根本没在等这个。
最易被忽略的一点：Oracle 12c 在启用 INMEMORY 或 SEGMENT ADVISORY 时，TRUNCATE 可能触发额外元数据刷新，加剧 enq: RO 表现。此时 ALTER SESSION SET "_inmemory_truncate_optimization"=FALSE 可临时验证是否相关——但仅用于诊断，勿长期开启。
