ash查不到_temp space allocated，因其不采集该度量值；该字段属v$sql_workarea_active或v$tempseg_usage，需结合event、sql_id、等待时长及v$tempseg_usage等综合分析临时表空间争用。
ash里查不到_temp space allocated，别白费劲
ash（active session history）本身不采集临时表空间分配量这类度量值，_temp space allocated是v$sql_workarea_active或v$tempseg_usage里的字段，ash的event列最多只记录direct path read temp或sort segment request这类等待事件，但不带字节数。硬要在dba_hist_active_sess_history里搜这个字段，结果永远是空。
真正能定位临时表空间争用的ASH查询方式
得靠组合判断：看谁在等、等多久、等什么、同时在跑啥SQL。关键不是找“分配了多少”，而是找“卡在哪了”。
-
EVENT包含direct path read temp或sort segment request的会话，说明正在读/写临时段，且已触发物理IO或分配竞争 - 搭配
SQL_ID和SESSION_SERIAL#，关联V$SQL看执行计划里是否有TEMP TABLE TRANSFORMATION或大量SORT/HASH JOIN - 用
TIME_WAITED过滤累计等待超5秒的样本，避免噪音；注意ASH采样粒度是1秒，单次direct path read temp若小于1秒可能被合并或丢失 - 别只查
DBA_HIST_ACTIVE_SESS_HISTORY——它默认只保留7天（取决于AWR保留策略），实时问题优先查V$ACTIVE_SESSION_HISTORY
V$TEMPSEG_USAGE才是看_temp space allocated的正地方
这个视图每行对应一个会话当前正在使用的临时段，ALLOCATED_SPACE列就是你要的字节数（单位是数据库块，不是字节，要乘DB_BLOCK_SIZE才对）。但它只反映“此刻”，且仅对活跃的排序/哈希操作有效。
- 必须用
SESSION_ADDR关联V$SESSION才能知道是谁，SQL_ID字段在12c+才有，11g需靠SQL_HASH_VALUE反查 - 如果看到
ALLOCATED_SPACE远大于USED_SPACE，说明分配了但没全用——可能是SQL执行计划预估偏差大，或用了/*+ OPT_PARAM('_smm_max_size' 2048) */这类手动调大PGA的hint - 该视图不记录历史，想回溯得靠AWR快照里的
DBA_HIST_TEMPSEG_USAGE，但它的ALLOCATED_BLOCKS是采样点快照值，不是峰值
临时表空间争用的真实信号往往藏在V$SORT_SEGMENT和等待链里
当V$TEMPSEG_USAGE里多个会话反复申请/释放、V$SORT_SEGMENT显示CURRENT_USERS持续高位，再配合ASH里出现enq: TS - contention，基本就是表空间头块或位图块争用。这时候_temp space allocated数值本身已经不重要了——瓶颈在并发分配路径。
-
enq: TS - contention等待说明多个会话同时请求分配临时段，Oracle要串行化更新TS$或位图块，此时加大TEMP表空间数据文件数（分散头块压力）比调大PGA_AGGREGATE_TARGET更有效 - 检查
V$TEMP_EXTENT_POOL的USED_BLOCKS是否接近TOTAL_BLOCKS，但注意这个视图在12c后被弃用，19c起要用V$TEMP_SPACE_HEADER - 如果应用频繁建
GLOBAL TEMPORARY TABLE并INSERT /*+ APPEND */，记得确认ON COMMIT DELETE ROWS还是PRESERVE ROWS——后者会导致临时段无法及时释放，撑高ALLOCATED_SPACE
临时表空间争用从来不是单个数字能说清的事，_temp space allocated只是表象，背后是执行计划、PGA配置、临时表设计、甚至磁盘IO能力的叠加反应。盯着一个字段查ASH，容易漏掉真正的瓶颈点。
