Oracle 19c物化视图本身不支持分区，所谓“历史分区”实指其底层存储表被手动分区或基于已分区基表构建；需通过ON PREBUILT TABLE挂载并验证底表分区属性，删除前须停刷新、查依赖、执行完整刷新，再按顺序删分区、更新全局索引、重收集统计信息，否则易触发ORA-12003等错误。
Oracle 19c 中物化视图本身不支持分区（MATERIALIZED VIEW 是逻辑对象，不能直接分区），所谓“历史分区”实际指其底层存储表（即物化视图对应的段）被手动分区，或更常见的是：物化视图基于**已分区的基表**构建，且刷新后继承了分区结构（如通过 ON PREBUILT TABLE 挂载到一个预先创建的分区表上）。
确认物化视图是否真挂载在分区表上
别凭印象判断。物化视图定义里没写 PARTITION BY，不代表它没用分区表——它可能用了 ON PREBUILT TABLE 方式绑定到一个已分区的普通表。
- 查物化视图是否基于预建表：
SELECT on_prebuilt_table FROM user_mviews WHERE mview_name = 'MV_NAME'，返回YES就必须继续查底表 - 查底表是否分区：
SELECT partitioned FROM user_tables WHERE table_name = (SELECT container_name FROM user_mviews WHERE mview_name = 'MV_NAME') - 若底表是分区表，再查分区策略：
SELECT partitioning_type, subpartitioning_type FROM user_part_tables WHERE table_name = 'CONTAINER_TABLE_NAME'
删除历史分区前必须停掉刷新并验证依赖
直接 ALTER TABLE ... DROP PARTITION 会失败或引发刷新异常，因为物化视图刷新过程可能正读写该分区，或日志捕获逻辑仍引用旧分区元数据。
- 先禁用自动刷新（如果是
ON DEMAND，确保没有调度作业正在运行；如果是ON COMMIT，临时改用ON DEMAND） - 执行
DBMS_MVIEW.REFRESH('MV_NAME', 'C')完成一次完整刷新，确保所有变更已落地，避免删分区时丢失增量 - 检查是否有其他物化视图依赖当前物化视图（嵌套 MV）：
SELECT * FROM user_dependencies WHERE referenced_name = 'MV_NAME' AND type = 'MATERIALIZED VIEW'，有结果就得先处理依赖链
安全删分区的三步操作顺序
顺序错了就可能触发 ORA-12003（无法定位日志）、ORA-14048（分区维护与 DDL 不兼容）或后续刷新卡死。
- 第一步：删对应分区的物化视图日志条目（如果该分区曾单独建过日志）——但通常日志建在基表上，不是分区上；重点是确认
DBA_MVIEW_LOGS中MASTER列指向的是基表名，而非分区名 - 第二步：执行分区删除，推荐带
UPDATE GLOBAL INDEXes（如果物化视图上有全局索引）：ALTER TABLE container_table_name DROP PARTITION p_old UPDATE GLOBAL INDEXES - 第三步：立即重建物化视图统计信息：
DBMS_STATS.GATHER_TABLE_STATS(user, 'CONTAINER_TABLE_NAME')，否则优化器可能因分区元数据缺失而选错执行计划，导致下一次FAST REFRESH退化为COMPLETE
删完分区后最容易被忽略的点
删分区不是终点，而是维护链条中一环。最常出问题的是物化视图日志里的 sequence$$ 和 snaptime$$ 索引失效，以及基表新增列未同步进日志。
-
MLOG$_xxx表本身不会因删分区而损坏，但它依赖的基表分区元数据若变化（比如删了某分区后基表HIGH_VALUE调整），可能导致日志插入失败，报ORA-00604或ORA-12083 - 删完立刻查：
SELECT COUNT(*) FROM MLOG$_BASE_TABLE WHERE snaptime$$ < SYSDATE - 30，如果大量旧记录堆积，说明日志清理机制被阻塞，需手动DELETE并提交 - 如果基表后来新增了列，且该列被物化视图 SQL 引用（哪怕只在
WHERE中），必须手动向日志加列：ALTER MATERIALIZED VIEW LOG ON base_table ADD (new_col)，否则下次 FAST 刷新静默失败
