应检查DBA_MVIEW_LOGS.LAST_PURGE_DATE是否长期未更新，若停滞则快速刷新已失效，常见原因包括REFRESH 'F'调用时日志无未消费记录、基表DDL后未重建日志、日志表被TRUNCATE或权限丢失。
查 DBA_MVIEW_LOGS.LAST_PURGE_DATE 是否长期未更新
物化视图日志（mlog$_ 表）里的 last_purge_date 字段，记录的是 oracle 最后一次从日志中读取并应用变更的时间。如果这个值停滞不动（比如停留在几天前），哪怕基表持续有 dml，也说明快速刷新已失效——后续刷新大概率会退化为全量。
常见原因包括：
-
DBMS_MVIEW.REFRESH调用时传了'F'但日志里没未消费记录（SNAPTIME$$ = DATE '4000-01-01'） - 基表 DDL 变更后未重建日志（如删了主键、改了字段类型）
- 日志表被手动
TRUNCATE或权限丢失，导致 Oracle 不敢读
执行：
SELECT log_table, last_purge_date, rowids, primary_key FROM DBA_MVIEW_LOGS WHERE master = 'YOUR_BASE_TABLE';
确认基表是否发生过 DDL 导致 FAST 刷新不可用
基表只要执行过 ALTER TABLE ... DROP COLUMN、ADD CONSTRAINT、MODIFY 等操作，就可能让原有日志失效。Oracle 不会自动同步日志结构，也不会报错提醒，只是在下次 REFRESH 'F' 时静默跳过或直接失败。
判断方法：
- 查
DBA_MVIEW_LOGS的OBJECT_ID和基表DBA_OBJECTS.OBJECT_ID是否一致；不一致=日志已脱钩 - 运行
DBMS_MVIEW.EXPLAIN_MVIEW('YOUR_MV_NAME')，看输出中MSGTXT是否含"materialized view log is invalid"或"base table DDL changed" - 手动查日志表数据：
SELECT COUNT(*) FROM MLOG$_YOUR_BASE_TABLE WHERE SNAPTIME$$ = DATE '4000-01-01';—— 若为 0 且基表确有新 DML，基本可断定日志未捕获
用 EXPLAIN_MVIEW 看 REFRESH_FAST_PCT 和 REFRESH_FROM_LOG_AFTER_INSERT 是否 DISABLED
EXPLAIN_MVIEW 输出的 CAPABILITY_NAME 字段比错误码更早暴露问题。当它显示 REFRESH_FAST_PCT = DISABLED 或 REFRESH_FROM_LOG_AFTER_INSERT = DISABLED，基本意味着当前无法走增量路径，必须全量。
特别注意：
-
REFRESH_FAST_PCT = UNKNOWN：不是“不确定”，而是分区变更跟踪（EUT）未启用或权限不足，PCT 刷新不可用 -
REFRESH_FROM_LOG_AFTER_ANY = DISABLED：日志结构缺失关键列（如 GROUP BY 字段未包含在日志定义中） - 即使所有能力都标
POSSIBLE，若日志表空或LAST_PURGE_DATE过期，仍会退化为C
执行后查：
SELECT capability_name, possible, msgtxt FROM MV_CAPABILITIES_TABLE WHERE statement_id = 'QSMQT_EXPLAIN_MVIEW';
别信 LAST_REFRESH_DATE，盯紧 STALENESS 和刷新作业状态
LAST_REFRESH_DATE 在 DBA_MVIEWS 里只反映上一次成功完成时间，完全不体现“是否该刷”或“刷没刷成”。真正决定要不要全量的，是 STALENESS 值和底层作业是否真在跑。
关键组合：
-
STALENESS = 'STALE'+LAST_REFRESH_DATE是昨天 → 很可能卡在调度或失败后没重试 -
STALENESS = 'NEEDS_COMPILE'→ 基表 DDL 后忘了ALTER MATERIALIZED VIEW ... COMPILE，此时即使时间新，查询也会报错或返回空 -
STALENESS = 'UNUSABLE'→ 日志表损坏、DBLink 断开、或依赖对象（如远程表）不可达
顺手查下作业是否活着：
SELECT job_name, state, last_start_date FROM DBA_SCHEDULER_JOBS WHERE job_name LIKE '%YOUR_MV%';实际操作中，最常被忽略的是日志表与基表的
OBJECT_ID 对齐检查——它不报错，也不写日志，只让所有快速刷新请求悄悄绕过日志，直奔全量。
