你知道吗？ALTER TABLE ... MOVE PARTITION ... ONLINE 并不等同于真正意义上的“完全无锁”。它必须满足一系列严格条件，例如提前启用行移动、目标分区中不存在未提交事务、表上具备主键或唯一索引，并且使用 ROW STORE COMPRESS ADVANCED 等。如果这些前提没有满足，执行过程中依然可能短暂阻塞 DML 操作，甚至直接报错失败。另外，分区移动完成后，还需要手动检查并重建局部索引或全局索引，否则后续查询可能出现异常或性能下降。
ALTER TABLE ... MOVE PARTITION ... ONLINE 本质上支持在线移动分区，但这里的“在线”并不是简单加上 ONLINE 就一定不会锁表。实际执行时，仍有可能出现短暂 DML 阻塞，严重时甚至会直接中断并报错，关键就在于是否满足 Oracle 12c 在线移动分区的几个硬性要求。
为什么加了 ONLINE 仍然会锁表或执行失败
问题的根源通常不是 SQL 语法错误，而是底层执行机制受限。因为 MOVE PARTITION 在线操作依赖行移动能力（row movement）以及索引可维护性，这两个条件缺一不可。
ALTER TABLE t1 ENABLE ROW MOVEMENT必须提前执行，否则会直接报ORA-14102- 目标分区不能存在未提交事务：可通过查询
V$TRANSACTION和V$SESSION确认是否有人正在该分区上执行长事务 DML - 必须具备主键或唯一索引：全局索引维护依赖它来准确定位行位置，若缺失，可能导致索引重建失败，或使索引进入
UNUSABLE状态 - 不要使用
COMPRESS FOR OLTP：在线 MOVE 仅支持ROW STORE COMPRESS ADVANCED ONLINE，压缩类型使用不当时，可能被静默忽略，也可能直接报错
MOVE 后索引状态必须手动检查
Oracle 虽然将其定义为“在线”操作，但这并不意味着索引一定会被自动正确维护。局部索引通常不会自动重建，全局索引也可能在操作后变为无效。如果忽略这一步，后续查询可能走全表扫描，甚至直接报 ORA-01502。
- 局部索引（LOCAL）：必须显式重建对应索引分区，例如
ALTER INDEX idx_local REBUILD PARTITION p2 - 全局索引（GLOBAL）：应检查
DBA_INDEXES.STATUS和DBA_IND_PARTITIONS.STATUS，确认全部为VALID - 即使在语句中写了
UPDATE INDEXES ONLINE，也不能代替最终状态校验——它只影响索引维护时机，并不保证最终结果一定正常
真正影响业务连续性的几个隐藏风险点
所谓“在线”，是指操作期间通常允许并发执行 SELECT/INSERT/UPDATE/DELETE，但在分区移动过程中，Oracle 仍可能短暂持有 TX 锁，通常为毫秒级。至于影响大小，是行级锁还是更明显的阻塞，往往取决于是否正确启用了 ROW MOVEMENT 以及是否存在主键约束。
- 没有主键或唯一索引 → 全局索引无法正常维护 → Oracle 可能退化为串行化处理 → 锁持续时间变长，DML 排队现象会更明显
- LOB 列未单独处理 → 如果表中包含 LOB，
MOVE PARTITION不会同步移动 LOB 段，后续插入可能触发ORA-14647，通常需要拆分为两步处理 - 大量小分区批量移动 → 不建议通过循环逐个执行
MOVE PARTITION，因为锁窗口会叠加，风险更高，更适合优先评估使用DBMS_REDEFINITION作为替代方案
buffer busy waits（P3=4），或在 RAC 环境下同时出现 gc buffer busy acquire。如果只盯着“锁表”问题去调整参数，通常效果有限，甚至可能白费工夫。更合理的做法是先区分清楚等待事件类型，再针对性处理。
