重命名分区后物化视图状态变为stale导致查询重写失效，需手动刷新并设置query_rewrite_integrity=stale_tolerated才能恢复；同时须确认物化视图日志包含分区键列，否则fast刷新可能退化为complete。
不需要完全重构，但必须手动刷新物化视图并验证重写是否仍生效——重命名分区本身不破坏物化视图结构，但会触发其状态变为 STALE，导致查询重写静默失效。
重命名分区后物化视图状态自动变 STALE
Oracle 在重命名分区（ALTER TABLE ... RENAME PARTITION）时，会将依赖该表的所有物化视图标记为 STALE。这不是 bug，而是机制设计：分区元数据变更被视为“基表结构潜在不一致”，优化器默认拒绝在 STALE 状态下启用查询重写。
- 查状态：
SELECT mview_name, staleness FROM user_mviews WHERE mview_name = 'MV_SALES_BY_MONTH';—— 结果通常为STALE - 即使物化视图内容物理上未变、定义也未改，
EXPLAIN PLAN里也看不到访问MV_*的路径 -
DBMS_MVIEW.EXPLAIN_REWRITE会返回QSM-01150: no suitable materialized view found，而非更具体的错误
REFRESH FAST 可能失败，需检查日志字段是否含分区键
如果物化视图使用 REFRESH FAST，重命名分区后首次刷新可能退化为 COMPLETE，且不报错——根本原因是物化视图日志（MLOG$_*）未显式记录分区键列，而重命名操作被 Oracle 视为“分区键值变更事件”之一。
- 验证日志是否合规：
SELECT master, log_table, rowids, primary_key, filter_columns FROM user_mview_logs WHERE master = 'SALES';，确认FILTER_COLUMNS包含分区键（如SALE_DATE） - 若缺失，重建日志：
CREATE MATERIALIZED VIEW LOG ON sales WITH ROWID, SEQUENCE(sale_date, cust_id) INCLUDING NEW VALUES; - 刷新前务必执行：
EXEC DBMS_MVIEW.REFRESH('MV_SALES_BY_MONTH', method => 'F');并检查user_mview_refresh_times中的last_refresh_date和refresh_method
查询重写需重新激活，不能靠自动恢复
重命名后即使刷新成功、状态变 FRESH，查询重写也不一定自动恢复——因为 QUERY_REWRITE_INTEGRITY 默认为 ENFORCED，它要求 MV 内容与基表“数学等价”，而分区重命名带来的元数据扰动会让 Oracle 暂时失去信任。
- 临时生效（会话级）：
ALTER SESSION SET query_rewrite_integrity = STALE_TOLERATED; - 若业务允许强一致性，改用
TRUSTED，但需 DBA 手动保证后续刷新及时性 - 必须配合
ENABLE QUERY REWRITE声明（创建时已设，无需重做）和QUERY_REWRITE_ENABLED=TRUE实例参数 - 验证重写是否真起效：
EXPLAIN PLAN FOR SELECT SUM(amount) FROM sales WHERE sale_date >= DATE '2026-09-01';，再查PLAN_TABLE看OBJECT_NAME是否为物化视图名，且PARTITION_START显示具体分区号（非KEY）
最易被忽略的一点：重命名分区后，所有依赖它的物化视图索引不会自动重建或重命名——如果 MV 上建了复合索引（如 INDEX idx_mv_dt_region ON mv_sales_by_month(sale_date, region)），该索引仍有效，但若原分区键列名在 MV 定义中被函数包裹（如 TRUNC(sale_date)），重命名操作会加剧谓词无法映射的问题，此时仅刷新和调参不够，必须调整 MV 定义本身。
