ASH数据默认仅保留约1小时，短时问题须查v$active_session_history；wait_class='User I/O'需结合具体event及p1/p2定位；后台进程需显式过滤session_type='BACKGROUND'；RAC下必须用gv$ash并关注time_waited和current_obj#。
查不到最近的等待事件？先确认视图和时间窗口
ASH 不是实时日志，而是每秒从 v$session 采样一次活跃会话的状态，数据存在 SGA 的循环缓冲区里，默认只保留约 1 小时（实际取决于负载和 _ash_size）。如果问题发生在 90 分钟前，v$active_session_history 里很可能已经刷出内存；而 dba_hist_active_sess_history 是 AWR 每小时落盘一次，延迟更高。
实操建议：
- 短时突发问题（如 CPU 突增、SQL 响应变慢），必须查
v$active_session_history，别直接翻 AWR 报告 - 用
SELECT MIN(sample_time), COUNT(*) FROM v$active_session_history粗略估算当前还剩多少分钟数据 - 若常“查不到”，说明 ASH buffer 被高负载挤占，可临时调大
memory_target或显式设置sga_target - 注意：实例重启后
v$active_session_history清空，历史数据只能靠dba_hist_active_sess_history
为什么 wait_class = 'User I/O' 却不是磁盘慢？
wait_class 只是粗粒度分类，真正定位瓶颈得看具体 event 名称和参数。比如 db file sequential read 高，不等于存储慢——它常对应索引查找，平均等待时间高更可能是缓存不足或索引块离散；direct path read 高，则说明 SQL 绕过了 buffer cache，数据根本没被缓存过。
实操建议：
- 过滤时加
wait_class IN ('User I/O', 'System I/O')，但必须进一步拆解event - 关注
p1（file#）和p2（block#）：若集中在少数几个数据文件，问题在局部磁盘组，不是整体 IO - 对比
buffer_gets和disk_reads：比值接近 1，说明几乎没走缓存——根因是 SQL 设计或统计信息失效，不是 IO 子系统 - 避免误判：把
SQL*Net message from client当作 I/O 等待，它属于网络类，应加AND event NOT LIKE 'SQL%Net%'排除
后台进程（DBWR/LGWR）的等待为啥总查不到？
ASH 默认不保留后台进程采样，很多 DBA 直接查 v$active_session_history 全表，结果发现 DBW 或 LGWR 进程踪迹全无。这是因为后台进程采样需显式过滤，且默认 session_type 是 'BACKGROUND'，不是 'FOREGROUND'。
实操建议：
- 查 DBWR：加
program LIKE '%DBW%'和session_type = 'BACKGROUND'，重点看event = 'db file parallel write'的平均等待时间 - 查 LGWR：对比
log file sync和log file parallel write的平均等待——若前者远高于后者（如 25ms vs 8ms），问题不在写盘，而在日志切换、归档阻塞或 latch 争用 - 别漏掉
v$bgprocess中的io_wait_time和write_time差值：差值大说明 OS 层或存储响应延迟严重 - ASH 中
BLOCKING_SESSION字段对后台进程基本为空，定位持锁者必须结合v$session实时查
RAC 环境下并行查询（PQ）等待总对不上？
在 RAC 中，PX coordinator 和 PX slave 可能跨节点运行，单查 v$active_session_history 只能看到本实例的采样，关键等待如 PX Deq: Execution Message 很可能完全缺失。
实操建议：
- 必须用
gv$active_session_history，且按inst_id分组比对 - 判断并行倾斜不能只看
COUNT(*)，那是被采到的次数，不代表真实等待时长；要盯time_waited（单位微秒） - 硬信号是
MAX(time_waited) > 5000000（即 > 5 秒）：至少有一个 PX slave 卡住，拖慢整个并行组 - 若
AVG(time_waited)很低但MAX极高，基本可断定是数据分布倾斜或分区裁剪失效，而非资源不足 - 别忽略
current_obj#：关联dba_objects查出正在访问的表，再检查其分区策略和统计信息是否最新
session_type 和 sample_time 的组合过滤，而这恰恰是区分真实瓶颈和采样噪声的关键。 
