V$SQL_MONITOR查不到物化视图刷新，因其由DBMS_MVIEW.REFRESH等PL/SQL过程隐式执行，不走前台SQL监控路径；须用V$ALL_SQL_PLAN_MONITOR配合TYPICAL/ALL统计级别及相应权限定位执行步骤。
物化视图自动刷新（如 ON COMMIT 或 NEXT 定时任务）本身不暴露在 V$SQL_MONITOR 中，必须用 V$ALL_SQL_PLAN_MONITOR 配合权限和参数才能看到真实执行步骤。
为什么 V$SQL_MONITOR 查不到物化视图刷新？
因为 DBMS_MVIEW.REFRESH 是 PL/SQL 过程调用，其内部生成的 SQL 不走常规前台 SQL 监控路径。哪怕刷新耗时远超 5 秒，V$SQL_MONITOR 也基本为空——它只捕获显式提交的、独立的 SQL 执行，不抓后台隐式语句。
-
statistics_level必须设为TYPICAL或ALL；设成BASIC会彻底禁用所有实时监控能力 - 执行刷新的用户需有
SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY权限，否则查不到V$ALL_SQL_PLAN_MONITOR数据 - 自动刷新任务（如 DBMS_SCHEDULER job）由
ORACLE_OCM或SYS等后台用户触发，你自己的账号默认不可见，得切到对应用户或授权后查
怎么定位正在运行的刷新 SQL 的 KEY？
不能直接查 V$ALL_SQL_PLAN_MONITOR，它没索引、数据滚动快、KEY 不稳定。要先从源头找执行实例：
- 执行：
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'，避免看到已结束的历史记录 - 如果
sql_text模糊匹配不到，可改用sql_id IN (SELECT sql_id FROM v$sql WHERE sql_text LIKE '%MLOG%')，因为快速刷新必扫日志表
如何看刷新卡在哪一步？
拿到 KEY 后，查 V$ALL_SQL_PLAN_MONITOR 看每步的实时进展：
- 执行：
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_id -
output_rows是当前累计处理行数，last_output_rows是上一秒增量；若两者长时间不变，说明该步骤卡住 - 常见卡点：
TABLE ACCESS BY INDEX ROWID（快速刷新退化）→ 检查物化视图日志是否缺SEQUENCE字段；SORT GROUP BY耗时飙升 →BUFFER_GETS高但DISK_READS低，说明内存排序中，PGA 可能快耗尽
真正难的是跨步骤关联：一次刷新可能拆成 3–5 个 SQL_EXEC_ID，每个又含多条 PLAN_LINE_ID。没有固定 SQL_ID 可跟踪，只能靠 KEY + 时间窗口 + 操作类型组合判断。别指望一条语句查完全部，得手动拼上下文。
