物化视图刷新不走v$sql_monitor，需用v$all_sql_plan_monitor监控；须statistics_level为typical/all且用户有select_catalog_role权限；查key后分两步定位执行步骤；fast刷新卡在table access by index rowid常因日志缺失sequence字段；complete刷新时buffer_gets高而disk_reads低说明内存排序，需防pga耗尽。
物化视图刷新不走 V$SQL_MONITOR，得用 V$ALL_SQL_PLAN_MONITOR
物化视图刷新（如 DBMS_MVIEW.REFRESH）本质是一组后台 PL/SQL 调用 + 隐式 SQL 执行，它不会自动出现在 V$SQL_MONITOR 中——哪怕你手动执行 REFRESH 且耗时超 5 秒。真正能捕获其内部 SQL 执行细节的，是 V$ALL_SQL_PLAN_MONITOR，它是 RAC 环境下跨实例、带步骤级运行时统计的“增强版监控视图”。
关键点在于：刷新过程触发的底层 SQL（比如增量更新语句、日志表扫描、JOIN 合并等）会被独立监控，但必须满足两个前提：
- 数据库参数
statistics_level必须为TYPICAL或ALL（BASIC会禁用所有实时监控） - 刷新操作需由具备
SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY权限的用户发起，否则监控数据对当前会话不可见
查刷新 SQL 的 KEY 和 PLAN_LINE_ID 要连查两次
物化视图刷新不是单条 SQL，而是多阶段执行：先查日志、再构造 delta、最后 merge 到主 MV 表。这些步骤分散在不同 SQL_EXEC_ID 下，且每个步骤可能对应多个 PLAN_LINE_ID。直接查 V$ALL_SQL_PLAN_MONITOR 容易漏掉中间环节。
推荐做法是分两步定位：
- 第一步：从
V$ALL_SQL_MONITOR中找刷新触发源头
执行：SELECT key, sql_id, sql_exec_id, sql_exec_start, status FROM v$all_sql_monitor WHERE sql_text LIKE '%mv_sales_daily%' AND status = 'EXECUTING' ORDER BY sql_exec_start DESC
注意过滤status = 'EXECUTING'，避免看到已结束的历史记录 - 第二步：用上一步拿到的
key查详细步骤
执行：SELECT plan_line_id, plan_operation, plan_options, output_rows, last_output_rows, elapsed_time FROM v$all_sql_plan_monitor WHERE key = 'xxx...' ORDER BY plan_line_idoutput_rows是当前已处理行数，last_output_rows是上一秒增量，二者差值可判断是否卡住
FAST 刷新卡在 TABLE ACCESS BY INDEX ROWID？检查日志字段是否缺失
当 V$ALL_SQL_PLAN_MONITOR 显示某行 plan_operation = 'TABLE ACCESS BY INDEX ROWID' 且 elapsed_time 持续飙升、output_rows 几乎不动，大概率是快速刷新退化为慢路径——常见原因是物化视图日志字段不全。
例如物化视图含 WHERE e.deptno = d.deptno，但 dept 表日志只建了 WITH PRIMARY KEY，没加 SEQUENCE(deptno)，Oracle 就无法定位变更行，被迫回退到全表扫描基表。
验证方式：
- 查日志定义：
SELECT log_table, log_owner, primary_key, rowid_, sequence#, include_new_values FROM dba_mview_logs WHERE log_table IN ('MLOG$_EMP', 'MLOG$_DEPT') - 比对
sequence#列是否包含所有 JOIN/WHERE 中出现的列名（区分大小写） - 若缺失，需重建日志：
CREATE MATERIALIZED VIEW LOG ON dept WITH PRIMARY KEY, SEQUENCE(deptno) INCLUDING NEW VALUES
COMPLETE 刷新时 BUFFER_GETS 突增但 DISK_READS 很低？说明走了内存排序
完全刷新执行的是完整 SELECT + INSERT AS SELECT，若 V$ALL_SQL_PLAN_MONITOR 显示某 plan_operation = 'SORT GROUP BY' 或 'HASH JOIN' 的 buffer_gets 远高于 disk_reads（比如 100万 vs 0），说明 Oracle 正在 PGA 内完成大排序或哈希构建——这本身不是问题，但意味着你要关注 pga_aggregate_target 是否足够。
风险点在于：如果该刷新作业并发运行，多个大内存操作可能触发 ORA-04030（内存耗尽）。此时不能只看单次刷新的 elapsed_time，而要查 sql_exec_id 对应的 v$session_longops 中是否有 message 含 “sort” 或 “hash join” 且 time_remaining > 0 的长操作。
容易被忽略的是：即使刷新 SQL 在 V$ALL_SQL_PLAN_MONITOR 中已显示 STATUS = 'DONE'，其后台排序临时段可能尚未释放，需查 v$tempseg_usage 确认 segtype = 'SORT' 是否残留。
