物化视图含聚合却 REFRESH_FAST_POSSIBLE = 'N'，根本原因是Oracle在解析阶段校验失败，最常见为MSGNO=2025，要求显式且无别名的COUNT(*)、日志覆盖GROUP BY列和聚合输入列、非NULL约束及避免函数表达式。
物化视图含聚合却 REFRESH_FAST_POSSIBLE = 'N'，先查 MSGNO 2025
oracle 不是“不支持聚合的快速刷新”，而是对聚合物化视图做了硬性校验：只要 refresh_fast_possible 是 'n'，就说明它在创建或刷新前已拒绝该路径。最常见触发点是 msgno = 2025，对应提示类似 “complex query with aggregates, but missing count(*) or invalid group by”。这比报 ora-12052 更早、更准——它发生在解析阶段，不是执行时才失败。
必须立刻运行：EXEC DBMS_MVIEW.EXPLAIN_MVIEW('YOUR_MV_NAME');
然后查 mv_capabilities_table 中 CAPABILITY_NAME = 'REFRESH_FAST' 那一行的 msgtxt 字段。别跳过这步，否则容易把问题归错到日志或权限上。
COUNT(*) 必须显式写，且不能带别名或改写
聚合物化视图能走快速刷新的底层逻辑，依赖 COUNT(*) 来区分“行数变化”和“值变化”。Oracle 只认字面量 COUNT(*)，其他写法一律无效：
-
COUNT(1)、COUNT(id)、COUNT(DISTINCT dept_id)→ 直接拒掉快速刷新 -
COUNT(*) AS cnt或SELECT COUNT(*) + 0 FROM ...→ 解析失败，MSGNO = 2003或静默降级 - 如果用了
AVG(salary)，Oracle 内部无法维护增量平均值，必须拆成SUM(salary)和COUNT(*)两列
正确写法只有一种：SELECT dept_id, COUNT(*), SUM(salary) FROM emp GROUP BY dept_id
物化视图日志必须覆盖所有 GROUP BY 列和聚合输入列
日志不是“建了就行”，它必须精确匹配物化视图 SELECT 中所有非聚合列（即 GROUP BY 列）和所有被聚合函数直接作用的列（如 SUM(salary) 的 salary）。漏一个，ORA-32320 就立刻报。
检查方式：
- 查日志是否启用
INCLUDING NEW VALUES：SELECT including_new_values FROM user_mview_logs WHERE master = 'EMP';返回'NO'就得重建 - 查日志是否含关键列：
SELECT column_name FROM user_mview_log_filter_cols WHERE log_table = 'MLOG$_EMP';—— 这里必须有DEPT_ID和SALARY - 查日志结构是否完整：
SELECT sequence, rowids FROM dba_mview_logs WHERE master = 'EMP';两项都得是'YES'
常见错误：建日志时只写了 WITH ROWID, SEQUENCE，没指定列名，结果只记录主键和 ROWID，漏掉 SALARY 这类非主键聚合列。
基表约束和数据质量会暗中破坏快速刷新
即使 SQL 和日志都对了，COUNT(*) 也写了，仍可能失败——因为 Oracle 对聚合快速刷新有隐性数据假设：
-
SUM()或AVG()用的列（如salary）若允许NULL，且日志没开INCLUDING NEW VALUES，那么NULL → 100的更新就不会被捕获，导致聚合值错乱 -
AVG()要求所有参与列NOT NULL；否则必须用COUNT(*)+SUM(NVL(salary, 0))，但语义已变，需业务确认 - 基表主键失效（
status != 'ENABLED'）或做过ALTER TABLE ... MOVE，会导致日志中ROWID失效，REFRESH_FAST静默退化为COMPLETE
最容易被忽略的是：物化视图定义里写了 NVL(salary, 0) 这类函数表达式。Oracle 认为它不确定（哪怕函数本身 deterministic），直接禁用快速刷新——这种限制不会明说，只在 EXPLAIN_MVIEW 的 msgtxt 里提一句 “expression not supported for fast refresh”。
