90%物化视图不刷新的根因在日志表与基表关联失效，需查DBA_MVIEW_LOGS确认日志存在且rowids/primary_key为Y，用EXPLAIN_MVIEW定位具体能力缺失，验证日志表数据、OBJECT_ID一致性及状态，并结合10046跟踪和alert日志排查真实错误。
物化视图不刷新，90% 的根因不在物化视图本身，而在日志表与基表的关联关系是否完整、有效、未被破坏。
查 DBA_MVIEW_LOGS 确认日志是否存在且结构匹配
快速刷新依赖物化视图日志（MLOG$ 表）记录变更，但日志存在 ≠ 可用。常见错误是日志建了却没包含关键列，或用了 ROWID 但基表没启用 ROWID 支持（如 IOT 表）。
- 执行
SELECT log_owner, master, log_table, rowids, primary_key, object_id FROM DBA_MVIEW_LOGS WHERE master IN ('AAA', 'BBB');—— 确保rowids = 'Y'或primary_key = 'Y'，否则 FAST 刷新直接不可用 - 若日志表名是
MLOG$_AAA，检查它是否真包含物化视图 SELECT 中用到的所有列（如JOIN条件列、GROUP BY列），缺失任一列都会导致ORA-12054 - 注意：基表做
ALTER TABLE ... DROP COLUMN后，日志不会自动更新，必须重建日志
用 EXPLAIN_MVIEW 看具体哪条能力不满足
EXPLAIN_MVIEW 不是“有没有错”的开关，而是逐项告诉你“为什么不能 FAST”。它输出的 CAPABILITY_NAME 字段比错误码更直白。
- 先运行
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('YOUR_MV_NAME');，再查SELECT * FROM MV_CAPABILITIES_TABLE WHERE STATEMENT_ID = 'QSMQT_EXPLAIN_MVIEW'; - 重点关注
REFRESH_FROM_LOG_AFTER_ANY和REFRESH_FROM_LOG_AFTER_INSERT是否为DISABLED；若为UNKNOWN，说明日志结构或权限问题尚未排除 - 如果出现
PCT为DISABLED，但物化视图没涉及分区表，可忽略；若涉及分区，则需确认是否启用了增强型更新跟踪（EUT）
验证日志和基表的物理一致性
日志表和基表看似关联，实际可能因 DDL 操作断裂。最典型的是基表主键被删、约束失效、或日志表被手动 truncate。
- 查日志表数据：执行
SELECT COUNT(*) FROM MLOG$_AAA;，若长期为 0 但基表有 DML，说明日志未捕获变更（常见于日志未启用INCLUDING NEW VALUES） - 对比基表和日志表的
OBJECT_ID：SELECT object_id FROM dba_objects WHERE object_name = 'AAA';和SELECT master_object_id FROM dba_mview_logs WHERE log_table = 'MLOG$_AAA';必须一致，否则 Oracle 认为日志不属于该表 - 检查日志表是否 VALID：
SELECT status FROM dba_objects WHERE object_name = 'MLOG$_AAA';若为INVALID，需重建日志
刷新失败后只看 LAST_REFRESH_ERROR 是不够的
USER_MVIEWS.LAST_REFRESH_ERROR 只存最近一次错误，且常被覆盖。真正要抓现场，得盯住刷新时的会话级错误和 alert 日志。
- 执行刷新前，先开 session trace：
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12';，再跑DBMS_MVIEW.REFRESH，从 trace 文件里找真实报错堆栈 - 查 alert 日志中是否有
ORA-12034（日志太旧）、ORA-12008（远程 DBLINK 查询失败）、ORA-01555（快照过旧）—— 这些不会写进LAST_REFRESH_ERROR - 如果物化视图跨库（通过 DBLINK），
LAST_REFRESH_ERROR显示的是本地错误，实际问题可能在远端库缺少日志或权限
日志表不是“建了就完事”的静态对象，它和基表之间是强耦合的活连接。每次基表 DDL、每次日志重建、每次跨库链路变更，都可能悄悄断掉这个连接——而 Oracle 往往不报错，只是静默退化为 COMPLETE 刷新，或者干脆卡住不动。
