DROP PARTITION导致物化视图刷新失败，根本原因是物化视图日志元数据断裂、STALENESS变为UNUSABLE，使Oracle拒绝执行任何刷新操作。
基表 DROP PARTITION 后物化视图刷新失败，不是因为数据丢了，而是物化视图日志（MLOG$_xxx）元数据断裂、STALENESS 变为 UNUSABLE，导致 Oracle 拒绝执行任何刷新——哪怕你手动调 DBMS_MVIEW.REFRESH 也无效。
为什么 DROP PARTITION 会让物化视图“失能”？
DROP PARTITION 是 DDL 操作，会隐式提交，并重置基表的数据字典快照。物化视图日志依赖基表的结构稳定性，尤其是分区键表达式、主键约束、以及 ROWID 的连续性。一旦分区被删：
- 基表的分区键列（如
TRUNC(sales_date, 'MM')）可能因分区边界变更而无法再被日志准确映射 - 如果原日志建在分区表上且未显式包含分区键表达式（只写了列名），Oracle 就无法判断哪些变更行属于哪个逻辑分区
-
DBA_MVIEW_LOGS中的PRIMARY_KEY或ROWIDS字段可能被清空或设为N，查SELECT ROWIDS, PRIMARY_KEY FROM DBA_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'会返回全N - 更隐蔽的是：即使日志表物理存在，
STATUS在DBA_OBJECTS中可能已变成INVALID
如何确认是否真因 DROP PARTITION 导致失效？
别猜，直接查三处关键状态：
- 查物化视图当前状态：
SELECT MVIEW_NAME, STALENESS, STALENESS_REASON FROM DBA_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV_NAME'—— 若STALENESS = 'UNUSABLE'，说明已不可用，必须先COMPILE - 查日志是否还活：
SELECT STATUS FROM DBA_OBJECTS WHERE OBJECT_NAME = 'MLOG$_YOUR_TABLE'——INVALID就得重建 - 查日志配置是否完整：
SELECT ROWIDS, PRIMARY_KEY, SEQUENCE FROM DBA_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'—— 至少两个是Y才支持 FAST；若全是N，日志已形同虚设
重建日志前必须做的三件事
跳过这步直接 CREATE MATERIALIZED VIEW LOG，大概率白干：
- 先
ALTER MATERIALIZED VIEW your_mv_name COMPILE—— 这是解锁刷新的前提，否则所有REFRESH调用都会被忽略 - 确认基表仍有有效主键或唯一约束（
DROP PARTITION有时会连带删掉局部索引，间接让主键失效） - 检查是否还有其他物化视图共享这张日志：
SELECT * FROM DBA_REGISTERED_SNAPSHOTS WHERE LOG_OWNER = 'YOUR_SCHEMA' AND LOG_NAME = 'MLOG$_YOUR_TABLE'—— 若有，得协调一起重建，否则刷新会互相干扰
重建日志的最小安全语句
不要复用旧语句。针对 DROP PARTITION 后场景，推荐这个组合（假设基表有主键）：
CREATE MATERIALIZED VIEW LOG ON your_table WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES;
注意两点：
- 必须显式写
ROWID—— 因为DROP PARTITION后物理结构已变，仅靠主键不足以覆盖所有更新路径 - 不能省略
INCLUDING NEW VALUES—— 否则UPDATE和DELETE操作不会被日志捕获，FAST 刷新必然退化为 COMPLETE
重建后立刻做三件事：收集统计信息、重建 snaptime$$ 和 sequence$$ 索引、验证 MLOG$_xxx 中是否有新记录写入。最易被忽略的是索引缺失——没有它，日志扫描会默认走全表，FAST 刷新性能比 COMPLETE 还差。
