DBMS_MVIEW.EXPLAIN_MVIEW仅校验快速刷新的静态前提条件，不捕获运行时错误；它能查物化视图日志、ROWID、SELECT字段、聚合合规性等结构问题，但不能查权限不足、空间耗尽、数据冲突等动态故障。
DBMS_MVIEW.EXPLAIN_MVIEW 能查什么不能查什么
DBMS_MVIEW.EXPLAIN_MVIEW 不是用来查“刷新失败后发生了什么”，而是查“为什么根本不能走快速刷新”。它不捕获运行时错误（比如 ORA-00001 或 ORA-01652），只做静态语法与结构校验：物化视图日志是否存在、基表是否含 ROWID、SELECT 列表是否漏了关键字段、聚合是否满足 COUNT(*) + COUNT(col) 等硬性条件。
常见误用是等刷新报 ORA-12008 后才跑它——这时已经晚了。它解决不了约束冲突或临时表空间不足，但能提前告诉你：“这个 MV 根本不支持 FAST，别再试 method => 'F' 了”。
- 必须先执行
@?/rdbms/admin/utlxmv.sql创建MV_CAPABILITIES_TABLE表，否则报错ORA-00942 - 输出中重点看
CAPABILITY_NAME = 'REFRESH_FAST'对应的POSSIBLE值：若为'N'，再往下看MSGTXT和MSGNO -
MSGNO = 2005：基表没日志；MSGNO = 2012：SELECT漏了某张基表的ROWID；MSGNO = 2025：聚合定义不合规
为什么 DBMS_MVIEW.EXPLAIN_MVIEW 显示可能，但刷新还是报 ORA-12008
因为 EXPLAIN_MVIEW 只管“语法上能不能”，不管“运行时有没有权限、空间、数据一致性”。比如它说 REFRESH_FAST_POSSIBLE = 'Y'，但实际刷新时仍可能因以下原因崩在半路：
- 执行用户缺对基表的
FLASHBACK权限 → 报ORA-01031（被ORA-12008掩盖） - 物化视图日志表
MLOG$_xxx数据积压严重，导致内部MERGE INTO扫描全表 → 触发ORA-01652 - 基表有未提交的大事务，刷新 SQL 在读取
MLOG$_时遭遇ORA-01555快照太旧 - 跨 DBLink 刷新时，远端库版本太低（如 10.2.0.5），不支持当前 MV 类型的增量协议
此时 EXPLAIN_MVIEW 无能为力，必须开 10046 trace。
DBMS_MVIEW.REFRESH 失败后，怎么从 trace 里揪出真凶
不提前开 10046 trace，失败后基本无法还原上下文。Oracle 在刷新引擎崩溃时会截断调用栈，只把 ORA-12008 透出，真实错误（如 ORA-00001、ORA-01652）全埋在 trace 文件里。
- 刷新前务必执行：
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12' - 刷新失败后，立刻查：
SELECT value FROM v$diag_info WHERE name = 'Diag Trace'定位 trace 目录 - 找最新文件：
ls -t *ora_*.trc | head -1，然后grep "ORA-" your_trace.trc - 重点盯紧紧跟在
MERGE INTO MV_NAME或INSERT /*+ APPEND */语句之后的第一个ORA-错误——那才是根因
刷新卡住但没报错？先查 v$locked_object 和 atomic_refresh
表面无错误，但 DBMS_MVIEW.REFRESH 长时间不返回，大概率是锁或事务资源争用，而非 SQL 执行慢。
- 查锁源：
SELECT o.object_name, l.locked_mode FROM v$locked_object l, dba_objects o WHERE l.object_id = o.object_id，重点关注MLOG$_表和基表 - 检查
atomic_refresh参数：默认TRUE会让整个刷新在一个事务里完成，大 MV 容易撑爆 undo 表空间并锁死 - 生产环境建议显式传
atomic_refresh => FALSE，改用TRUNCATE + INSERT，降低锁粒度（副作用是刷新中 MV 短暂为空） - 若发现
v$session中有blocking_session非空且last_call_et > 3600，优先中止该会话，而不是硬等刷新
复杂点在于：trace 文件里的死锁图比任何 SQL 查询都可信，而 EXPLAIN_MVIEW 的输出必须和数据库版本、DBLink 远端能力交叉验证才能闭环——漏掉任一环，修复就只是在碰运气。
