ora-12054 表示物化视图不支持快速刷新，主因是查询含 join、group by、分析函数等复杂逻辑，导致 oracle 无法安全推导增量变更；需用 explain_mview 查 recommendation 定位具体限制。
物化视图刷新失败：fast 不生效，回退成 complete
大表建物化视图时最常遇到的不是语法报错，而是 refresh fast 看似写对了，实际执行时却悄悄走 complete。根本原因在于：oracle 要做快速刷新，必须能精准识别“哪些行变了”，这依赖两个硬性前提：materialized view log 存在且包含足够信息、基表有主键或唯一约束（或显式声明 with rowid）。
常见踩坑点：
- 基表没主键，又没加
WITH ROWID，FAST直接被拒绝 - 物化视图日志没建在基表所在用户下，或没给物化视图用户
SELECT权限（尤其是MLOG$_xxx表） - 查询语句含
ROWNUM、SYSDATE、子查询聚合未带GROUP BY等，导致 Oracle 判定无法增量维护
验证是否真走 FAST：执行 DBMS_MVIEW.EXPLAIN_MVIEW，查 mv_capabilities_table 中 REFRESH_FAST_AFTER_INSERT 等字段是否为 Y，别只看 DDL 里写了什么。
分区表上建物化视图：为什么不能直接用 PARTITION BY？
Oracle 物化视图本身不支持 PARTITION BY 子句——你不能像建普通表那样给物化视图指定分区键。但分区优化仍可落地，关键是让物化视图「继承」基表的分区结构并利用它加速刷新和查询。
实操要点：
- 基表必须是分区表（如按
ORDER_DATERANGE 分区），且物化视图查询中要显式引用分区键字段（例如SELECT ... FROM orders WHERE order_date >= TRUNC(SYSDATE-30)） - 创建物化视图日志时加
INCLUDING NEW VALUES，并确保日志也按相同列分区（需在CREATE MATERIALIZED VIEW LOG后手动ALTER TABLE MLOG$_ORDERS MODIFY PARTITION ...，否则日志变单一大表，FAST 刷新性能崩塌） - 刷新时用
DBMS_MVIEW.REFRESH的PARALLELISM参数（如PARALLELISM => 4），Oracle 会自动按分区并行处理变更 delta
注意：如果物化视图定义里用了 UNION ALL 拼多个分区表，或跨不同分区策略的表联查，FAST 刷新基本失效，得切回 FORCE + 定期 NEXT 调度。
大数据量下 REFRESH ON COMMIT 为什么必须禁用
基表每提交一次就触发物化视图同步，在小表上是便利，在千万级订单表上等于给每次 INSERT/UPDATE 加了一次全链路锁等待。尤其当物化视图含聚合或多表关联时，ON COMMIT 会强制事务串行化，TPS 断崖下跌。
替代方案更可控：
- 用
ON DEMAND+ 定时 JOB，例如每 5 分钟跑一次DBMS_MVIEW.REFRESH('MV_ORDERS_DAILY', 'F') - 结合
DBMS_MVIEW.REFRESH_DEPENDENT，监听基表变更后批量触发下游所有相关 MV，避免逐个刷新的开销 - 若需近实时，改用
DBMS_APPLY_ADM配合 GoldenGate，而非硬扛ON COMMIT
一个典型信号：v$session_event 中出现大量 enq: MV - fast refresh 等待事件，说明 ON COMMIT 已成为瓶颈。
物化视图占用空间暴增：如何限制历史数据保留
物化视图本身是物理表，但它的日志表（MLOG$_xxx）才是真正的空间黑洞——尤其开启 FAST 后，所有 DML 变更都先落日志，等刷新才清理。默认不清除，几天就能涨到基表几倍大小。
必须主动干预：
- 建日志时加
WITH SEQUENCE和INCLUDING NEW VALUES，便于后续按 SCN 或时间截断 - 定期清理：用
DELETE FROM MLOG$_ORDERS WHERE SNAPTIME$$ （注意先停刷新 JOB，再删，否则可能丢数据） - 把日志表移到独立表空间，并设置
MAXSIZE防止撑爆磁盘
真正容易被忽略的是：物化视图启用 QUERY REWRITE 后，Oracle 会在内部维护额外的重写映射元数据，这部分不占用户段空间，但会增加 shared pool 压力，大并发下可能引发 library cache lock ——上线前务必在 AWR 报告里盯紧 sql area 和 row cache objects 等待事件。
