基表分区后物化视图无法刷新，主因是快速刷新条件被破坏导致降级或卡顿；需检查日志同步、MVIEW是否失效及刷新任务阻塞，并确认日志含SEQUENCE和INCLUDING NEW VALUES。
基表分区后物化视图无法刷新，通常不是“不支持”，而是快速刷新条件被破坏，系统自动降级失败或卡在 refresh 等待状态。关键要检查日志是否同步、分区操作是否触发了 mview 失效、以及刷新任务是否被阻塞。
为什么分区操作会让物化视图“失联”
Oracle 的快速刷新依赖物化视图日志（MLOG$_table_name）记录 DML 变更。当对基表执行 ALTER TABLE ... ADD PARTITION、SPLIT PARTITION 或 EXCHANGE PARTITION 时：
- 若未启用
INCLUDING NEW VALUES，分区交换或批量插入可能绕过日志捕获，导致增量数据丢失； - 部分分区 DDL（如
TRUNCATE PARTITION）会隐式提交，但不会写入物化视图日志，FAST刷新判定直接失败； - 基表结构变更（如新增虚拟列、修改分区键表达式）可能导致物化视图元数据失效，
DBA_MVIEWS.STALENESS显示UNUSABLE或NEEDS_COMPILE。
如何确认当前刷新状态是否已损坏
别急着手动刷新，先查清楚“卡在哪”：
- 运行
SELECT MVIEW_NAME, STALENESS, STALENESS_REASON FROM DBA_MVIEWS WHERE MVIEW_NAME = 'YOUR_MV_NAME';—— 若STALENESS是UNUSABLE，说明编译失败，需ALTER MATERIALIZED VIEW ... COMPILE； - 查日志表是否存在：
SELECT * FROM DBA_MVIEW_LOGS WHERE MASTER = 'BASE_TABLE_NAME';，确认日志仍有效且含SEQUENCE和ROWID； - 看刷新任务是否挂起：
SELECT JOB_NAME, STATE, LAST_START_DATE, NEXT_RUN_DATE FROM DBA_SCHEDULER_JOBS WHERE JOB_NAME LIKE '%MV%';，若STATE是RUNNING但长时间无进展，大概率被锁阻塞。
修复步骤：从日志重建到强制回退
按顺序执行，避免跳步：
- 如果
STALENESS是NEEDS_COMPILE，先执行ALTER MATERIALIZED VIEW your_mv_name COMPILE;； - 若日志缺失或字段不全（比如没
SEQUENCE），重建日志：CREATE MATERIALIZED VIEW LOG ON base_table WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES;； - 确认基表分区键列在 SELECT 列表中（尤其连接视图），否则
FAST不可用； - 手动触发一次
FORCE刷新：EXEC DBMS_MVIEW.REFRESH('YOUR_MV_NAME', 'F');，观察是否回落为COMPLETE； - 若仍失败，用
COMPLETE强制重建：EXEC DBMS_MVIEW.REFRESH('YOUR_MV_NAME', 'C', ATOMIC_REFRESH => FALSE);——ATOMIC_REFRESH => FALSE关键，避免大表 truncate 时长事务锁表。
后续预防：分区场景下的刷新稳定性要点
分区不是物化视图的敌人，但需要主动适配：
- 所有涉及分区操作的基表，物化视图日志必须带
SEQUENCE和INCLUDING NEW VALUES，否则EXCHANGE类操作无法被捕获； - 避免在高峰期执行
SPLIT或MERGE，这类 DDL 可能触发 MV 元数据重校验，期间FAST刷新临时禁用； - 使用刷新组（
DBMS_REFRESH）时，务必设ATOMIC_REFRESH => FALSE，否则单个 MV 刷新失败会导致整组回滚，掩盖真实问题； - 定期检查
DBA_MVIEW_ANALYSIS中的LAST_REFRESH_DATE和REFRESH_METHOD，发现从FAST持续变为COMPLETE就是预警信号。
最常被忽略的是日志的 INCLUDING NEW VALUES 选项——它不是可选配置，而是分区环境下增量捕获的硬性前提。没有它，哪怕加了 SEQUENCE，EXCHANGE PARTITION 后的数据也不会进日志，FAST 刷新必然失败，且错误不报在前台，只静默降级或卡住。
