查v$tempseg_usage可获session_addr、sql_id等信息但无sql文本，sql_id可能已老化；需联v$session、v$sql_plan、ash等视图综合分析临时段占用源头。
查 V$TEMPSEG_USAGE 能看到谁在用临时段，但看不到 SQL 文本
直接查 V$TEMPSEG_USAGE 可以拿到 SESSION_ADDR、SQL_ID、SEGMENT_NAME 和 TABLESPACE 等关键字段，但它不包含执行的 SQL 语句本身。很多 DBA 卡在这一步，以为查到 SQL_ID 就完事了，结果发现 V$SQL 里查不到——因为大排序或并行操作生成的临时段，对应的 SQL_ID 可能已从共享池老化淘汰。
- 优先关联
V$SESSION获取SID、SERIAL#、USERNAME、MACHINE和PROGRAM - 用
V$SQL_PLAN回溯执行计划（需带SQL_ID和CHILD_NUMBER），重点看OPERATION含SORT、HASH JOIN、GROUP BY的行 - 若
SQL_ID在V$SQL中为空或查无记录，说明语句已不在共享池，此时必须依赖V$SESSION_LONGOPS或 ASH（V$ACTIVE_SESSION_HISTORY）反查历史上下文
用 V$ACTIVE_SESSION_HISTORY 追临时段峰值时刻的会话行为
V$ACTIVE_SESSION_HISTORY 每秒采样一次（默认保留 1 小时），是定位“临时段突然暴涨”源头最可靠的动态视图。它能把临时段使用量（TEMP_SPACE_ALLOCATED）和具体执行堆栈绑定起来，哪怕 SQL 已结束。
- 筛选条件必须包含：
SESSION_STATE = 'WAITING'且EVENT LIKE '%temp%'（如direct path write temp、read by other session等） - 加
TEMP_SPACE_ALLOCATED > 104857600（100MB）过滤显著占用者，避免噪音 - 用
SQL_ID+SQL_PLAN_HASH_VALUE关联V$SQL_PLAN，确认是否为ORDER BY、WINDOW SORT或大表CREATE INDEX类操作 - 注意
SESSION_SERIAL#和SESSION_ID是实时快照值，不能直接用于ALTER SYSTEM KILL SESSION，需先查V$SESSION确认当前状态
V$TEMP_EXTENT_POOL 和 V$TEMP_SPACE_HEADER 告诉你空间到底卡在哪一级
临时表空间不是“用了就还”，而是按 extent 分配再复用。V$TEMP_EXTENT_POOL 显示每个 tempfile 当前被多少 session 持有 active extents；V$TEMP_SPACE_HEADER 则反映 header block 中的 free space 统计——这两者差异大，说明存在 extent 碎片或分配争用。
-
V$TEMP_EXTENT_POOL中USED_EXTENTS高但V$TEMP_SPACE_HEADER.FREE_SPACE也高？大概率是多个小查询反复申请/释放小 extent，未触发合并 - 如果
V$TEMP_EXTENT_POOL.MAX_SIZE接近DBA_TEMP_FILES.BYTES，且V$TEMP_SPACE_HEADER.USED_SPACE持续增长，说明临时表空间物理文件确实不够，需要扩容或清理长事务 - 别只看
DBA_TEMP_FREE_SPACE：它显示的是“逻辑空闲”，不等于 OS 层可回收空间；真正瓶颈常在 extent 分配锁（enq: TS - contention）
杀会话前先确认是不是并行或递归操作
直接 ALTER SYSTEM KILL SESSION 可能无效甚至引发 ORA-00031：“session marked for kill”，尤其当目标会话正在执行并行 DML、物化视图刷新或 DBMS_STATS 收集统计信息时——这些操作内部会启动多个 PX slave，主会话 kill 后 slave 仍可能继续占用临时段。
- 查
V$PX_SESSION，用QCSID关联主会话，确认是否存在并行子进程 - 检查
V$SESSION的CLIENT_INFO和ACTION字段，常见值如DBMS_STATS、REFRESH_MV、DBMS_SQLTUNE都暗示后台任务，不宜贸然中断 - 对疑似递归调用（如 trigger 中隐式排序），应先停应用侧批量提交，而非直接 kill
临时段占用分析最难的不是查哪个视图，而是把 SQL_ID、SESSION、EXTENT 分配状态 和 ASH 时间线 四条线索在时间维度上对齐——差几秒就可能错过关键帧。实际排查时，建议先抓一个 5 分钟窗口的 ASH 样本，再逆向打点验证，比单看某张视图更可靠。
