FINISH_REDEF_TABLE必须加SX锁以确保元数据原子切换，阻塞源于其与DML的ROW EXCLUSIVE锁不兼容；压至1秒内需提前清事务、禁新写入、多轮SYNC并低峰执行。
Oracle分区表在线转换本身不直接导致高并发阻塞，真正引发阻塞的是 DBMS_REDEFINITION 在 FINISH_REDEF_TABLE 阶段执行的原子切换动作——它需要对原表加 SX（Share eXclusive）锁，而该锁与业务侧高频的 INSERT/UPDATE/DELETE 所需的 ROW EXCLUSIVE 锁**不兼容**。
FINISH_REDEF_TABLE 为什么必须锁表？
这一步不是“改结构”，而是“换皮”：把原表的段头（data object id）、统计信息、依赖对象（索引、约束等）全部迁移到新分区表上，并让所有 SQL 立刻看到新结构。Oracle 必须确保切换瞬间无任何 DML 正在修改原表数据页，否则会出现元数据错乱或数据丢失。
常见现象是应用线程在 enq: TX - row lock contention 或 library cache lock 上长时间等待，v$session 中能看到大量会话状态为 ACTIVE 但 EVENT 是锁等待。
-
FINISH_REDEF_TABLE默认会尝试获取SX锁，若已有未提交事务持有TX锁，它会一直等，直到超时（默认 60 秒）或被 kill - 即使业务事务都很短，只要并发写入密度高（比如每秒数百次 INSERT），就极大概率撞上锁争用窗口
- 该操作无法通过 hint 或参数跳过锁检查，是 Oracle 内核强制行为
如何把阻塞时间压到 1 秒内？
关键不是避免锁，而是让锁等待时间不可感知。核心思路是：提前清空原表上的活跃事务，再在低峰期快速执行 FINISH_REDEF_TABLE。
- 切换前 5 分钟，主动 kill 掉所有持有原表
TX锁的会话：ALTER SYSTEM KILL SESSION ', ' IMMEDIATE - 禁止新事务写入原表：在应用层加开关，或临时
REVOKE INSERT,UPDATE,DELETE ON old_table FROM app_user（注意触发器可能绕过权限） - 用
DBMS_REDEFINITION.SYNC_INTERIM_TABLE多跑几次，确保中间表增量已追平，减少FINISH阶段内部同步耗时 - 执行
FINISH_REDEF_TABLE前，先查v$locked_object确认原表无任何OBJECT_ID记录
为什么 PMOP 模式下更容易出问题？
PMOP（Parallel Maintenance of Partitions）是 Oracle 19c 引入的分区维护并行化机制，但它只作用于 ALTER TABLE ... SPLIT/MERGE/EXCHANGE PARTITION 类操作，不参与 DBMS_REDEFINITION 流程。所谓“PMOP 导致阻塞”其实是误判——真实原因是：
- 运维同学在重定义中途，顺手执行了
ALTER TABLE ... ADD PARTITION（触发 PMOP），结果该 DDL 又要抢同一张表的DDL锁，和FINISH_REDEF_TABLE形成死锁链 - PMOP 自身会启用并行进程（
PX），若系统parallel_max_servers不足，会导致后台进程排队，间接拖慢SYNC_INTERIM_TABLE的增量应用速度，延长整体窗口 - 部分 DBA 把
DBMS_REDEFINITION和DBMS_PARALLEL_EXECUTE混用，后者若配置不当，会在原表上建临时作业表并加锁，干扰重定义
最常被忽略的一点：重定义完成后，原表并未自动删除，而是被重命名为 INT$_。如果忘记 DROP TABLE，它的段仍占用 buffer cache 和 shared pool，后续大查询可能因 shared pool latch 争用出现隐性延迟——这和阻塞无关，但会让问题排查绕远路。
