目录
Oracle ASH (Active Session History) 报告是诊断瞬时性能问题的利器。它能以每秒一次的频率采样活动会话，精准捕捉那些在AWR报告中容易被“平均掉”的短暂性能瓶颈。
🔍 Oracle ASH报告深度解析
1️⃣ ASH核心机制与价值
ASH的核心价值在于其高粒度的采样机制（默认每秒一次）和对活动会话（ACTIVE Session）的聚焦，使其成为分析持续时间仅几分钟甚至几秒的瞬时性能问题的首选工具。它由后台进程MMNL (Memory Monitor Light) 执行，采样数据首先存储在SGA的循环缓冲区（V$ACTIVE_SESSION_HISTORY）中，并定期持久化到AWR表（WRH$_ACTIVE_SESSION_HISTORY）中。
ASH与AWR的关系：
| 特性 | AWR | ASH |
|---|---|---|
| 数据粒度 | 快照间隔（通常1小时） | 每秒采样 |
| 关注点 | 系统整体性能、历史趋势、平均值 | 活动会话的实时等待、瞬时事件、特定会话行为 |
| 主要用途 | 长期性能趋势分析、容量规划、周期性瓶颈定位 | 诊断短时、突发性性能问题（如锁阻塞、瞬时高负载）、细化分析AWR发现的问题 |
| 数据保留 | 默认8天 | 内存中约1小时，磁盘上部分持久化（默认1/10采样） |
| 报告间隔 | 通常30分钟至数小时 | 通常5-15分钟（针对问题时段） |
| 问题捕获 | 可能平均掉短暂问题 | 专为捕获瞬时问题设计 |
2️⃣ 生成ASH报告
生成ASH报告的主要方式是通过SQL脚本ashrpt.sql（或RAC环境下的ashrpti.sql）。
-- 通过SQL*Plus连接数据库后执行
SQL> @?/rdbms/admin/ashrpt.sql
随后根据提示选择输出格式（通常选择HTML以获得更佳的阅读体验）、输入分析的时间范围（精确到分钟甚至秒）和报告文件名。
3️⃣ ASH报告核心章节详解
一份完整的ASH报告包含多个章节，以下是需要重点关注的部份。
3.1 Top Events（顶级等待事件）
这是分析性能瓶颈的起点，它按等待时间排序，显示了采样期间最主要的等待事件。
-
诊断要点：
- 通常，单个事件占比超过30% 就需要优先关注和处理。
CPU + Wait for CPU事件排名靠前，通常意味着系统正在消耗大量CPU资源，可能需要优化高负载SQL或检查系统资源。- 常见的等待事件及其指向：
等待事件 (Wait Event) 潜在问题方向 下一步分析动作 enq: TX - row lock contention行级锁争用 查看 Blocking Sessions定位阻塞源log file syncLGWR写入重做日志文件慢 检查重做日志所在磁盘的I/O性能 db file sequential read索引扫描相关的单块读I/O慢 检查磁盘I/O延迟，优化高物理读SQL db file scattered read全表扫描相关的多块读I/O慢 检查磁盘I/O延迟，优化SQL减少全表扫描 buffer busy waits缓冲区忙等待（热点块） 识别被频繁访问的段（Segment） gc buffer busy(RAC)全局缓存争用 检查跨实例访问，优化SQL减少跨节点交互
3.2 Load Profile（负载概要）
此部分提供了采样期间系统负载的宏观视图，帮助理解压力类型。
- 关键指标：
- Activity (%) per Second / per Transaction。
- Top Service/Module: 识别哪个服务或应用模块是负载的主要来源。例如，如果某个特定模块（如
SQL*Plus或某个应用服务）消耗了超过50%的活动，调查就应聚焦于此。 - Top SQL Command Types: 了解主导操作是
SELECT还是DML（如UPDATE,INSERT）。
3.3 Top SQL with Top Events（关联了顶级事件的SQL）
这是连接SQL语句与系统等待事件的桥梁，是定位问题SQL的关键。
- 诊断要点：
- 关注
% Activity列。通常，占比超过5%的SQL就需要优先分析。 - 结合
Event列，看该SQL主要在等待什么资源（如db file sequential read），这直接指明了优化方向。 SQL ID是下一步深入分析（如查看执行计划）的钥匙。Executions高可能意味着频繁执行的小事务，而Buffer Gets高则可能意味着单条SQL效率低下。
- 关注
3.4 Top Sessions（顶级会话）
显示在采样期内最活跃的会话。
- 诊断要点：
- 识别消耗资源最多的会话（
SID,SERIAL#）。 - 结合
# Samples Active列，判断会话的活跃程度。 - 此部分有助于将问题具体到某个应用连接。
- 识别消耗资源最多的会话（
3.5 Top Blocking Sessions（顶级阻塞会话）
诊断锁争用（如enq: TX - row lock contention）的核心区域。
- 诊断要点：
- 直接定位阻塞源会话（
BLOCKING_SESSION）及其正在执行的SQL（SQL_ID）。 - 这是解决行锁阻塞问题的最快捷途径，可以迅速找到“罪魁祸首”。
- 直接定位阻塞源会话（
3.6 Activity Over Time（随时间变化的活动）
将整个分析时段划分为10个等分的时间槽（Time Slot），展示活动会话数和等待事件随时间的变化趋势。
- 诊断要点：
- 识别负载尖峰（Spike）：某个时间槽的
Slot Count（采样会话数）和Event Count（等待事件数）突然激增，表明该时段发生了瞬时问题。 - 关联分析：将负载尖峰与对应时段内出现的顶级SQL和等待事件关联起来，可以精准定位问题原因。
- 识别负载尖峰（Spike）：某个时间槽的
4️⃣ ASH报告分析流程：四步诊断法
基于ASH报告的特性，我推荐以下四步分析法：
-
定位核心瓶颈：
首先查看Top Events，识别占比超过30%的关键等待事件，确定系统级瓶颈类型（是CPU、I/O还是锁）。 -
关联资源消耗：
进入Top SQL with Top Events，找到那些高% Activity（如>5%）且与顶级等待事件关联的SQL语句。这些SQL是导致瓶颈的直接原因。 -
追溯阻塞链（如适用）：
如果主要等待事件是锁争用（如enq: TX - row lock contention），立即查看Top Blocking Sessions部分，定位阻塞源头会话和SQL，这是解决问题的关键。 -
时段负载分析：
最后，使用Activity Over Time图表验证问题发生的精确时间点，并观察负载模式。这有助于确认根本原因，并了解问题是瞬时突发还是持续存在。
5️⃣ 常见性能问题排查速查表
| 现象（ASH报告中的表现） | 可能原因 | 验证与解决方案 |
|---|---|---|
enq: TX - row lock contention 占比高 |
行锁争用（多个会话修改同一行、位图索引更新、唯一键冲突） | 1. 使用Blocking Sessions找到阻塞源。2. 优化应用逻辑，避免长事务，及时提交。 3. 考虑细化事务粒度。 |
CPU + Wait for CPU 占比高 |
高CPU消耗（大量逻辑读、低效SQL、频繁解析） | 1. 查看Top SQL中高% Activity和高Buffer Gets的SQL。2. 优化SQL执行计划（添加索引、重写SQL）。 3. 检查并绑定变量以减少硬解析。 |
db file sequential read 占比高 |
索引读取I/O慢或SQL效率低导致大量索引访问 | 1. 检查存储I/O延迟和性能。 2. 优化相关SQL，减少逻辑读。 3. 确保 DB_CACHE_SIZE大小合适。 |
log file sync 等待显著 |
重做日志文件写入慢 | 1. 检查重做日志所在磁盘的I/O性能。 2. 考虑使用更快的磁盘或分离I/O。 3. 评估应用提交频率是否过高。 |
gc buffer busy (RAC环境) |
全局缓存争用，热点块跨实例访问 | 1. 优化SQL，减少跨实例交互。 2. 考虑使用数据库驻留连接池(DRCP)或调整服务分配。 3. 检查并优化可能导致全表扫描的SQL。 |
6️⃣ ASH最佳实践与注意事项
-
采样时机与间隔：
- 分析瞬时问题时，报告间隔应精确覆盖问题发生时段，通常5-15分钟为宜。
- 进行趋势分析时，可适当延长至30-60分钟。
- 高并发环境下，ASH内存缓冲区可能被快速覆盖，需及时捕获数据。
-
关联分析：
- 瞬时问题：ASH + SQL Monitor（用于分析单条SQL的详细执行情况）。
- 历史趋势：ASH + AWR（先AWR定位大致时段，再ASH深入分析）。
- RAC环境：务必使用
ashrpti.sql生成全局ASH报告，分析跨实例的等待事件。
-
数据保留策略：
默认ASH磁盘数据保留时间可能与AWR快照保留策略一致（如8天），但可以通过以下命令修改（单位：分钟）：EXEC DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(retention => 12960); -- 延长至9天
掌握ASH报告的分析，意味着你拥有了在分钟甚至秒级别上洞察数据库活动的能力。结合AWR提供的宏观趋势，你就能构建起从宏观到微观的完整性能诊断体系，精准、高效地解决各类数据库性能难题。
