ASH 中查不到 TEMP_SPACE_ALLOCATED 字段，因其仅存在于 DBA_HIST_SQLSTAT、V$SQL_WORKAREA_ACTIVE 和 V$TEMPSEG_USAGE 等视图中；ASH 仅记录等待事件如 'direct path write temp' 或 'sort segment request'，不包含空间分配量。
temp_space_allocated 在 ash 里查不到——别在 dba_hist_active_sess_history 或 v$active_session_history 中过滤这个字段，它根本不存在。
ASH 不记录 TEMP_SPACE_ALLOCATED 字段
Oracle ASH 的设计目标是捕获会话“正在等什么”，不是“用了多少空间”。TEMP_SPACE_ALLOCATED 是会话级累计值，只出现在执行结束后的 SQL 统计快照中（DBA_HIST_SQLSTAT）或实时内存操作视图里（V$SQL_WORKAREA_ACTIVE、V$TEMPSEG_USAGE）。ASH 的 EVENT 列最多出现 direct path write temp 或 sort segment request 这类等待事件，但不带字节数。
- 直接查
ASH.TEMP_SPACE_ALLOCATED IS NOT NULL的语句永远返回空结果 -
DBA_HIST_ACTIVE_SESS_HISTORY是每 10 秒采样一次的持久化副本，字段更少，更不可能含该列 - 想确认某次采样是否涉及临时段操作，只能看
EVENT和SQL_ID的组合
替代方案：用 EVENT + SQL_ID 定位高消耗会话
临时表空间争用的真实信号是“等待”和“并发分配”，不是单次分配量。重点抓两类事件：
-
EVENT = 'direct path write temp'：说明会话正在把排序/哈希结果写入磁盘，已溢出 PGA -
EVENT = 'sort segment request'：说明多个会话同时申请临时段，可能触发位图块争用 - 搭配
TIME_WAITED > 5000000（单位微秒，即 >5 秒）过滤长等待样本，避免噪音 - 用
SESSION_ID和SESSION_SERIAL#关联V$SESSION查MACHINE、MODULE，快速定位应用模块
要查实际分配量，必须切到 V$TEMPSEG_USAGE
这是唯一能拿到 ALLOCATED_SPACE 实时值的地方，但它只反映“此刻活跃”的临时段使用：
-
ALLOCATED_SPACE单位是数据库块，需乘DB_BLOCK_SIZE才得字节数 - 必须用
SESSION_ADDR关联V$SESSION才能知道是谁；SQL_ID字段在 12c+ 才稳定，在 11g 需靠SQL_HASH_VALUE反查 - 若
ALLOCATED_SPACE >> USED_SPACE，说明执行计划预估严重偏差，或用了类似/*+ OPT_PARAM('_smm_max_size' 2048) */的 hint 强制放大 PGA - 该视图无历史数据，回溯只能靠
DBA_HIST_TEMPSEG_USAGE，但它的ALLOCATED_BLOCKS是快照点值，非峰值
AWR 中反向计算高消耗 SQL 的正确姿势
如果问题已过去，且你有 AWR 权限，可用 DBA_HIST_SQLSTAT 计算差值：
- 用
LAG(TEMP_SPACE_ALLOCATED) OVER (PARTITION BY SQL_ID ORDER BY SNAP_ID)算相邻快照增量 - 限定
SNAP_ID BETWEEN X AND Y，避开数据库刚启动或 AWR 清理后的空值 - 必须加
EXECUTIONS_DELTA > 0，否则归因无效；并按SQL_ID+PLAN_HASH_VALUE去重（并行执行会多进程上报） - 别信
V$SORT_USAGE.SQL_ID——它在 11g 常为空，12c 后也易丢失，优先用V$SQL_MONITOR（启用 MONITOR=YES 时）或 ASH 回溯
真正卡住系统的，往往不是某条 SQL 分配了多少 MB，而是几十个会话同时在 enq: TS - contention 上排队抢位图块。这时候盯着 TEMP_SPACE_ALLOCATED 数值本身，已经偏离了问题本质。
