物化视图不会自动感知分区删除，删分区后MV状态变为STALE，必须执行COMPLETE刷新；要支持FAST刷新需提前配置PCT、INCLUDING NEW VALUES日志及分区键对齐。
物化视图不会自动感知分区删除，必须手动干预
删掉 log_2022 分区后，mv_log_daily 里的数据不会消失，也不会触发任何刷新——哪怕你刚执行过 dbms_mview.refresh('mv_log_daily', 'f')。oracle 不把 drop partition 当作 dml 变更，物化视图日志（mlog$_lzms_log）里一条记录都不会多，所以 fast 刷新根本找不到“哪些行变了”，只能报 ora-12004: refresh fast cannot be used 或悄悄退化成 complete。
删分区后必须先 COMPLETE 刷新，不能硬上 FAST
分区 DDL（包括 DROP、TRUNCATE、EXCHANGE）会让所有依赖该表的物化视图状态强制变为 STALE，这是 Oracle 的元数据强一致性机制，不是异常。此时再调用 REFRESH FAST 必然失败或跳过变更。
- 查状态：
SELECT mview_name, staleness FROM user_mviews WHERE mview_name = 'MV_LOG_DAILY'—— 返回STALE就得处理 - 强制全量重建：
DBMS_MVIEW.REFRESH('MV_LOG_DAILY', 'C')是唯一可靠路径 - 别信
FORCE：它在 STALE 状态下仍会尝试 FAST，大概率失败后才 fallback，不如直接指定'C' - 如果物化视图很大，考虑加
ATOMIC_REFRESH => FALSE避免长事务锁表
想保留 FAST 刷新能力？得提前配好 PCT 和日志
真正能避免删分区后“必须全量刷”的方案，不是事后补救，而是建模时就对齐物理结构。关键不在物化视图本身，而在基表日志和定义是否支持分区变更跟踪（PCT）。
- 基表建日志时必须带
INCLUDING NEW VALUES PCT，且分区类型要是 RANGE/LIST（HASH 不支持） - 物化视图定义中聚合字段要与分区键严格对齐，比如按
log_time分区，就别写GROUP BY TO_CHAR(log_time, 'YYYY-MM')，改用TRUNC(log_time, 'MM') - 删分区前，先用
DBMS_MVIEW.PARTITION_CHANGING通知 Oracle “这个分区要动”，否则 PCT 无法标记范围 - 即使配齐了，
DROP PARTITION后仍需一次REFRESH FAST+PCT参数，而非默认模式
日常维护中容易忽略的权限与元数据断点
删完分区、刷完物化视图，结果查询还是慢或数据不对？八成是元数据链断了，而不是逻辑错了。
-
DROP PARTITION后，检查user_tab_partitions是否还显示旧分区名——若残留，说明 DDL 没真正生效（可能被锁或回滚段问题） - 确认物化视图用户对基表仍有
SELECT权限；分区删除有时会重置对象级权限，尤其跨 schema 时 - 如果用了
ON PREBUILT TABLE方式创建 MV，删分区后要检查底层表的ROWID是否失效（如发生过SHRINK或MOVE），否则 FAST 刷新会因 ROWID 不匹配而失败 - 查询重写可能还在用旧执行计划：删分区后跑一次
EXEC DBMS_STATS.GATHER_TABLE_STATS更新统计信息，否则优化器可能继续走已失效的物化视图
分区删除不是“删数据”那么简单，它是一次物理结构变更，物化视图的响应必须由人来闭环——没有自动、没有捷径、也没有隐式兜底。
