上一期生成了ASH报告后，就需要解读报告关键信息。ASH的使用可以快速定位瞬时性能问题。生产环境的场景时间紧、任务重，但是必须要结合具体业务分析，同时借助其他工具做报告做趋势分析。
一、ASH 技术原理
1. 核心机制
- 采样原理：ASH 每秒采样一次活动会话（状态为 ACTIVE，非空闲等待），由后台进程 MMNL（Memory Monitor Light）执行
- 数据存储：
- 内存：采样数据存储在 SGA 的循环缓冲区（V$ACTIVE_SESSION_HISTORY），缓冲区大小由隐含参数 _ash_size 控制（默认约 1MB~30MB）
- 持久化：MMNL 定期将内存数据写入 AWR 表 WRH$_ACTIVE_SESSION_HISTORY（视图为 DBA_HIST_ACTIVE_SESS_HISTORY），持久化比例由 _ash_disk_filter_ratio 控制（默认 1/10）
2. 核心术语
| 术语 | 解释 | 分析意义 |
| DB Time | 所有活动会话消耗的总时间（CPU + 等待时间） | 衡量系统负载强度，高 DB Time 表明性能瓶颈 |
| Top Events | 排名前几的等待事件（如db file sequential read, enq: TX - row lock contention） | 定位系统级瓶颈（事件占比 >30% 需优先处理） |
| Load Profile | 活动会话数、逻辑读/秒、物理读/秒等负载指标 | 判断资源压力（如物理读 >500/秒需优化 I/O） |
| SQL ID | 消耗资源最多的 SQL 唯一标识 | 关联高负载 SQL 与等待事件 |
| Blocking Session | 阻塞其他会话的源头会话 ID | 诊断锁争用问题（如行锁阻塞链） |
3. 关键隐含参数
| 参数名 | 默认值 | 作用 |
| _ash_sampling_interval | 1000ms | 采样间隔（毫秒） |
| _ash_enable | TRUE | 启用/禁用 ASH 采样 |
| _ash_sample_all | FALSE | 是否采样空闲等待会话（通常仅ACTIVE会话） |
| _ash_disk_write_enable | TRUE | 控制是否持久化到磁盘 |
4. 顶级等待事件（Top User Events）
识别系统级瓶颈的核心区域
- 单事件占比 > 30%：需要立即处理
- 累计等待时间 > 50%：系统级瓶颈
5. 高负载SQL（Top SQL with Top Events）
| 字段 | 诊断意义 | 优化阈值 |
| SQL ID | SQL唯一标识 | - |
| % Activity | SQL影响范围 | >5%需优先优化 |
| Executions | 执行频率 | >100/分钟需关注 |
| Buffer Gets | 逻辑读消耗 | 单次>10,000需优化 |
| Scan Type | 扫描方式 | FTS(全表扫描)需建索引 |
| 关联等待事件 | SQL瓶颈类型 | 关联Top Events分析 |
- 高频全表扫描 → 创建缺失索引
- 高逻辑读SQL → SQL重写/绑定变量
- 长时锁等待SQL → 业务逻辑优化
6. 活动会话时间分布（Activity Over Time）
- 时段突增：关联具体SQL/事件（如时段3的db file sequential read）
- 持续高峰：系统容量不足
- 周期性波动：定时任务影响
7. 阻塞会话分析（Blocking Sessions）
- BLOCKING_SESSION：阻塞源会话ID
- WAIT_TIME：等待时间（>1秒需关注）
- EVENT：等待事件类型
- SQL_ID：阻塞源SQL
二、ASH报告诊断四步法
分析流程
定位核心瓶颈：
- 查看 Top Events，筛选占比 >30% 的等待事件（如行锁、I/O 等待）
- 检查 Load Profile 中的活动会话数：若持续超过 CPU 核数 × 1.5，表明资源争用
关联资源消耗：
- 在 Top SQL with Top Events 中，找到高 % Activity（>5%）的 SQL，分析其执行计划与资源消耗
- 示例 SQL（查找高逻辑读 SQL）：
--注意参数 SELECT sql_id, SUM(buffer_gets) total_gets FROM dba_hist_active_sess_history WHERE sample_time BETWEEN :start AND :end GROUP BY sql_id ORDER BY total_gets DESC;
追溯阻塞链：
- 通过 Blocking Sessions 定位锁源头会话，结合 DBA_HIST_ACTIVE_SESS_HISTORY 分析锁类型（如 enq: TX - row lock contention）
时段负载分析：
- 使用 Activity Over Time 图表定位突增时段（如 10:05-10:08），关联该时段内的 SQL 与事件
三、关键性能问题速查表
| 现象 | 可能原因 | 验证方法 |
| log file sync > 30% | redo写入延迟 | 检查redo日志文件性能 |
| enq: TX - row lock contention | 行锁争用 | 分析阻塞会话链 |
| db file sequential read | 索引扫描I/O慢 | 检查磁盘IOPS/延迟 |
| buffer busy waits | 热块争用 | 检查对象访问模式 |
| CPU used when call started | SQL效率低下 | 分析Top SQL逻辑读 |
四、案例解析
案例 1：Oracle 11g 行锁阻塞（enq: TX - row lock contention）
- 问题现象：ASH 报告中 enq: TX - row lock contention 占比 87.62%
- 在 Top Events 中确认行锁为顶级事件。
- 通过关联的 SQL_ID 找到UPDATE 卡事务的 SQL：
--更新业务侧，等待很久 UPDATE HIS.FEI_ACCOUNT SET SHYUEDU = SHYUEDU - 1000 WHERE HUANGZHE_ID = 9028;
- 溯源 BLOCKING_SESSION，发现未提交的事务持有行锁
- 解决方案：
- 优化事务提交逻辑，避免长事务。
- 添加索引减少行锁竞争范围
案例 2：Oracle 19c RAC 全局 I/O 瓶颈
- 问题现象：gc buffer busy 和 db file sequential read 等待事件在多个实例同时出现。
- 分析过程：
- a.RAC ASH 报告显示跨实例的高 gc buffer busy。
- 关联 SQL 发现全表扫描频繁，导致全局缓存争用。
- 检查 Buffer Activity 部分，Consistent Gets 异常高
- 解决方案：
- 为高频查询字段添加索引，减少全表扫描。
- 调整 db_cache_size 和 inmemory_size，优化缓冲区命中率
案例 3：短时 CPU 高负载（11g 单机）
- 问题现象：用户反馈系统在 14:00-14:05 卡顿，但 AWR 未捕获异常。
- 分析过程：
- 生成精确时段的 ASH 报告（14:00-14:05）。
- 发现 CPU used when call started 占比 95%，关联 SQL 为低效聚合查询。
- 该 SQL 执行计划使用全表扫描而非索引
- 解决方案：
- 优化 SQL，添加复合索引。
- 调整 cursor_sharing 减少硬解析
五、ASH 的局限和最佳实践
1. 数据覆盖风险：
- 内存缓冲区仅保留约 1 小时数据，高并发时可能被覆盖，需及时捕获
2. RAC 环境要点：
- 使用 ashrpti.sql 生成全局报告，分析跨实例等待事件（如 gc buffer busy）
ASH报告分析最佳实践
采样时间选择：
- 问题发生期精确分析：5-15分钟
- 趋势分析：30-60分钟
对比分析：
-- 比如工作日 vs 周末，注意时间参数
SELECT event, COUNT(*)
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN <高负载期间> AND <低负载期间>
GROUP BY event;关联工具使用：
- 瞬时问题：ASH + SQL Monitor
- 历史分析：ASH + AWR
- 实时监控：ASH + OEM
保存策略优化：
-- 延长ASH保留时间（单位：分钟）
EXEC DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(retention => 4320 -- 3天保留期（默认=4320分钟）
);
)
