物化视图状态非fresh则数据过期或不可用；查user_mviews中staleness字段：fresh表示最新，stale为旧数据，needs_compile需编译，unusable已损坏。
物化视图状态不是 fresh，就别急着查数据——它大概率没刷新成功，或者压根不能用。
怎么快速确认物化视图当前状态
直接查 user_mviews 或 dba_mviews，重点关注 STALENESS 和 STALENESS 字段（注意：Oracle 12c+ 后该列名统一为 STALENESS，旧版本可能叫 STALENESS 或依赖 LAST_REFRESH_DATE + STALENESS 组合判断）：
SELECT MVIEW_NAME, STALENESS, LAST_REFRESH_DATE, REFRESH_METHOD, FAST_REFRESHABLE FROM user_mviews WHERE MVIEW_NAME = 'MV_MY_PARTITIONED_TABLE';
-
STALENESS = 'FRESH'：内容最新，可放心查询 -
STALENESS = 'STALE'：主表已变更但未刷新，查出来是旧数据 -
STALENESS = 'NEEDS_COMPILE'：主表结构改过（比如加字段、重建视图），必须先执行ALTER MATERIALIZED VIEW MV_NAME COMPILE -
STALENESS = 'UNUSABLE'：物化视图已损坏，常见于分区交换、DROP/RENAME主表后未同步处理
分区表物化视图为什么常卡在 STALE 或报错
分区表本身不阻止物化视图创建，但会放大日志和刷新逻辑的脆弱性。关键问题往往不在物化视图定义，而在底层支撑是否完备：
- 没建物化视图日志，或日志没包含
INCLUDING NEW VALUES—— 快速刷新（FAST）直接失效，REFRESH只能退成COMPLETE，而分区大表做COMPLETE刷新极慢甚至超时 - 日志建在分区表上，但用了
WITH PRIMARY KEY，而分区键不在主键里 → 日志无法捕获跨分区 DML，刷新失败且状态变UNUSABLE - 分区表做了
EXCHANGE PARTITION，但没对对应物化视图日志执行DBMS_MVIEW.REFRESH_DEPENDENT或手动补刷新 → 状态滞留STALE，且后续FAST刷新拒绝执行 - 物化视图定义里用了
SELECT *，而分区表新增了列 → 触发NEEDS_COMPILE，不编译就查不到新列，甚至整个查询报ORA-12018
DBMS_MVIEW.EXPLAIN_MVIEW 查具体不支持原因
光看状态不够，得知道“为什么不能 FAST”或“为什么不能重写”。先确保已运行 @?/rdbms/admin/utlxmv.sql 建好 MV_CAPABILITIES_TABLE，再执行：
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('MV_MY_PARTITIONED_TABLE');
然后查结果：
SELECT CAPABILITY_NAME, RELATED_TEXT, MSGTXT
FROM MV_CAPABILITIES_TABLE
WHERE STATEMENT_ID = 'MV_MY_PARTITIONED_TABLE'
AND CAPABILITY_NAME NOT IN ('REWRITE', 'REFRESH_FAST')
AND RELATED_TEXT IS NOT NULL;
- 出现
REFRESH_FAST_AFTER_INSERT但提示FAILED→ 检查日志是否含SEQUENCE和ROWID（分区表推荐用WITH ROWID日志） - 出现
PCT能力缺失 → 表明没启用增强型更新跟踪（EUT），分区维护操作（如SPLIT/TRUNCATE）后无法FAST刷新 - 出现
REWRITE_GENERAL失败 → 查询重写被禁用，可能是物化视图含不支持的函数、子查询或远程表引用
分区表物化视图刷新失败后最易忽略的三件事
很多人修完日志、重编译完就以为完事了，其实还有几个硬性条件常被跳过：
- 物化视图日志表（
mlog$_xxx）本身不能是DISABLED状态 —— 查user_mview_logs的LOG_TABLE列对应表的STATUS，若为INVALID，需DROP并重建日志 - 如果物化视图基于多个分区表联结，所有主表都必须有对应日志，且日志中字段要覆盖
SELECT列（特别是GROUP BY或聚合字段） -
REFRESH命令里漏了ATOMIC_REFRESH => FALSE—— 分区大表默认原子刷新会锁全表，容易超时或阻塞其他会话；设为FALSE允许分批删插，但需确保应用能容忍中间态
分区表物化视图真正卡住的地方，往往不在语法，而在日志与分区操作之间的隐式契约——一旦打破，状态就停在 STALE 或 UNUSABLE，而错误信息通常藏在 DBA_MVIEW_ANALYSIS 或后台 trace 文件里，不主动挖就看不到。
