Oracle中分区DDL操作会使物化视图强制变为STALE，因物理结构变更导致数据不一致；必须显式执行COMPLETE刷新，日志无法捕获分区变更，查询重写可能返回错误结果。
分区 DDL 操作会直接使物化视图变为 STALE
在 oracle 中，对分区表执行 alter table ... add partition、drop partition、split partition 或 exchange partition 等 ddl 操作后，所有依赖该表的物化视图（无论刷新模式）状态都会被置为 stale。这不是 bug，而是 oracle 的强制行为：ddl 改变了基表的物理结构或元数据，优化器无法保证物化视图中预存的数据仍与当前分区布局一致。
常见错误现象：SELECT * FROM user_mviews WHERE mview_name = 'MV_TEST'; 返回 STALENESS = 'STALE'，但查询仍能执行（尤其当 query_rewrite_integrity 设为 STALE_TOLERATED 时），结果可能漏掉新分区数据或包含已删除分区的残留记录。
- 即使物化视图是
ON COMMIT刷新，DDL 后也不会自动触发刷新——必须显式调用DBMS_MVIEW.REFRESH -
EXCHANGE PARTITION尤其危险：若交换的是空分区或历史归档分区，物化视图里可能还保留着旧数据块的逻辑映射，但实际数据已不在原表中 - 分区维护后未刷新物化视图，会导致查询重写失效（
EXPLAIN PLAN显示走基表而非物化视图）
物化视图日志无法捕获分区级 DML 变更
物化视图日志（MATERIALIZED VIEW LOG）只记录行级 DML（INSERT/UPDATE/DELETE），对分区操作完全无感知。例如：ALTER TABLE sales DROP PARTITION p_2025_q1 删除了 200 万行，但日志里一条记录都不会增加。
这意味着：如果你依赖日志做快速刷新（FAST REFRESH），分区 DDL 后再执行 REFRESH FAST，Oracle 会报错 ORA-12004: REFRESH FAST cannot be used for materialized view，因为它发现日志和基表结构已不匹配。
- 必须改用
REFRESH COMPLETE（全量重建），否则刷新失败 - 如果物化视图定义中用了
ROWID，而分区 DDL 导致部分ROWID失效（如MOVE或SHRINK），FAST REFRESH也会失败 - 模板化分区表（
INTERVAL或LIST子分区）新增分区后，物化视图日志不会自动扩展覆盖新分区，需人工确认日志是否含INCLUDING NEW VALUES
查询重写在分区变更后可能返回不一致结果
Oracle 查询重写机制依赖物化视图定义与当前基表结构的语义一致性。当分区结构变化（比如新增一个按时间范围划分的子分区），但物化视图未刷新，优化器仍可能基于旧的分区统计信息和元数据选择该物化视图——哪怕它根本不包含新分区的数据。
典型场景：MV_SALES_SUM 基于 sales 表按月聚合，某天 DBA 手动加了 P_202604 分区并导入当月数据，但忘记刷新物化视图。此时用户查 SELECT SUM(amount) FROM sales WHERE sale_date >= DATE'2026-04-01'，可能命中物化视图却返回 0（因 MV 里没这个分区数据），而实际基表已有 50 万条记录。
- 关键参数
query_rewrite_integrity决定容忍程度：ENFORCED（默认）下，STALE物化视图根本不会被选中；TRUSTED下则完全跳过校验，风险极高 - 可通过
SELECT * FROM v$mvrefresh查看最近刷新是否成功，注意ERROR_NUMBER字段 - 分区维护脚本中必须串联
DBMS_MVIEW.REFRESH调用，不能仅靠调度任务——因为人工 DDL 往往是突发的
跨租户/多源环境下的二级分区兼容性陷阱
在 OceanBase Oracle 租户等兼容场景中，分区维护的一致性风险被放大。已知 bug 显示：向模版化二级分区表添加新二级分区后，系统视图（如 ALL_TAB_SUBPARTITIONS）查询结果不包含该分区，导致 DBMS_MVIEW.REFRESH 内部依赖这些视图做元数据比对时出错，刷新可能静默跳过新分区数据。
这不是 Oracle 原生问题，但在 OMS 迁移、混合云架构中极易踩坑。验证方式简单：SELECT COUNT(*) FROM all_tab_subpartitions WHERE table_name = 'SALES'; 与 SELECT COUNT(*) FROM dba_segments WHERE segment_name = 'SALES' AND segment_type = 'TABLE SUBPARTITION'; 结果不一致，就说明元数据已脱节。
- 临时规避：刷新前手动执行
EXEC DBMS_STATS.GATHER_TABLE_STATS强制更新统计信息 - 长期方案：避免在 OceanBase Oracle 租户中对模版化二级分区表做高频 DDL，优先用一级分区+应用层路由
- 任何分区维护后，必须用真实业务 SQL 对比物化视图与基表的聚合结果（不止 count，还要比 sum/max/min）
分区维护本身不复杂，但物化视图对它的响应是隐式的、延迟的、且缺乏明确报错——最危险的状态不是“刷新失败”，而是“看起来刷新成功，实则数据已偏移”。
