V$SESSION_LONGOPS 是唯一可靠方式；物化视图刷新属长期操作，不暴露于V$SESSION/V$PROCESS，DBA_MVIEWS字段无法反映实时进度，须用OPNAME LIKE 'Refresh%'且TOTALWORK!=0、SOFAR过滤。
直接查 V$SESSION_LONGOPS 是唯一可靠方式
物化视图刷新（尤其是 COMPLETE 或大范围 FAST）一旦启动，就属于 Oracle 的“长期运行操作”，不会在 V$SESSION 或 V$PROCESS 里暴露进度百分比。别试图从 DBA_MVIEWS.LAST_REFRESH_DATE 或 STALENESS 字段反推——它们只记录完成时间或状态，不反映当前进行中任务的进展。
必须用 V$SESSION_LONGOPS，它底层捕获的是 Oracle 内核级的进度计数器，对 DBMS_MVIEW.REFRESH 调用天然支持。关键过滤条件是：
-
OPNAME LIKE 'Refresh%'或OPNAME = 'mv refresh'（不同版本略有差异，LIKE 'Refresh%'更稳） -
TOTALWORK != 0且SOFAR ，否则可能是刚启动未初始化或已结束 - 排除
OPNAME LIKE '%aggregate%'，这类是内部统计，SOFAR/TOTALWORK无意义
V$SESSION_LONGOPS 返回字段怎么看才不误判
常见误区是盯着 TIME_REMAINING 或 ELAPSED_SECONDS 做预估——这两个字段在刷新类任务中波动剧烈，尤其当并行度变化或 I/O 等待突增时，剩余时间可能从 5 分钟跳到 2 小时再跳回 8 分钟，完全不可信。
真正该盯死的只有两个值：
-
ROUND(SOFAR / TOTALWORK * 100, 2)：这是目前最稳定的完成百分比，只要TOTALWORK不为 0 就有效 -
TARGET字段内容：它会明确写出被刷新的物化视图名，例如SCHEMA.MV_SALES_SUMMARY，避免你查错对象
示例查询：
SELECT SID, SERIAL#, OPNAME, TARGET,
ROUND(SOFAR/TOTALWORK*100, 2) "%_COMPLETE",
SOFAR, TOTALWORK
FROM V$SESSION_LONGOPS
WHERE OPNAME LIKE 'Refresh%'
AND TOTALWORK != 0
AND SOFAR < TOTALWORK;为什么 V$MVIEWS 和 DBA_MVIEW_LOGS 都不能反映刷新进度
DBA_MVIEWS 的 LAST_REFRESH_DATE 只在刷新成功提交后才更新；如果卡在中间（比如锁等待、空间不足、日志缺失），这个字段纹丝不动，看起来像“没动”，实际可能已卡住 20 分钟。
DBA_MVIEW_LOGS 里的 LOG_TABLE 行数增长也靠不住：它只反映基表 DML 触发的日志写入，和刷新进程本身无关。你可能看到日志表每秒涨 100 行，但刷新线程根本还没开始读日志——因为 FAST 刷新前还要做一致性校验、变更映射等前置步骤。
更隐蔽的坑是 RAC 环境：V$SESSION_LONGOPS 是实例级视图，若刷新由节点 2 发起，节点 1 上查不到任何记录。必须确认执行 DBMS_MVIEW.REFRESH 的会话所在实例，或改用 GV$SESSION_LONGOPS 并加 INST_ID 过滤。
物化视图刷新卡住时，优先排查这三件事
进度长时间停在 99% 或某固定值（如 37.5%），不是 UI 延迟，大概率是阻塞。立刻检查：
- 是否被其他会话锁住基表？查
V$LOCK中TYPE = 'TM'且ID1对应基表OBJECT_ID - 物化视图日志是否被清理过早？错误
ORA-12034会导致刷新静默失败，但V$SESSION_LONGOPS仍显示“进行中” - 临时表空间是否耗尽？
COMPLETE刷新大量排序/聚合时，V$SORT_SEGMENT会暴增，但错误常延迟抛出
进度监控本身不难，难的是把 V$SESSION_LONGOPS 的数值和真实瓶颈对应起来——99% 卡住，往往不是快完成了，而是刚撞上第一个锁或空间问题。
