v$active_session_history是Oracle 19c定位临时表空间争用最及时可靠的入口，通过筛选direct path write temp事件、按SQL_ID和PLAN_HASH_VALUE分组统计采样次数，并结合DBMS_XPLAN.DISPLAY_CURSOR验证执行计划溢出点来精准识别落盘操作。
v$active_session_history 是 Oracle 19c 中定位临时表空间争用最及时、最可靠的入口——它不依赖 SQL 是否还在执行，也不受共享池老化影响，只要 direct path write temp 发生过，ASH 就能捕获。
查 direct path write temp 等待事件最准
这个等待事件是 Oracle 写入临时表空间物理文件的明确信号，比 sort write 或 read by other session 更直接。它代表排序、哈希连接或临时表操作已溢出到磁盘，不是 PGA 内存中完成的。
- 必须加时间过滤，否则结果稀疏且查询慢：
sample_time > SYSDATE - 1/144（最近 10 分钟）足够覆盖多数批处理窗口 - 必须按
SQL_ID和PLAN_HASH_VALUE双字段分组：并行执行时多个 PX 进程会共用同一SQL_ID，但不同执行计划可能资源消耗差异极大 - 统计用
COUNT(*)（采样次数），不用SUM(time_waited)：短事件中time_waited常为 0，不可靠
示例语句：
SELECT SQL_ID, PLAN_HASH_VALUE, COUNT(*) samples FROM v$active_session_history WHERE EVENT = 'direct path write temp' AND sample_time > SYSDATE - 1/144 GROUP BY SQL_ID, PLAN_HASH_VALUE ORDER BY samples DESC FETCH FIRST 5 ROWS ONLY;
用 DBMS_XPLAN.DISPLAY_CURSOR 验证执行计划溢出点
拿到高采样 SQL_ID 后，别急着改 SQL 文本。要确认它是否真在走落盘路径，重点看执行计划里有没有以下物理操作节点：
-
SORT ORDER BY、SORT GROUP BY、SORT AGGREGATE -
HASH JOIN、HASH GROUP BY、HASH UNIQUE -
TEMP TABLE TRANSFORMATION（尤其带大量 INSERT 的 WITH 子句）
运行：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('abc123xyz', 123456789));
注意看 TempSpc 列：有数值（单位字节）表示 CBO 预估需落盘；若为空但实际发生了 direct path write temp，说明优化器严重低估中间结果集大小——这时候查统计信息和隐式转换比调 SQL 更治本。
注意 TEMP_SPACE_ALLOCATED 在 ASH 里不可信
v$active_session_history.TEMP_SPACE_ALLOCATED 字段在 19c 中仍不稳定：
- 它只在某些采样点被填充，很多行是 NULL
- 并行执行时多个 PX 进程各自上报，容易重复计数
- 不同实例间（RAC）值无法合并，不能简单 SUM
所以不要写类似 ORDER BY TEMP_SPACE_ALLOCATED DESC 的查询来“找最大消耗者”。它可能把一条并行 SQL 拆成 8 行各报 200MB，看起来像 8 条独立大 SQL。
真正该盯的是等待事件本身——direct path write temp 出现一次，就代表至少一个数据块已写入 TEMP 文件，这是硬指标。
临时表空间争用往往发生在秒级内，等你连上去查 v$sort_usage，段早释放了。ASH 是唯一能回溯“那一刻正在干啥”的视图，但前提是得知道该筛哪个事件、怎么聚合、以及后续如何交叉验证执行计划。漏掉 PLAN_HASH_VALUE 或误信 TEMP_SPACE_ALLOCATED，排查就会绕远路。
