物化视图不参与分区删除，仅提供快照式缓存，归档需外部控制；刷新不感知分区变化，旧数据残留属正常；归档前须人工/脚本确认分区边界，可用user_tab_partitions查询；适合用于归档校验。
物化视图不直接参与分区删除，但能辅助归档判断
物化视图本身不能触发或替代 drop partition 操作，它也不感知底层表的分区结构变化。它的作用是「快照式缓存」，归档逻辑必须由外部控制。如果你指望物化视图自动随分区删除而同步清理归档数据，那会落空。
常见错误现象是：先删了 log_2022 分区，再刷新物化视图，结果发现旧数据还在 —— 因为物化视图刷新只依赖其定义的查询（比如 SELECT * FROM lzms_log WHERE log_time >= DATE '2023-01-01'），并不检查源表还剩哪些分区。
- 归档前必须人工/脚本确认源表分区边界，例如用
SELECT partition_name, high_value FROM user_tab_partitions WHERE table_name = 'LZMS_LOG' - 物化视图适合做「归档校验」：创建一个只查待归档分区范围的物化视图（如
WHERE log_time ），刷新后 count 为 0 才说明该范围数据已清空 - 不要在物化视图定义里硬写分区名（如
FROM lzms_log PARTITION(p_2022)），否则分区一删就报ORA-00942: table or view does not exist
DROP PARTITION 和 TRUNCATE PARTITION 的归档适用场景
归档本质是「把旧数据移出在线系统」，不是单纯删掉。直接 DROP PARTITION 是最省事，但不可逆；TRUNCATE PARTITION 则保留分区结构，方便后续重载或补录。
- 用
DROP PARTITION：适用于严格按时间滚动、绝无回溯需求的日志类表（如lzms_log），删完立刻释放空间，且无需重建索引（如果加了UPDATE GLOBAL INDEXES） - 用
TRUNCATE PARTITION：适用于需保留分区壳子的场景，比如下游 ETL 任务依赖固定分区名取数，或要留空分区等未来数据归档回填 - 注意：两者都会使全局索引失效，除非显式加上
UPDATE GLOBAL INDEXES；局部索引不受影响 - 执行前务必确认该分区无活跃事务，否则会卡住 DDL，报
ORA-00054: resource busy
分区删除后物化视图刷新失败的典型原因
删分区后物化视图刷新报错，八成不是物化视图的问题，而是源表元数据或权限链断了。
-
ORA-12008: error in materialized view refresh path+ORA-00942：说明物化视图查询里引用了已被删的分区名，或用了PARTITION限定语法 -
ORA-12015: cannot create a fast refresh materialized view from a complex query：删分区后导致原查询变成非简单查询（比如删掉的是唯一键所在分区，破坏了可快速刷新条件） - 刷新时卡住不动：可能因分区删除未提交，或物化视图日志（
ON COMMIT模式）还在等已不存在的分区变更记录 - 解决办法优先级：1）检查物化视图定义是否含硬编码分区；2）运行
DBMS_MVIEW.EXPLAIN_MVIEW看刷新能力；3）必要时重建物化视图（CREATE MATERIALIZED VIEW ... BUILD DEFERRED）
自动化归档脚本必须绕开的坑
写定时任务自动删分区+刷物化视图，最容易栽在「顺序」和「边界」上。
- 必须先删分区，再刷新物化视图；反过来会导致物化视图尝试读已不存在的数据块，报 I/O 错误
- 分区名不能靠字符串拼接推算（如
'P_'||TO_CHAR(ADD_MONTHS(SYSDATE,-24),'YYYYMM')），因为实际分区名可能不规则（比如log_future或带下划线日期格式） - 用
high_value解析真实边界：例如SELECT partition_name FROM user_tab_partitions WHERE table_name='LZMS_LOG' AND TO_DATE(REGEXP_SUBSTR(high_value, '''([^']+)'''), 'YYYY-MM-DD') - 生产环境别用
ON COMMIT刷新物化视图：分区 DDL 会阻塞事务提交，导致应用超时
真正难的不是语法，是确认「这个分区确实没被任何业务逻辑依赖」——比如某个报表 SQL 写死了 PARTITION(p_2021)，删了它，报表就崩，而这种依赖根本不会出现在数据字典里。
