Oracle中怎么通过ASH分析Temp临时表空间I/O爆满原因-Oracle-PHP中文网

必须限定时间范围并按sql_id与plan_hash_value聚合ash数据以准确定位temp写抖动，因v$sort_usage的sql_id不可靠且ash不存temp_space_allocated字段；临时表空间i/o抖动持续时间短、爆发性强，不加时间过滤和正确聚合会导致结果稀释、响应慢、漏掉问题窗口。

oracle中怎么通过ash分析temp临时表空间i/o爆满原因

直接查 v$active_session_history 中的 direct path write temp 等待事件，但必须加时间过滤和按执行计划聚合，否则结果无效。

为什么不能直接 SELECT * FROM v$active_session_history WHERE EVENT = 'direct path write temp'

因为临时表空间 I/O 抖动通常只持续几分钟，甚至几十秒；全表扫描 v$active_session_history 会： - 拖慢查询本身（ASH 表可能有数百万行） - 返回大量低采样、无意义的历史记录，稀释真实问题窗口 - 完全错过真正高负载的那几秒——抖动峰值往往被平均掉 - DELTA_TIME 在短事件中常为 0 或被合并，用 SUM(DELTA_TIME) 统计反而失真

必须限定时间范围并按 SQL_ID + PLAN_HASH_VALUE 聚合

临时写入不是按“SQL 文本”发生的，而是按“实际执行计划”触发的。尤其并行 SQL：多个 PX 进程共享同一 SQL_ID，但各自写 temp，若只 GROUP BY SQL_ID，会把一次执行误算成 N 次，误导定位。

时间范围建议从最近 5–10 分钟开始：sample_time > SYSDATE - 1/144（10 分钟）或更窄，如 - 1/288（5 分钟）
必须 GROUP BY SQL_ID, PLAN_HASH_VALUE，不能省略后者
统计用 COUNT(*)（采样次数），它反映该执行计划在抖动窗口内被观测到的频次，比耗时类指标更稳定

典型语句：

Agent Git Oracle

高级仓库分析与重构指南。基于AI推理识别技术债务与架构反模式。

下载

SELECT SQL_ID, PLAN_HASH_VALUE, COUNT(*) samples
FROM v$active_session_history
WHERE EVENT = 'direct path write temp'
  AND sample_time > SYSDATE - 1/288
GROUP BY SQL_ID, PLAN_HASH_VALUE
ORDER BY samples DESC
FETCH FIRST 5 ROWS ONLY;

别信 v$sort_usage.SQL_ID，它和当前写 temp 的 SQL 几乎无关

v$sort_usage 里的 SQL_ID 来自 v$session.prev_sql_id，只要会话执行了新语句，旧临时段就“断连”。你看到的可能是 20 分钟前的一条简单查询，而此刻正在狂写 temp 的是另一条未被捕获的并行报表 SQL。

ASH 是唯一能捕获“溢出发生瞬间”的来源——每秒采样一次，带完整上下文（含当时真实的 SQL_ID 和 PLAN_HASH_VALUE）
查到高采样 SQL 后，下一步不是杀会话，而是立刻用 DBMS_XPLAN.DISPLAY_CURSOR 看执行计划，确认是否存在磁盘排序路径（如 SORT ORDER BY、HASH JOIN、TEMP TABLE TRANSFORMATION）
如果计划里没这些节点，说明写 temp 可能来自隐式操作（如大对象处理、索引重建），需结合 sql_id 查 v$sql 的 command_type 和 sql_text 上下文

临时段归属错误是生产环境高频误操作点

靠 v$sort_usage 找到的 session，90% 以上不是真正的问题源头。一旦误杀，不仅解决不了 I/O 抖动，还可能中断关键事务或报表作业。真正的线索藏在 ASH 的采样快照里——它不依赖会话状态，只忠实记录“那一秒发生了什么”。时间窗越窄、聚合维度越准（SQL_ID + PLAN_HASH_VALUE）、统计方式越简单（COUNT），定位就越可靠。复杂度不在查询本身，而在对采样逻辑和临时段生命周期的理解是否到位。