Oracle数据库并发性能差？通过ASH分析Session活跃度
来源：互联网 2026-05-02 11:36:17ASH视图查不到最近的活跃会话？检查采样是否启用且时间窗口够用 遇到性能问题，第一时间去查v$active_session_history（ASH），结果却空空如也？这事儿挺常见，但别急着下结论。Oracle的ASH机制默认是每秒采样一次活跃会话，听起来频率不低，对吧？但关键在于，这些采样数据在内存
ASH视图查不到最近的活跃会话？检查采样是否启用且时间窗口够用
遇到性能问题，第一时间去查v$active_session_history（ASH），结果却空空如也？这事儿挺常见，但别急着下结论。Oracle的ASH机制默认是每秒采样一次活跃会话，听起来频率不低，对吧？但关键在于，这些采样数据在内存里只保留大约一小时，具体时长取决于隐含参数_ash_size和系统当时的负载压力。至于更久远的数据，则依赖于AWR快照，默认每小时归档一次到dba_hist_active_sess_history。所以，如果你刚发现系统卡顿就立刻去查v$ash却一无所获，大概率是这两种情况：要么采样还没来得及“抓拍”到那个瞬间，要么会话已经结束、相关的采样数据已经被新的数据覆盖了。
那该怎么办呢？几个实操建议帮你快速定位：
长期稳定更新的攒劲资源： >>>点此立即查看<<<
- 缩小时间范围：立即排查时，优先查询
V$ACTIVE_SESSION_HISTORY，并加上时间过滤条件，比如WHERE sample_time > SYSDATE - 1/1440，这能帮你聚焦过去一分钟内的数据，避免在大量历史数据中大海捞针。 - 确认AWR状态：执行
SELECT dbid, name, startup_time FROM v$database;，并检查dba_hist_snapshot视图中是否有近期的记录，确保AWR快照功能是正常启用的。 - 调整内存保留量：如果需要更细粒度的历史分析，可以考虑临时增加ASH在内存中的保留量。注意，这通常需要修改SPFILE并重启实例，例如：
ALTER SYSTEM SET "_ash_size"=524288000 SCOPE=SPFILE;（设置为500MB）。 - 注意数据盲区：有一个关键细节容易被忽略：
V$ASH视图不包含那些会话状态为ON CPU但等待事件为NULL的会话。这类会话往往正在进行硬解析或递归SQL调用，同样是性能瓶颈的潜在来源。要捕捉它们，得结合V$SESSION和V$SQL视图进行交叉验证。
查出大量enq: TX - row lock contention但找不到阻塞源？重点看blocking_session和final_blocking_session
在ASH报告里看到一堆enq: TX - row lock contention（行锁等待），是不是就觉得找到罪魁祸首了？别急，这很可能只是故事的开始，而不是结局。ASH采样的是会话“正在等待”的那个瞬间，而那个持有锁的“元凶”会话，可能在你采样之前就已经提交或回滚了，或者它持有锁的时间非常短（短于1秒），根本就没被ASH捕获到。
所以，光看等待事件是不够的，必须深挖关联关系。具体可以这么做：
- 锁定关键字段：查询时，不要只筛选
event字段。务必同时查询session_id（被阻塞会话）、blocking_session（直接阻塞者）以及final_blocking_session（最终阻塞者，12c及以上版本稳定可用）这三列。 - 执行排查语句：尝试运行如下查询：
SELECT session_id, blocking_session, final_blocking_session, sql_id, event, p1text, p1 FROM v$active_session_history WHERE event = 'enq: TX - row lock contention' AND sample_time > SYSDATE - 1/720 ORDER BY sample_time DESC;这能帮你按时间倒序列出最近的行锁等待。 - 理解级联阻塞：如果发现
blocking_session为空，但final_blocking_session却有值，这说明存在级联阻塞链（例如A阻塞B，B又阻塞C）。这时，你需要顺着final_blocking_session这个线索，去V$SESSION视图里查看该最终阻塞会话的当前状态。 - 警惕DDL操作：另外要注意，有些行锁等待是由DDL语句隐式触发的（比如
ALTER TABLE ... MOVE）。在这种情况下，ASH中的sql_id可能为NULL。此时就需要结合machine（客户端机器）和program（客户端程序）字段，人工排查是哪个应用模块发起的操作。
ASH显示大量cursor: pin S wait on X？不是SQL写法问题，而是Library Cache争用
看到cursor: pin S wait on X这个等待事件，很多人的第一反应是：“是不是SQL没用绑定变量？” 其实，这是一个常见的误解。这个事件的本质，是多个会话试图同时获取同一个游标句柄的共享锁（S锁），但这个游标正被另一个会话以排他模式（X锁）修改——比如正在进行硬解析、刷新执行计划，或者刷新结果集缓存。它反映的是Library Cache（库缓存）层面的闩锁（Latch）或互斥量（Mutex）争用，根源不在于SQL语句本身的效率，而在于共享池的管理和游标生命周期。
遇到这种情况，可以按以下步骤排查：
- 确认硬解析：首先，检查系统是否真的存在大量硬解析。可以查询
V$SQL视图，看是否有SQL的parse_calls（解析调用次数）远大于executions（执行次数）；或者查看V$SYSSTAT中的parse count (hard)统计项是否在短期内急剧增长。 - 检查共享池操作：排查是否有频繁的
DBMS_SHARED_POOL.PURGE或ALTER SYSTEM FLUSH SHARED_POOL这类操作。这些操作会强制清空或失效大量游标，导致后续会话不得不重新进行硬解析，从而引发集中的库缓存争用。 - 评估游标共享设置：如果应用使用了大量动态SQL，并且数据库参数
cursor_sharing被设置为FORCE，有时反而会加剧Mutex争用。在12c及以后的版本中，更推荐的做法是设置cursor_sharing=EXACT，同时推动应用层彻底使用绑定变量。 - 治标与治本：作为紧急缓解措施，可以考虑调整隐含参数如
_kks_use_mutex_pin（11gR2后默认已是TRUE），但这只是权宜之计。根本的解决之道，还是在于减少不必要的游标失效，并从根本上避免无谓的硬解析。
用ASH聚合分析Top SQL时，为什么sql_id统计不准？别忽略in_connection_mgmt和in_parse状态
用ASH数据按sql_id来聚合排序，找出消耗资源最多的Top SQL，这是性能分析的常规操作。但这个方法有个盲区：它会漏掉两类不关联sql_id、却可能消耗大量时间的关键活动。一类是连接建立和断开的过程（比如使用DRCP连接池时的会话切换），另一类是SQL文本的解析阶段（注意，是解析而非执行）。在ASH中，这些活动的sql_id字段为NULL，但其session_state可能显示为IN CONNECTION MANAGEMENT或IN PARSE。别小看它们，在实际系统中，这类开销有时能占到总响应时间的30%以上。
为了让Top SQL分析更全面，建议补充以下步骤：
- 补充状态分析：在执行常规的Top SQL查询前或后，先运行这样一条语句：
SELECT session_state, event, COUNT(*) FROM v$active_session_history WHERE sample_time > SYSDATE - 1/24 GROUP BY session_state, event ORDER BY 3 DESC;这能帮你了解在连接管理和解析阶段，会话主要的时间花在了哪里。 - 解析慢的排查：如果发现大量
IN PARSE状态且event为空，说明SQL文本解析本身就很慢。需要检查是否启用了已废弃的参数如cursor_space_for_time=TRUE，或者是否存在体积异常庞大（例如超过10MB）的SQL文本。 - 连接管理的优化：如果
IN CONNECTION MANAGEMENT状态占比很高，并且program字段显示多为oracle@... (J000)这类作业进程，那很可能是数据库调度作业（如DBMS_SCHEDULER）在密集地创建和断开连接。优化方向是引入连接池，或者调整这些作业的并发度和调度策略。 - 注意执行计划差异：最后提醒一点，相同的
sql_id并不意味着每次执行都使用相同的执行计划。不同的绑定变量值可能会触发不同的执行计划（即不同的plan_hash_value）。因此，在按sql_id聚合后，最好再结合plan_hash_value进行二次分组，才能更精确地定位问题。
总而言之，ASH是实时性能诊断的一把利器，但它提供的是“快照”，而非连续的“录像”。真正的挑战往往不在于查出“哪个SQL在等待”，而在于理解“它为什么偏偏在这个时间点、以这种方式等待”。这要求我们把ASH的数据与V$SESSION、V$LOCK、V$SQL_PLAN，乃至操作系统层面的top命令输出串联起来，进行立体化的分析。特别是当等待事件集中在latch: shared pool或library cache: mutex X这类底层资源争用时，单靠ASH的字段很难定位到根本原因，必须深入到V$LATCH_CHILDREN或V$MUTEX_SLEEP等更底层的视图中去挖掘线索。
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
