DBMS_MVIEW.EXPLAIN_MVIEW是诊断物化视图FAST刷新失败的首要工具，需重点检查REFRESH_FAST行的MSGTXT、MSGNO和POSSIBLE='N'原因；日志缺失或结构不匹配必须DROP/CREATE重建并带全要素；ATOMIC_REFRESH=FALSE对大表刷新至关重要；job失败多因权限不足或统计信息失效。
DBMS_MVIEW.EXPLAIN_MVIEW 看清真正卡在哪
ORA-12008 或刷新静默退化为 COMPLETE，不代表语法错了，而是 Oracle 内部校验链断了。不查 DBMS_MVIEW.EXPLAIN_MVIEW 就动手改 SQL，大概率修错地方。
执行 DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME') 后，重点筛 CAPABILITY_NAME = 'REFRESH_FAST' 的行，盯紧三样：
-
MSGTXT是人话提示，比如 “materialized view log does not exist on table T1” 或 “outer join with OR in WHERE clause” -
MSGNO是编号，2005=缺日志、2012=漏 ROWID、2025=聚合不合规、2031=外连接含 OR/!= -
POSSIBLE = 'N'是最终判决，只要它为 N，FAST 就不可用
别跳过这步直接删 DISTINCT 或加索引——有些限制（如跨 DBLink 时远端版本不支持）只在 MSGTXT 里提一句，但足以让修复白忙。
物化视图日志缺失或字段不全必须重建
基表加了 NOT NULL 列、改了 DEFAULT 值、或删了主键后，MLOG$_TABLE_NAME 表结构和内容就和 MV 定义脱钩了。ALTER MATERIALIZED VIEW LOG 不生效，必须 DROP 再 CREATE。
重建命令要带全要素：
- 必须显式包含
WITH ROWID（如果 MV 定义依赖 ROWID）或WITH PRIMARY KEY -
SEQUENCE()括号里得列全所有参与 JOIN 和 FILTER 的字段，哪怕只是加了个col_x DEFAULT 0 - 必须加
INCLUDING NEW VALUES，否则 INSERT/UPDATE 新值不记日志
验证方式：查 USER_MVIEW_LOG_FILTERS，确认新增列出现在 COLUMN_NAME 列里；再跑一次 EXPLAIN_MVIEW，看 MSGNO 是否从 2005 变成 OK。
ATOMIC_REFRESH=FALSE 不是可选项，是大表刷新的刚需
默认 ATOMIC_REFRESH => TRUE 会让 FAST 刷新全程走事务：先 DELETE 再 INSERT，锁表+写大量 UNDO+撑爆回滚段。千万级数据一刷就卡死，v$session 看到 event 是 ‘enq: TX row lock contention’ 或 ‘db file sequential read’。
生产环境手动刷新必须显式关掉：
DBMS_MVIEW.REFRESH('MV_NAME', atomic_refresh => FALSE)- 定时 job 里调用封装过程时，参数不能省，不能靠默认值
- 副作用是刷新中 MV 短暂为空，应用层得能容忍——没双读逻辑就别开
开了之后，Oracle 改用 TRUNCATE + INSERT /*+ APPEND */，锁粒度降到分区级，速度通常快 3–5 倍，但前提是基表支持直接路径插入（无活动触发器、无引用完整性约束等）。
权限和统计信息是后台 job 失败的隐形推手
手动刷新成功但 job 失败，90% 是因为 job 进程（jnnn）不继承角色权限，且不认会话级设置。它只认显式授予的直接权限。
- 必须单独授
GRANT ALTER ANY MATERIALIZED VIEW TO your_user，CONNECT/RESOURCE 角色无效 - 基表和
MLOG$_XXX日志表都要有显式SELECT权限，跨 schema 时尤其容易漏 -
DBMS_STATS.GATHER_TABLE_STATS采集后，若没加NO_INVALIDATE => FALSE，可能意外使 MV 对应的包失效，间接阻塞刷新链
查 job 状态时，next_date = '4000-01-01' 就是失败超限后的兜底值，不是时间设错了；broken = 'Y' 且 failures > 0 说明已被 Oracle 自动停用，得先 DBMS_JOB.BROKEN(job_number, FALSE) 再重试。
EXPLAIN_MVIEW 显示 POSSIBLE='Y' 也照样刷不动。 
