Oracle中配置带过滤条件的物化视图日志

先看一个结论：在配置物化视图日志时，必须显式包含 WHERE 条件中涉及的所有列，且不能用别名，也不能漏掉任何一个过滤字段。否则，fast 刷新会直接降级为 complete，甚至刷新失败。这可不是小事，数据一致性一旦出问题，后续排查会很头疼。

---

物化视图日志漏掉 WHERE 字段导致增量刷新失效

举个例子，假设物化视图里加了 WHERE pay_status = 1 这个过滤条件。如果日志里没有包含 pay_status 列，Oracle 就无法判断某条记录是否还在过滤范围内。这样一来，UPDATE 或 DELETE 操作就可能被跳过，最终导致数据不一致，这后果谁都不想遇到。

实际工作中，你会遇到这些问题：

• ORA-12057: materialized view is invalid and must be compiled —— 日志列缺失时的典型错误
• 执行 DBMS_MVIEW.REFRESH 时，明明指定了 FAST，结果却走了 COMPLETE 刷新
• 查看日志表 MLOG$_T_ORDER，发现缺了对应字段，用 SELECT * FROM user_mview_logs 可以确认

具体操作时，建议你先做一步：反推物化视图 SQL 中所有参与 WHERE、GROUP BY、SELECT 聚合的原始列。注意是原始列名，不是别名。比如：

• 如果用了 TRUNC(create_time)，日志里只需要写 create_time
• 如果用了 UPPER(name)，日志里必须包含 name，不能只写 UPPER(name)

WITH SEQUENCE 和 INCLUDING NEW VALUES 是单表聚合 MV 的硬性要求

只要物化视图里包含了 SUM、COUNT、GROUP BY 这类聚合操作，Oracle 就强制要求日志带上 SEQUENCE 和 INCLUDING NEW VALUES。这两个参数缺一不可，否则即使列都齐了，FAST 刷新也会拒绝执行。

正确的写法是这样的：

CREATE MATERIALIZED VIEW LOG ON t_order  WITH PRIMARY KEY, SEQUENCE(create_time, pay_amount, pay_status)  INCLUDING NEW VALUES;

这里有几点需要注意：

• SEQUENCE 不是可选项——它保证了 DML 操作的顺序，聚合类 MV 必须依赖它
• INCLUDING NEW VALUES 是必须的，EXCLUDING 是默认值，但会导致聚合 MV 无法 FAST 刷新
• 不能同时指定 PRIMARY KEY 和括号里再列主键列，比如 WITH PRIMARY KEY (id) 会直接报错

主键列会自动记录，别重复声明

如果表有主键，用 PRIMARY KEY 子句后，Oracle 会自动把主键列写进日志。如果你再在 SEQUENCE(...) 里重复写它们，语法上虽然不报错，但逻辑冗余，还可能干扰解析，多一事不如少一事。

以 t_order 表为例，主键是 order_id，下面两种写法效果一样，但后者更干净：

• 推荐写法：WITH PRIMARY KEY, SEQUENCE(create_time, pay_amount, pay_status)
• 冗余写法：WITH PRIMARY KEY, SEQUENCE(order_id, create_time, pay_amount, pay_status)

这里要特别提醒：ROWID 不能替代 PRIMARY KEY。聚合类 MV 明确要求使用主键方式，否则直接拒绝创建 FAST 刷新支持。

大小写和对象名要严格匹配基表定义

Oracle 默认对未加引号的标识符会转大写。如果你建表时用了小写字段名并加了双引号，比如 "create_time"，那日志语句里也必须用双引号，否则系统找不到这个列。

最稳妥的做法是：

• 先查基表真实列名：SELECT column_name FROM user_tab_columns WHERE table_name = 'T_ORDER'
• 直接复制粘贴列名，避免手敲时大小写出错
• 别在日志里用 AS 别名——日志只认物理列名，TRUNC(create_time) AS stat_date 对日志毫无意义

一个容易被忽略的细节：物化视图日志本身不校验字段是否存在，只有真正执行 REFRESH FAST 时才会暴露问题。所以，配置完一定要跑一次手动刷新来验证，不能只看 CREATE 成功就认为万事大吉了。