Oracle大表查询太慢？如何利用ASH分析访问特征

ASH查活跃会话的实时等待事件、资源争用和高负载SQL，不查非活跃会话、完整执行计划、精确总耗时、绑定变量值及已老化出共享池的SQL。

ASH视图查什么，不查什么

先说一个核心认知：ASH（Active Session History）记录的，是每秒采样的活跃会话快照，它可不是一份事无巨细的完整SQL日志。这个定位决定了它的能力边界——它最适合回答“此刻哪些SQL正在拖慢系统”或者“谁在争抢CPU/IO资源”这类实时性问题。至于还原完整的执行计划，或者精确统计某条SQL从开始到结束的总耗时，ASH就力不从心了，原因很简单：采样必然有丢失，聚合也难免有延迟。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

• V$ACTIVE_SESSION_HISTORY 视图默认只保留大约1小时的数据（具体时长受内存和_ash_size隐含参数影响），历史数据会像滚轮一样被新数据覆盖。
• 它不记录非活跃会话。比如，一条SQL已经执行完毕，正在等待客户端读取结果，这种空闲状态ASH是不会捕捉的。
• 某些执行时间短于1秒的SQL，尤其是在高并发场景下，很可能被完全漏采。

所以，千万别指望用ASH去查“昨天下午3点那条慢查询的完整绑定变量值是什么”，它压根就没存这些细节。

定位高负载SQL的三个关键过滤维度

直接去查V$ACTIVE_SESSION_HISTORY，很容易被海量的采样数据淹没，找不到重点。必须组合使用下面三个过滤条件，才能像用探照灯一样，精准锁定目标：

• 按等待事件过滤：重点关注 event 字段中那些真正的瓶颈信号，比如‘db file sequential read’（单块读）、‘log file sync’（提交等待）、‘enq: TX - row lock contention’（行锁等待）。要主动避开像‘SQL*Net message from client’这类代表空闲等待的“假热点”。
• 按时间窗口过滤：利用 sample_time 字段，通常聚焦最近10到30分钟的数据。时间拉得太长，容易跨多个采样周期，导致统计结果失真。
• 按对象或模块过滤：结合 current_obj#（可以关联DBA_OBJECTS查出具体的表名）或者 module 字段（很多应用框架会设置此值），能快速将问题定位到具体的业务模块或数据库对象上。

来看一个组合使用的示例语句：

SELECT sql_id, COUNT(*) cnt, ROUND(A VG(time_waited),2) a vg_wait_ms
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/24
  AND event LIKE 'db file%'
  AND current_obj# IN (SELECT object_id FROM dba_objects WHERE object_name = 'ORDER_DETAIL')
GROUP BY sql_id
ORDER BY cnt DESC;

为什么sql_id对不上V$SQL里的记录

这是一个让不少DBA困惑的典型现象：在ASH里看到一个频繁出现的sql_id，但回头去查V$SQL时，却发现这条SQL的EXECUTIONS显示为0、LAST_ACTIVE_TIME是很久以前，甚至根本查不到这个sql_id。

别慌，这通常意味着以下几种情况：

• 原因一：SQL已老化出共享池。V$SQL只保存当前还缓存在共享池里的SQL。而ASH的采样数据存放在独立的内存区域，它的生命周期不依赖于共享池。所以，SQL即使被从共享池里“挤”出去了，它在ASH采样期间的历史记录依然存在。
• 原因二：绑定变量窥探（Bind Peeking）引发的硬解析。当SQL使用了绑定变量，且因不同绑定值导致多次硬解析时，会生成多个子游标。ASH里记录的是实际执行的子游标sql_id，而V$SQL中对应的主游标可能已经被刷出内存了。
• 原因三：某些特殊的SQL未被持久化。比如一些PL/SQL匿名块、或者通过DBMS_SQL包动态构造执行的语句，可能不会被常规地持久化记录到V$SQL中。

遇到这种情况，正确的做法是转向查询DBA_HIST_SQLTEXT（前提是已开启AWR功能），或者尝试查询V$SQL_PLAN（如果执行计划还在内存中的话），而不是死守着V$SQL不放。

ASH分析后下一步必须做的验证动作

通过ASH分析拿到一个可疑的sql_id，这只是诊断工作的起点。如果跳过后续的验证步骤，非常容易得出错误的结论。接下来这几步，缺一不可：

• 查看真实执行计划：使用 DBMS_XPLAN.DISPLAY_ASH（12c及以上版本）或者传统的 DBMS_XPLAN.DISPLAY_CURSOR(sql_id, child_number) 来查看SQL当时的真实执行计划。关键要确认它是否走了预期的索引、有没有发生全表扫描或者嵌套循环连接导致的性能爆炸。
• 对照长时间操作视图：对比 V$SESSION_LONGOPS 视图中同一sql_id的记录，判断这个SQL是在执行一次性的长操作（比如一个大表的排序），还是在反复进行大量的短等待（比如频繁的索引分裂）。
• 检查统计信息时效性：去DBA_TABLES里检查该SQL所涉及的核心表的LAST_ANALYZED时间，看看统计信息是否已经过期。过期的统计信息会误导优化器选择错误的执行路径，而ASH只会忠实地显示等待结果，不会告诉你这个根本原因。

可以说，没有经过执行计划和统计信息状态交叉验证的ASH分析，就像医生只看体温计读数就开处方——体温数字是准确的，但发烧背后的病因，可能完全是另一回事。