47-Oracle ASH报告解读

上一期生成了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）

​采样偏差​：ASH 偏向捕获长时间等待事件（例如 100ms 事件被采样的概率是 10ms 事件的 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语句分析

​字段​	​诊断意义​	​优化阈值​
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）​​

10等分时间片的负载趋势分析

​诊断要点​：

• ​时段突增​：关联具体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 等待事件在多个实例同时出现。
• ​分析过程​：

1. a.RAC ASH 报告显示跨实例的高 gc buffer busy。
2. 关联 SQL 发现全表扫描频繁，导致全局缓存争用。
3. 检查 Buffer Activity 部分，Consistent Gets 异常高

• ​解决方案​：
  • 为高频查询字段添加索引，减少全表扫描。
  • 调整 db_cache_size 和 inmemory_size，优化缓冲区命中率

案例 3：短时 CPU 高负载（11g 单机）​​

• ​问题现象​：用户反馈系统在 14:00-14:05 卡顿，但 AWR 未捕获异常。
• ​分析过程​：

1. 生成精确时段的 ASH 报告（14:00-14:05）。
2. 发现 CPU used when call started 占比 95%，关联 SQL 为低效聚合查询。
3. 该 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分钟）
);