V$TEMPSEG_USAGE无法准确反映并行查询临时空间消耗，因其仅关联用户会话（saddr），不区分并行度，未记录PX进程（P00x）独立占用，且无degree/server_name字段，无法拆解累计blocks至各PX进程；须结合V$PX_SESSION与V$TEMPSEG_USAGE关联追踪QC-PX-Segment三层链路。
不能只查 v$tempseg_usage 就认为抓到了并行查询的临时空间消耗——它不区分并行度，也不记录并行服务器进程（p00x）的独立占用，容易把多个px进程的叠加用量当成单个会话行为。
为什么 V$TEMPSEG_USAGE 无法准确反映并行查询的临时空间消耗
这个视图只关联到用户会话（saddr），但并行查询中真正分配和使用临时段的是后台 PX 进程（如 P000, P001），它们不显示在 V$SESSION 的常规会话列表里；V$TEMPSEG_USAGE 中的 blocks 是所有 PX 进程对该会话的累计值，无法拆解到每个并行服务器；更关键的是，它没有 degree 或 server_name 字段，你看到 5000 MB 占用，根本不知道是 2 个 PX 进程各占 2500 MB，还是 10 个各占 500 MB——这对资源隔离和限流毫无指导意义。
必须结合 V$PX_PROCESS 和 V$TEMPSEG_USAGE 关联查询
要定位真实消耗来源，得先找出哪些 PX 进程属于哪个并行查询，再匹配其临时段使用。核心逻辑是：通过 V$PX_PROCESS 找出正在服务某 SQL 的 PX 进程（server_name），再用其 addr 去 V$TEMPSEG_USAGE 查对应占用。
-
V$PX_PROCESS.server_name（如P000）可与V$TEMPSEG_USAGE.session_addr关联——注意：不是直接等值，而是需用V$PX_PROCESS.qcinst_id+V$PX_PROCESS.qcsid定位 QC（Query Coordinator）会话，再查该 QC 下所有 PX 进程的临时段 - 推荐写法：先查
V$PX_SESSION（它直接关联 QC 和 PX 的映射），再左连V$TEMPSEG_USAGE，避免漏掉未活跃但已分配段的 PX 进程 - 示例关键字段组合：
SELECT px.qcsid, px.qcserial#, px.server_name, t.blocks * tbs.block_size / 1024 / 1024 AS mb_used, t.segtype FROM V$PX_SESSION px JOIN V$TEMPSEG_USAGE t ON px.sid = t.session_num JOIN dba_tablespaces tbs ON t.tablespace = tbs.tablespace_name WHERE t.tablespace = 'TEMP'
如何识别高消耗并行 SQL 并追溯执行计划
仅看 MB 数不够，得知道是哪个操作（Sort/Hash/Temp Table）在吃空间，以及是否因并行度设置过高导致浪费。
- 用
V$SQL_PLAN查operation含SORT、HASH JOIN、GROUP BY的语句，并过滤other_xml中的px_inmemory或px_server属性确认是否启用并行 - 重点检查
V$SQL_WORKAREA中policy = 'AUTO'且actual_mem_used > max_mem_used的记录——说明 Oracle 被迫 spill 到磁盘，这是临时空间暴涨的直接原因 - 若发现
V$SQL_WORKAREA.active_time很长但work_area_size很小，大概率是并行度（DEGREE）设得太高，而 PGA_AGGREGATE_TARGET 不足，导致每个 PX 进程分到内存太少，集体落地
监控脚本必须避开的三个坑
很多 DBA 写的“实时监控”脚本一跑就卡，或者结果跳变剧烈，问题往往出在这三处：
- 别在循环里反复查
V$TEMPSEG_USAGE—— 它底层锁开销大，频繁扫描会阻塞其他 DML；改用每 30 秒采样一次 + 缓存上次结果做 delta 计算 - 不要用
dba_temp_files.bytes - v$temp_space_header.bytes_free算“已用”，因为v$temp_space_header只反映文件头缓存状态，可能滞后数秒；应以V$TEMPSEG_USAGE.blocks×block_size为准 - 忽略
V$PX_PROCESS的status = 'IN USE'过滤——有些 PX 进程已结束但段未释放，status变成IDLE，但V$TEMPSEG_USAGE里仍有记录，漏掉这部分会导致低估 20%+ 实际用量
真正有效的并行临时空间监控，本质是“QC–PX–Segment”三层链路的闭环追踪。任何跳过 V$PX_SESSION 或 V$PX_PROCESS 的方案，都只能看到水面以上的冰山一角——尤其在 12c 的自适应并行调度下，PX 进程生命周期极短，瞬时快照比平均值重要得多。
