DROP PARTITION导致FAST刷新必然失败，因分区DDL绕过物化视图日志机制，日志无记录导致差异捕获链断裂；需查DBA_MVIEW_LOGS确认日志有效性，开10046 trace定位ORA-12008真实根因，并执行COMPILE修复编译态。
基表执行 DROP PARTITION 后，物化视图刷新失败（尤其是 REFRESH FAST）不是偶然现象，而是 Oracle 的确定性行为：分区级 DDL 绕过物化视图日志机制，导致差异捕获链断裂，FAST 刷新必然失败。
为什么 DROP PARTITION 会让 FAST 刷新直接失效
物化视图日志（MLOG$_xxx）只记录 DML（INSERT/UPDATE/DELETE），不记录 DDL。哪怕日志建时加了 INCLUDING NEW VALUES，DROP PARTITION 也不会往日志里写任何行 —— 因为它不走 DML 路径。结果就是：REFRESH FAST 执行时扫描日志发现“没变化”，但实际基表数据已永久丢失一部分，Oracle 拒绝在这种不一致前提下做增量更新。
- 查日志是否真有效：运行
SELECT ROWIDS, PRIMARY_KEY, SEQUENCE FROM DBA_MVIEW_LOGS WHERE MASTER = 'BASE_TABLE_NAME'，三者至少两个为Y才支持 FAST - 查日志表本身状态：
SELECT status FROM dba_objects WHERE object_name = 'MLOG$_BASE_TABLE_NAME'，若返回INVALID，必须重建日志 -
DROP PARTITION后立刻执行SELECT COUNT(*) FROM MLOG$_base_table，如果值没变（尤其基表刚有 DML 却仍为 0），说明日志捕获已失效
执行 REFRESH 时只报 ORA-12008 怎么定位真因
ORA-12008 是占位符错误，不是根因。它背后一定是某条隐式 SQL（如 MERGE INTO mv_name）执行失败，但 Oracle 截断了错误栈。不看 trace，永远不知道卡在哪。
- 必须在刷新前开启 10046 trace：
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12' - 立即执行刷新：
EXEC DBMS_MVIEW.REFRESH('MV_NAME', 'F') - 失败后去
USER_DUMP_DEST找最新 trace 文件，用grep "ORA-" your_trace.trc搜索，重点看紧挨着刷新语句之后的第一个ORA-错误 - 高频真实错误包括：
ORA-01652（临时表空间不足）、ORA-00001（MV 表唯一约束冲突）、ORA-02291（外键父键缺失）
编译失败（PLS-00302）或 STALENESS 仍为 UNUSABLE 怎么办
执行 ALTER MATERIALIZED VIEW mv_name COMPILE 是必要前置动作。只有编译成功，FAST 刷新才可能启用；否则一律回落 COMPLETE，且可能卡在日志扫描阶段。
- 如果
COMPILE报PLS-00302: component 'XXX' must be declared，说明基表结构已不兼容原 MV 定义 —— 比如被删分区里的列在 MV SELECT 列表中引用了，但该列物理上已不存在 - 编译成功后，查
DBA_MVIEWS.STALENESS：若仍是UNUSABLE，大概率是物化视图日志损坏或未重建；若变为STALE，说明编译态恢复，可尝试REFRESH FAST，但大概率仍失败（因日志无记录） - 此时最稳妥路径是：先
REFRESH COMPLETE拉齐数据，再评估是否重建日志 + 重定义 MV，尤其当基表频繁分区维护时
真正棘手的不是报错本身，而是错误发生后状态残留 —— MLOG$_xxx 表可能还挂着旧结构，STALENESS 状态可能长期卡在 UNUSABLE，而 DBA 以为只是“刷新慢”。一旦忽略日志有效性验证和 trace 开启习惯，问题就会从单次失败演变成定时故障。
