V$PX_SESSION查不到物化视图完全刷新的并行会话，因其默认不走并行路径，仅当基表启用并行且刷新语句显式指定PARALLEL hint时才可能触发PX进程；该视图仅显示实时活跃的PX worker，不含QC或历史记录。
为什么 V$PX_SESSION 查不到物化视图刷新的并行会话？
因为物化视图完全刷新（refresh complete）默认不走并行执行路径，哪怕你显式指定了 parallel hint 或设置了 parallel_degree_policy，oracle 也可能在解析阶段就降级为串行——尤其是当基表没有启用并行度、或统计信息缺失时。v$px_session 只显示当前活跃的并行服务进程（px server），没启动 px 就自然查不到。
实操建议：
- 先确认刷新是否真走了并行：查
V$SESSION中对应会话的QCINST_ID和QCSID非空，且SERVER_GROUP> 0 - 强制触发并行刷新需满足：基表有
PARALLEL属性（ALTER TABLE t PARALLEL 4），且刷新语句中显式加/*+ PARALLEL(mv_name, 4) */ - 注意
DBMS_MVIEW.REFRESH的parallelism参数仅对快速刷新（FAST）生效，对 COMPLETE 刷新无效
V$PX_SESSION 能看到什么、什么时候看？
它只反映“正在干活”的 PX 进程快照，不是刷新生命周期的全程日志。物化视图刷新涉及多个阶段（扫描基表、构建临时段、插入目标 MV、更新物化视图日志等），只有其中计算密集型阶段（如大表全表扫描）才可能派发 PX server。
实操建议：
- 在刷新执行中高频轮询：
SELECT qcsid, server_group, server_set, degree FROM V$PX_SESSION WHERE qcsid IN (SELECT sid FROM V$SESSION WHERE program LIKE '%refresh%') - 若
server_group为 0，说明该会话是 Query Coordinator（QC），不是 worker；真正干活的是server_group > 0的行 - 注意
V$PX_SESSION不保留历史，刷新一结束，记录立刻消失，不能靠它回溯已完成任务的并行度
替代方案：从 V$SQL_PLAN 看并行计划是否生成
比盯着 V$PX_SESSION 更可靠的方式，是检查刷新 SQL 是否生成了并行执行计划。物化视图刷新最终会转成一条或几条 DML/SELECT 语句，这些语句的执行计划里会有 PX 相关操作符。
实操建议：
- 刷新前开启 SQL trace：
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';，刷新后用 tkprof 分析，找含LOAD AS SELECT或INSERT SELECT的 SQL ID - 查计划：
SELECT operation, options, object_name, cost FROM V$SQL_PLAN WHERE sql_id = '<your_sql_id>' AND operation LIKE '%PX%'</your_sql_id> - 关键指标是
DEGREE字段值（非NULL且 > 1），以及是否存在PX COORDINATOR/PX SEND/PX RECEIVE节点
容易被忽略的隐性限制
即使所有配置看起来都对，物化视图完全刷新仍可能静默退回到串行——不是 bug，是 Oracle 的保守决策机制在起作用。
常见踩坑点：
- 基表虽设了
PARALLEL 4，但实际数据块数 cpu_count * parallel_threads_per_cpu，优化器认为并行收益为负，直接跳过 - 刷新语句里用了
UNION ALL或复杂子查询，导致并行传播中断（NO_PARALLEL传染） -
COMPATIBLE参数低于 12.2 时，某些物化视图结构（如含 JSON 列）不支持并行刷新 - 使用
ON COMMIT刷新模式时，并行度被强制限制为 1，无法绕过
真实环境里，并行刷新的稳定性高度依赖基表统计信息新鲜度和段级并行属性的一致性。查不到 V$PX_SESSION 记录，大概率不是监控方式错了，而是并行根本没起来。
