ORA-12015 表示查询结构不满足快速刷新的硬性前提，而非语法错误；常见原因包括ANSI JOIN、缺失ROWID、无物化视图日志、含SYSDATE/聚合/子查询等，需用DBMS_MVIEW.EXPLAIN_MVIEW定位具体限制。
ORA-12015 根本不是语法错，而是能力不满足
报 ORA-12015: cannot create a fast refresh materialized view from a complex query 时，Oracle 并不是在说“你 SQL 写得丑”，而是在明确告诉你：**这个查询结构不满足 FAST 刷新的硬性前提**。它连尝试建日志或校验依赖都不做了，直接拒绝创建。常见诱因包括：
- 用了标准
LEFT JOIN（哪怕只是内连接，只要用 ANSI JOIN 语法）——Oracle 只认(+)外连接写法 - SELECT 列里缺基表的
ROWID（尤其多表连接时，每张基表的ROWID都得显式选出来） - 基表没建物化视图日志，或日志没含
ROWID/PRIMARY KEY/ 所有被 SELECT 或 WHERE 引用的列 - 查询里出现
SYSDATE、ROWNUM、聚合函数、子查询、UNION、CONNECT BY等任意一项
为什么 DBMS_MVIEW.EXPLAIN_MVIEW 比看错误码管用
错误信息只给结论，不给原因。执行 EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME'); 后查 PLAN_TABLE，重点关注：
-
CAPABILITY_NAME = 'REFRESH_FAST'对应的POSSIBLE值：若为'N'，说明 FAST 彻底不可用 -
MSGTXT字段：比如"complex SQL: outer join with OR in WHERE clause"或"materialized view log does not exist on table T1" -
MSGNO编号：2005=缺日志、2012=漏ROWID、2025=聚合不合规、2031=外连接含函数
这比反复改 SQL 猜错快得多。
分区表和跨库场景下，ORA-12015 更容易误判
这两类场景表面看是“查询复杂”，实际是底层支持缺失：
- 分区表上建 FAST 刷新 MV，必须显式创建含
PRIMARY KEY、ROWID和所有 SELECT 列的物化视图日志，仅靠表有主键不够 - 跨库（DB Link）时，
ORA-12015是必然结果——FAST 刷新依赖本地日志捕获变更，远程库无法同步日志，Oracle 直接禁用该模式，不提供任何绕过路径 - 含
CLOB/BLOB的基表，哪怕 MV 定义里根本没选这些列，只要基表存在 LOB 字段，FAST 就被硬性禁止
最容易被忽略的隐性条件
很多 DBA 查完日志、语法、连接写法都没问题，还是报 ORA-12015。这时要盯紧：
- 基表约束是否还有效？
ALTER TABLE ... DROP COLUMN或修改NOT NULL状态后，主键/唯一约束可能失效，USER_CONSTRAINTS.STATUS变成'DISABLED' - 物化视图日志是否覆盖新增列？加了新字段到 SELECT 但没补进
SEQUENCE(col1,col2,...)，日志就等于没记录变更 -
CAN_USE_LOG = 'NO'出现在USER_MVIEWS中，说明日志链已断——这不是配置问题，是 Oracle 内部状态已标记为不可用，重建日志是唯一解
这些点不报错、不告警，只静默让 FAST 退化，直到你查 EXPLAIN_MVIEW 才暴露。
