mlog$物化视图日志表被争抢导致tx行锁，90%以上源于sync_interim_table对同一行反复读写冲突；需通过v$session和v$locked_object定位持锁会话及对象，避开高峰分批执行并确保表空间充足。
查清谁在锁 mlog$ 表
在线重定义期间出现 tx 行锁，90% 以上是 mlog$ 物化视图日志表被争抢所致。不是源表或目标表本身被锁，而是增量同步时对 mlog$ 的同一行反复读写引发冲突。
执行以下查询定位持锁会话和具体对象：
SELECT blocking_session, sid, event, sql_id FROM v$session WHERE event = 'enq: TX - row lock contention' AND blocking_session IS NOT NULL;
再用该 blocking_session 查它正在操作的对象：
SELECT object_name, object_type FROM v$locked_object lo JOIN dba_objects o ON lo.object_id = o.object_id WHERE lo.session_id = &blocking_sid;
若 object_name 是类似 MLOG$_T 或 LOG$_T 的名字，基本坐实问题根源。
避免 sync_interim_table 触发高冲突
DBMS_REDEFINITION.SYNC_INTERIM_TABLE 本质是把源表 DML 日志（即 MLOG$）里的变更批量应用到中间表，同时清空日志。这个“清空”动作会对 MLOG$ 加行级独占锁，而此时源表仍在持续写入，两者撞在同一行上就卡死。
缓解方式不是调参数，而是控制节奏：
- 避开业务高峰执行
SYNC_INTERIM_TABLE，尤其避免在统计信息自动收集窗口（默认夜间）前后 2 小时内运行 - 单次同步数据量别超过 5 万行；可通过
WHERE子句分批，例如WHERE rowid BETWEEN ... AND ... - 确认
MLOG$所在表空间有足够空闲，否则清理日志时 IO 延迟会放大锁等待时间
重定义失败后残留物化视图日志的清理
如果因表空间满（ORA-23539）导致重定义中断，系统会留下未清理的 MLOG$ 和中间表，但状态已损坏，无法直接重试。
必须手动清理才能继续：
- 先查残留日志：
SELECT mview_name FROM user_mviews WHERE master = 'T';（T是原表名） - 删日志：
DROP MATERIALIZED VIEW LOG ON T; - 终止挂起的重定义：
DBMS_REDEFINITION.ABORT_REDEFINITION('LUCIFER', 'T'); - 确认
v$session中无残留DBMS_REDEFINITION相关会话，再重新开始
注意：不要跳过 ABORT_REDEFINITION 直接删表或日志，否则元数据不一致可能引发后续 DDL 报错。
为什么不能靠 kill session 解决根本问题
看到 TX - row lock contention 就去杀 blocking_session，往往治标不治本。因为：
- 被杀会话释放的是当前事务锁，但
MLOG$清理逻辑本身就会重入，下次SYNC_INTERIM_TABLE还会触发同样争抢 - 若源表 DML 频率高，新会话立刻补上，锁链不断
- 频繁 kill 可能导致
MLOG$数据损坏，后续同步出错或丢数据
真正要盯住的是 MLOG$ 的生命周期——它只在重定义期间存在，且设计上就不该承受高并发写。只要还在用 SYNC_INTERIM_TABLE，就得接受它是个串行瓶颈点。复杂点在于：你没法绕开它，只能让它尽量短、尽量轻、尽量静。
