物化视图刷新失败主因是外键依赖的父表未显式包含在MV查询中，导致ORA-12008套ORA-2291；必须JOIN父表并SELECT其主键列，或改用ON DEMAND刷新并控制顺序。
因为外键本身不自动带入物化视图，Oracle 刷新时会严格校验 MV 内部可见的父表数据是否完整——而你很可能根本没把父表加进去。
ORA-12008 / ORA-02291 刷新失败的根本原因
错误日志里反复出现 ORA-12008 套着 ORA-02291，不是数据真丢了，而是物化视图定义里只写了子表（比如 sales_detail），却依赖它外键指向的 product 表做约束检查。Oracle 在 REFRESH FAST ON COMMIT 时，会扫描 MV 当前持有的所有行，逐个验证外键值是否能在 MV 自己“看到”的父表数据中找到——但如果你没把 product 表 SELECT 进来，那它就啥也找不到。
- 典型场景：子表按月分区，MV 定义用了
WHERE sale_date >= ADD_MONTHS(SYSDATE, -3)，只拉最近 3 个月；但外键列prod_id指向的 product 数据全都不在 MV 里 - 即使数据库层面有真实外键约束，Oracle 物化视图刷新器完全不认这个，只认 MV 查询语句里实际包含的表和列
- 分区裁剪（partition pruning）在查询时生效，但在刷新路径里，约束检查是面向 MV 全量结果集的，不跳过任何行
必须显式把父表或关键列写进 MV 定义
不能靠“有外键就自动关联”这种直觉。要么整表引入，要么至少把外键引用的主键/唯一键列 SELECT 进来，并确保类型、长度、NULL 性完全一致。
- 安全做法：在 MV 查询中显式
JOIN product p ON s.prod_id = p.prod_id，且SELECT列表包含p.prod_id（哪怕只是为校验用） - 若父表太大（比如亿级 product），可改用
REFRESH FAST ON DEMAND，再手动控制刷新顺序：DBMS_MVIEW.REFRESH('MV_PRODUCT')先跑，再刷子表 MV - 禁止在子表 MV 中用
WHERE过滤分区的同时，又依赖未纳入的父表做外键检查——这是最常踩的组合型坑
ON PREBUILT TABLE 场景下外键更危险
预构建物化视图复用已有表，但类型校验比普通 MV 更苛刻。如果原表字段类型和 MV 查询中表达式不一致（比如原表是 NUMBER(10)，查询里写 CAST(col AS NUMBER)），Oracle 会直接拒绝创建，后续刷新也无从谈起。
- 验证方法：用
DESC existing_table和SELECT column_name, data_type, data_precision FROM user_tab_columns对照 MV 查询里的每个字段表达式 - 外键列参与 JOIN 或过滤时，必须出现在物化视图日志中（
CREATE MATERIALIZED VIEW LOG ON parent_table INCLUDING NEW VALUES），否则刷新报ORA-12032 - 如果原表没主键，又在 MV 定义里写了
WITH PRIMARY KEY，会报ORA-12014——删掉该子句，或给原表补主键
真正容易被忽略的是：外键约束在 MV 刷新路径里，从来不是“数据库已存在所以自动生效”的基础设施，而是每次刷新都重新执行的一次独立校验动作。只要 MV 结果集里某一行的外键值，在它自己能访问到的数据范围内找不到对应主键，就立刻失败——跟基表上有没有约束、有没有数据，完全无关。
