EXPLAIN_MVIEW输出结果默认写入MV_CAPABILITIES_TABLE表，需先执行@?/rdbms/admin/utlxmv.sql创建该表，再运行EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')，最后查询WHERE mvname='MV_NAME' AND capability_name='REFRESH_FAST'定位POSSIBLE值与MSGTXT原因。
EXPLAIN_MVIEW 输出结果写到哪？先建表再查
不建 MV_CAPABILITIES_TABLE 表，DBMS_MVIEW.EXPLAIN_MVIEW 就没法输出可读结果——它默认往这个表里写诊断数据，不是直接返回结果集。Oracle 不自带这个表，得手动执行脚本创建。
执行：@?/rdbms/admin/utlxmv.sql（路径可能因 Oracle 安装位置略有差异，但基本是这个）。建完后，再跑：EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME');
- 别用 SELECT 语句直接调用函数重载版本，容易漏字段或格式错乱
- 如果只传一个参数（物化视图名），它默认写入
MV_CAPABILITIES_TABLE；传两个参数（如带statement_id）可用于多 MV 并行诊断 - 查结果时务必加过滤：
WHERE mvname = 'MV_NAME' AND capability_name = 'REFRESH_FAST'，否则一堆 rewrite/pct 能力信息会干扰判断
REFRESH_FAST 行的 POSSIBLE='N' 是判决书，MSGTXT 是人话解释
POSSIBLE = 'N' 就代表 FAST 刷新彻底不可用，不是“暂时不行”，而是定义层硬性不满足。这时候必须看同一行的 MSGTXT 字段，它才是 Oracle 内部校验失败的真实原因。
-
MSGNO = 2005：基表没日志，或日志缺ROWID/SEQUENCE—— 检查USER_MVIEW_LOGS中对应表的ROWIDS和SEQUENCE是否为YES -
MSGNO = 2012：SELECT 列表里漏了某张基表的ROWID—— 即使只用主键 JOIN，也要显式写出t1.ROWID、t2.ROWID -
MSGNO = 2025：含聚合但没配齐COUNT(*)+ 所有GROUP BY列的COUNT(col)—— 这不是语法错误，是 Oracle 快速刷新协议强制要求 -
MSGNO = 2031：外连接 WHERE 里用了OR、!=或函数 —— 比如WHERE t1.status = 'A' OR t1.status = 'B'就直接禁用 FAST
子查询一出现，FAST 就永久关闭，别试绕过
Oracle 19c 对子查询是零容忍：只要 SELECT 或 WHERE 里有 EXISTS、IN、NOT EXISTS、ANY、ALL，DBMS_MVIEW.EXPLAIN_MVIEW 就会直接返回 REFRESH_FAST 的 POSSIBLE = 'N'，且 MSGTXT 通常不提示具体哪句，只说 “complex SQL” 或 “subquery not allowed”。
- 这不是配置疏漏，是内核级限制：子查询破坏增量变更的确定性映射，Oracle 刷日志时根本无法定位哪几行该重算
- 试图用 hint、改写 or 条件、加索引都无效——解析阶段就砍掉 FAST 路径，后续优化器不参与
- 唯一可行解是重写为 JOIN：比如
WHERE deptno IN (SELECT deptno FROM dept WHERE loc = 'DALLAS')改成JOIN dept ON emp.deptno = dept.deptno AND dept.loc = 'DALLAS'，但前提是两张表都有完整日志（含deptno和loc的SEQUENCE）
为什么刚建完 MV 就报 REFRESH_FAST 不可能？检查三个硬条件
新建物化视图后立刻跑 EXPLAIN_MVIEW 报 POSSIBLE = 'N'，大概率卡在最基础的三件事上，而不是 SQL 多复杂：
- 基表没建日志，或日志字段不匹配：比如 MV 里用了
UPPER(ename)，日志却只建在ename上——没问题；但如果 MV 里写了UPPER(ename) AS name，而日志没包含ename原始列，就会失败 - 基表缺主键或唯一约束：
REFRESH FAST ON COMMIT强制要求所有基表有PRIMARY KEY或UNIQUE NOT NULL约束，否则连日志都建不稳 - JOIN 类型越界：用了
FULL OUTER JOIN或RIGHT OUTER JOIN，哪怕逻辑等价于 INNER，Oracle 也拒绝 FAST —— 只认INNER JOIN和部分受限的LEFT OUTER JOIN
这些点不解决，后面调优索引、改参数、加并行全无意义——能力校验在最顶层就否决了。
