ora-12054 是因物化视图定义含非确定性函数（如 sysdate、rownum）被 oracle 刷新机制硬性拦截所致，必须从源头移除；可用 dbms_mview.explain_mview 定位具体问题并替换为稳定列或改用 complete 刷新。
非确定性函数（如 SYS_GUID()、SYSDATE、ROWNUM）在 Oracle 物化视图中直接导致 ORA-12054，这不是配置疏漏，而是 Oracle 刷新机制的硬性拦截——必须从定义源头移除。
为什么 SYSDATE 和 ROWNUM 会让物化视图创建失败
Oracle 快速刷新依赖物化视图日志和基表变更的精确映射。一旦视图 SQL 中出现非确定性函数，系统就无法判断“同一行数据在不同时间点是否应被刷新”，于是直接拒绝创建。这不是警告，是校验阶段的终止动作。
-
SYSDATE每次执行返回不同值，Oracle 无法保证主从或刷新前后结果一致 -
ROWNUM依赖查询执行时的临时排序顺序，而快速刷新不重跑全量 SQL，只应用增量 delta -
UNION ALL或聚合（COUNT、SUM）虽不报错，但同样触发QSM-01106，需查RECOMMENDATION字段确认具体限制点
如何用 DBMS_MVIEW.EXPLAIN_MVIEW 定位真实卡点
别只看 ORA-12054，运行 DBMS_MVIEW.EXPLAIN_MVIEW('your_mv_name') 后查 MVIEW_EXCEPTIONS 表，重点盯 RECOMMENDATION 和 RELATED_TEXT：
-
RECOMMENDATION = 'NONDETERMINISTIC'→ 确认是否用了SYSDATE、SYS_GUID()、USER等上下文相关函数 -
RELATED_TEXT会标出问题 SQL 的具体行号，比如line 3: SELECT SYSDATE FROM ... - 若推荐值是
'AGGREGATE'，说明COUNT(*)或GROUP BY是主因，不是函数问题，别白改
替换非确定性函数的可行方案
不能简单删掉时间字段，得保留业务语义又满足刷新要求：
- 用基表中已有的时间列替代
SYSDATE，比如created_at或last_modified—— 这些是可追踪的稳定列 - 去掉
ROWNUM，改用基表主键或唯一约束列做序；若必须分页逻辑，移到应用层或物化视图外处理 - 避免子查询里嵌套非确定性函数：例如
(SELECT SYSDATE FROM DUAL)要整个删掉，不能只删SYSDATE - 如果业务强依赖实时时间戳，放弃快速刷新，改用
COMPLETE刷新，并配合调度（如每小时DBMS_MVIEW.REFRESH）
ON PREBUILT TABLE 不是绕过非确定性的后门
有人以为用 ON PREBUILT TABLE 就能跳过校验，其实它只绕开“结构匹配”检查，对非确定性函数无效。创建时仍会报 ORA-12003 或 ORA-12054。
-
ON PREBUILT TABLE的前提是：预建表字段类型、顺序、长度必须与视图 SELECT 列完全一致 - 即使成功创建，后续
FAST REFRESH仍会失败，因为 Oracle 在刷新时依然要解析原始视图定义 - 真正需要的是把非确定性逻辑从视图定义里剥离，而不是靠预建表掩耳盗铃
非确定性函数的问题不在语法层面，而在 Oracle 对“可推导变更”的底层假设上。只要定义里还留着 SYSDATE 或 ROWNUM，任何绕过手段都只是延迟报错——最终一定会在第一次刷新时暴露。最省事的做法，是打开 EXPLAIN_MVIEW，盯着 RECOMMENDATION 改，别猜。
