不能单靠V$TEMPSEG_USAGE判断临时空间占用者，必须关联V$PX_SESSION与V$TEMPSEG_USAGE定位真实PX进程（如P000），因QC会话仅显示累计值而实际分配由后台PX进程完成。
不能靠 V$TEMPSEG_USAGE 单独判断谁在吃临时空间，也不能用 SESSION_TIMEOUT 直接杀并行查询的临时段占用者——它不作用于 PX 进程，且对已分配但未释放的临时段无效。
查不到真实消耗来源？必须关联 V$PX_SESSION 和 V$TEMPSEG_USAGE
直接查 V$TEMPSEG_USAGE 只能看到 QC（Query Coordinator）会话名下的累计 blocks，但真正分配和写入临时段的是后台 P000、P001 等 PX 进程。它们不显示在 V$SESSION 里，也不出现在 V$TEMPSEG_USAGE.session_addr 的常规匹配路径中。
- 正确做法是先通过
V$PX_SESSION找出属于同一查询的所有 PX 进程（含qcsid、qcserial#、server_name），再用sid关联V$TEMPSEG_USAGE.session_num - 别用
V$PX_PROCESS.addr = V$TEMPSEG_USAGE.session_addr—— 字段类型不一致，且V$PX_PROCESS中的addr是进程地址，不是会话地址 - 示例关键字段组合：
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'
- 如果某
server_name（如P005）持续占用 >2GB 且对应 SQL 已运行超 10 分钟，基本可判定为异常
想自动终止？SESSION_TIMEOUT 对 PX 进程完全无效
ALTER SYSTEM SET SESSION_TIMEOUT=1800 只影响新建立的用户会话（QC），对已派生的 PX 进程不起作用。这些进程生命周期由 QC 控制，即使 QC 被 kill，PX 进程也可能残留数秒至数分钟，并继续持有临时段。
- 真正能中断并行操作的，是杀 QC 的
SID,SERIAL#：ALTER SYSTEM KILL SESSION '123,45678' IMMEDIATE - 但要注意：若该会话正在执行 DML 并持有事务锁，
IMMEDIATE仍需等待回滚完成，期间临时段不会立即释放 - 不要依赖
DBA_BLOCKERS或v$lock中的blocking_others = 'VALID'来触发 kill —— 并行查询的临时段争用通常不表现为传统锁阻塞，而是资源耗尽型等待（如direct path write temp） - 若需自动化，建议封装脚本：先查
V$PX_SESSION+V$TEMPSEG_USAGE找出高 MB 占用且px.qcserial#对应的 QCSID，再调用KILL SESSION；注意加SLEEP 1避免连续高频 DML 操作触发 Oracle 内核节流（ORA-00600）
为什么 V$ACTIVE_SESSION_HISTORY 查不到 PX 进程的临时段等待？
因为 V$ACTIVE_SESSION_HISTORY 默认只采样前台会话（session_type = 'FOREGROUND'），而 PX 进程属于后台进程（session_type = 'BACKGROUND'），即使它们正卡在 direct path write temp 或 parallel query queue 上，也不会被记录进 ASH。
- 验证方式：执行一个大并行排序后立刻查
SELECT COUNT(*) FROM V$ACTIVE_SESSION_HISTORY WHERE event LIKE '%temp%' AND session_type = 'BACKGROUND'，结果几乎为 0 - 替代方案是查
V$SESSION_WAIT（实时）或V$SESSION_EVENT（累计），过滤event IN ('direct path write temp', 'direct path read temp', 'parallel query queue')，再关联V$PX_SESSION定位源头 - 别指望用 ASH 的
blocking_session追踪临时段争用——它压根不采集 PX 进程的阻塞关系
临时段监控最易被忽略的一点：临时表空间本身没有“使用率告警”机制，DBA_HIST_TBSPC_SPACE_USAGE 不记录临时表空间，V$TABLESPACE_USAGE_METRICS 对 TEMP 表空间返回值恒为 0。你只能靠定期轮询 V$TEMPSEG_USAGE + V$PX_SESSION 组合来感知风险，且必须接受 5–10 秒级延迟——这是 Oracle 内核层面的设计限制，不是配置能绕过的。
