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，避免你查错对象
示例查询：
V$MVIEWS
- 是否被其他会话锁住基表？查
V$LOCK中TYPE = 'TM'且ID1对应基表OBJECT_ID - 物化视图日志是否被清理过早？错误
ORA-12034会导致刷新静默失败，但V$SESSION_LONGOPS仍显示“进行中” - 临时表空间是否耗尽？
COMPLETE刷新大量排序/聚合时，V$SORT_SEGMENT会暴增，但错误常延迟抛出
进度监控本身不难，难的是把 V$SESSION_LONGOPS 的数值和真实瓶颈对应起来——99% 卡住，往往不是快完成了，而是刚撞上第一个锁或空间问题。
