物化视图手动刷新会被基表未提交事务的行锁阻塞，本质是oracle一致性读机制要求访问前镜像，而未提交事务导致undo不可达或日志行被锁。
物化视图手动刷新会阻塞在基表未提交事务的行锁上，不是“不能刷”，而是被卡住等锁 —— 本质是 Oracle 读一致性与 MV 刷新机制共同作用的结果。
DBMS_MVIEW.REFRESH 默认走一致性读，必须等基表事务释放行锁
Oracle 的 DBMS_MVIEW.REFRESH（尤其是 method => 'F' 或默认 FAST）在读取基表或物化视图日志（MLOG$_xxx）时，并非直接读最新数据，而是构造一致性读（CR）镜像。这个过程依赖 undo 和当前 SCN，但前提是它能访问到所有相关行的“前镜像”。如果某行正被另一个未提交事务修改（比如一个长事务正在 UPDATE 基表某条记录），该行会被加上 TX 锁，而 REFRESH 进程在尝试构建 CR 镜像时，会发现该行的前镜像不可达（undo 被覆盖或未生成），于是卡在 enq: TX - row lock contention 上，表现为“一直不返回”。
- 即使你只刷新单个 MV，只要它关联的基表有任意一行被未提交事务锁住，整个刷新可能停滞（尤其涉及 JOIN 或复杂谓词时）
-
ATOMIC_REFRESH => FALSE不解决此问题——TRUNCATE+APPEND 只跳过 MV 表本身的事务锁，但读基表/日志仍需一致性读 - 查等待：运行
SELECT sid, event, blocking_session FROM v$session WHERE event LIKE 'enq: TX%'，若blocking_session指向一个未提交的业务会话，基本可确认
物化视图日志（MLOG$_）本身也可能被未提交事务阻塞
FAST 刷新严重依赖 MLOG$_xxx 表中记录的变更。而该日志表的写入和读取同样受事务控制。如果有一个长事务正在对基表做 DML（且已触发日志写入），但尚未提交，那么该事务会持有 MLOG$_xxx 表中对应变更记录的行锁。此时 REFRESH 尝试读取这些日志行，就会被阻塞。
- 典型现象：
SELECT COUNT(*) FROM MLOG$_base_table返回非零值，但REFRESH卡住；查v$locked_object会看到MLOG$_base_table被锁 - 注意：
MLOG$_xxx是普通堆表，没有自带索引，高并发下snaptime$$和sequence$$字段缺失索引时，扫描更易争抢资源 - 重建日志不会自动清理已有锁，必须等原事务提交或回滚
为什么 COMPLETE 刷新有时也卡住？
很多人以为切 method => 'C' 就能绕过锁，其实不然。COMPLETE 刷新虽然不依赖日志，但它仍需对基表执行全量 SELECT。如果基表上有未提交事务修改了大量行，Oracle 构造一致性读所需的 undo 可能极大，甚至触发 ORA-01555（snapshot too old）；更常见的是，该 SELECT 语句本身会等待那些被锁住的行释放，导致刷新挂起。
- 验证方式：在刷新前，先手工执行 MV 定义中的 SELECT 查询（替换掉
FROM后的基表名），看是否同样卡住 - 临时解法：用
SET TRANSACTION ISOLATION LEVEL READ COMMITTED无效 —— MV 刷新不走用户会话隔离级别，由内核强制使用 SERIALIZABLE 级别保障一致性 - 真正有效的缓解：确保基表 DML 事务粒度合理（避免超长事务），或错峰执行刷新
最易被忽略的一点是：你看到的“不能刷新”，往往不是语法或权限问题，而是数据库在沉默地等待一个你根本没意识到的、早已遗忘的未提交事务 —— 它可能来自开发测试窗口、某个中断的脚本，甚至一个连错 schema 的 ad-hoc SQL。别急着调参，先查 v$transaction 和 v$session 找出那个 USED_UBLK > 0 且 STATUS = 'ACTIVE' 的会话。
