Oracle ASH 报告分析

ASH 报告简介

ASH（Active Session History）是 Oracle 数据库的活动会话历史功能，它会以秒为单位采样收集活动会话的详细信息，并存储在内存和 AWR 仓库中。ASH 报告提供了实时的数据库性能视图，是 DBA 进行实时性能监控和问题诊断的重要工具。

ASH 报告的主要特点

实时性：提供近实时的数据库性能数据
细粒度：以秒为单位采样，捕捉短期性能问题
详细信息：记录活动会话的等待事件、SQL 语句、绑定变量等详细信息
内存存储：采样数据首先存储在内存中，然后定期刷新到 AWR
关联分析：可以与 AWR 报告结合使用，提供更全面的性能分析

ASH 报告与 AWR 报告的区别

特性	ASH 报告	AWR 报告
数据粒度	秒级	分钟级
数据存储	主要在内存，部分在 AWR	存储在 AWR 仓库
分析范围	短期性能问题	长期性能趋势
详细程度	非常详细，包含会话级信息	汇总信息，统计级别
生成速度	快速	相对较慢
适用场景	实时监控、短期问题诊断	性能趋势分析、长期问题诊断

生成 ASH 报告

使用 ashrpt.sql 脚本

sql

-- 在 SQL*Plus 中执行
@$ORACLE_HOME/rdbms/admin/ashrpt.sql

-- 按提示输入：
-- 1. 报告格式（html 或 text）
-- 2. 开始时间（例如：10:00:00）
-- 3. 结束时间（例如：10:30:00）
-- 4. 报告文件名

使用 ashrpti.sql 脚本（指定实例）

sql

-- 在 RAC 环境中指定实例生成报告
@$ORACLE_HOME/rdbms/admin/ashrpti.sql

-- 按提示输入：
-- 1. 报告格式
-- 2. 数据库 ID
-- 3. 实例 ID
-- 4. 开始时间
-- 5. 结束时间
-- 6. 报告文件名

使用 Enterprise Manager

登录 Oracle Enterprise Manager
导航到 "性能" → "性能报告"
选择 "ASH 报告"
设置时间范围和其他参数
点击 "生成报告"

使用 DBMS_WORKLOAD_REPOSITORY 包

sql

-- 查看 ASH 数据
SELECT sample_id, sample_time, session_id, session_serial#, 
       sql_id, wait_class, event
FROM v$active_session_history
ORDER BY sample_time DESC;

-- 从 AWR 中查看 ASH 数据
SELECT sample_id, sample_time, session_id, session_serial#, 
       sql_id, wait_class, event
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN SYSDATE-1/24 AND SYSDATE
ORDER BY sample_time DESC;

ASH 报告分析方法

1. 报告头部信息分析

关注要点：

报告时间范围
数据库版本和实例信息
采样时间间隔
活动会话数量

分析技巧：

确认报告覆盖了性能问题发生的时间段
注意活动会话数量的变化，判断负载程度

2. 等待事件分析

关注区域：

Top User Events：用户会话的主要等待事件
Top Background Events：后台进程的主要等待事件
Wait Events by Time：按时间排序的等待事件
Wait Events by Count：按发生次数排序的等待事件

分析技巧：

首先关注排名靠前的等待事件
分析等待事件的类型和原因
结合其他部分的信息进行综合判断

3. SQL 语句分析

关注区域：

Top SQL by Elapsed Time：按执行时间排序的 SQL
Top SQL by CPU Time：按 CPU 时间排序的 SQL
Top SQL by User I/O Wait Time：按用户 I/O 等待时间排序的 SQL
Top SQL by Application Wait Time：按应用等待时间排序的 SQL
Top SQL by Cluster Wait Time：按集群等待时间排序的 SQL
Top SQL by Concurrency Wait Time：按并发等待时间排序的 SQL

分析技巧：

重点关注消耗资源最多的 SQL 语句
分析 SQL 语句的执行计划
检查 SQL 语句的绑定变量值
结合等待事件分析 SQL 性能问题

4. 会话分析

关注区域：

Top Sessions：消耗资源最多的会话
Sessions by Wait Class：按等待类分类的会话
Session Details：会话详细信息

分析技巧：

识别消耗资源最多的会话
分析会话的等待模式
检查会话的 SQL 语句和执行计划
确定是否存在异常会话

5. 服务和模块分析

关注区域：

Top Services：按资源消耗排序的服务
Top Modules：按资源消耗排序的模块
Top Actions：按资源消耗排序的操作

分析技巧：

识别消耗资源最多的服务和模块
分析不同服务和模块的性能特征
确定是否存在特定服务或模块的性能问题

6. 时间模型分析

关注区域：

DB Time Breakdown：数据库时间分解
Foreground vs Background：前台进程 vs 后台进程

分析技巧：

分析数据库时间的分布情况
确定主要的时间消耗来源
评估前台进程和后台进程的资源消耗比例

7. 阻塞分析

关注区域：

Blockers：阻塞会话信息
Blocked Sessions：被阻塞会话信息

分析技巧：

识别阻塞源和被阻塞的会话
分析阻塞的原因和持续时间
采取措施解除阻塞

8. PL/SQL 分析

关注区域：

Top PL/SQL by Elapsed Time：按执行时间排序的 PL/SQL 程序
Top PL/SQL by CPU Time：按 CPU 时间排序的 PL/SQL 程序

分析技巧：

识别消耗资源最多的 PL/SQL 程序
分析 PL/SQL 程序的性能问题
优化 PL/SQL 代码

ASH 报告分析实例

分析步骤

生成 ASH 报告：在性能问题发生时生成报告
分析等待事件：识别主要性能瓶颈
分析 SQL 语句：找出消耗资源最多的 SQL
分析会话信息：识别异常会话
综合分析：结合所有信息进行综合判断
制定优化方案：根据分析结果制定优化策略

案例分析

场景：数据库突然响应缓慢，用户无法正常操作

ASH 报告分析：

等待事件分析：
- Top 1: enqueue (Wait Time: 65%)
- Top 2: db file sequential read (Wait Time: 20%)
- Top 3: buffer busy waits (Wait Time: 10%)
SQL 语句分析：
- 发现一个 UPDATE 语句消耗了 70% 的 elapsed time
- 该 SQL 正在更新一个大型表，没有使用索引
会话分析：
- 发现会话 ID 123 正在执行上述 UPDATE 语句
- 该会话阻塞了 15 个其他会话
阻塞分析：
- 会话 123 持有排他锁
- 被阻塞的会话正在等待该锁释放

优化方案：

终止会话 123 的长时间运行的 UPDATE 语句
为 UPDATE 语句的 WHERE 条件添加合适的索引
考虑分批更新大型表，避免长时间持有锁
监控类似的长时间运行的语句

ASH 报告的高级使用

1. 实时 ASH 分析

使用 V$ACTIVE_SESSION_HISTORY 视图：

sql

-- 实时查看活动会话
SELECT sample_time, session_id, session_serial#, 
       sql_id, wait_class, event, 
       current_obj#
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/1440  -- 最近 1 分钟
ORDER BY sample_time DESC;

-- 查看等待事件分布
SELECT wait_class, event, COUNT(*)
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/1440
GROUP BY wait_class, event
ORDER BY COUNT(*) DESC;

-- 查看消耗 CPU 最多的 SQL
SELECT sql_id, COUNT(*)
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/1440
  AND wait_class = 'CPU'
GROUP BY sql_id
ORDER BY COUNT(*) DESC;

2. ASH 数据挖掘

使用 DBA_HIST_ACTIVE_SESS_HISTORY 视图：

sql

-- 查看历史 ASH 数据
SELECT sample_time, session_id, session_serial#, 
       sql_id, wait_class, event
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN SYSDATE-1 AND SYSDATE
  AND wait_class NOT IN ('Idle')
ORDER BY sample_time DESC;

-- 分析特定时间段的性能问题
SELECT wait_class, event, COUNT(*)
FROM dba_hist_active_sess_history
WHERE sample_time BETWEEN TO_DATE('2026-01-28 10:00:00', 'YYYY-MM-DD HH24:MI:SS') 
                      AND TO_DATE('2026-01-28 10:30:00', 'YYYY-MM-DD HH24:MI:SS')
  AND wait_class NOT IN ('Idle')
GROUP BY wait_class, event
ORDER BY COUNT(*) DESC;

-- 分析特定 SQL 的性能
SELECT sample_time, wait_class, event, 
       current_obj#, blocking_session
FROM dba_hist_active_sess_history
WHERE sql_id = 'abc123'
  AND sample_time BETWEEN SYSDATE-1 AND SYSDATE
ORDER BY sample_time;

3. ASH 报告与其他工具结合使用

与 ADDM 结合：

ADDM 会自动分析 ASH 数据并提供优化建议
优先考虑 ADDM 建议的优化措施

与 SQL Tuning Advisor 结合：

对于 ASH 报告中识别的高消耗 SQL，使用 SQL Tuning Advisor 进行优化
SQL Tuning Advisor 会分析 SQL 语句并提供具体的优化建议

与 AWR 报告结合：

使用 ASH 报告分析短期性能问题
使用 AWR 报告分析长期性能趋势
结合两者提供更全面的性能分析

4. 自定义 ASH 报告

使用 DBMS_WORKLOAD_REPOSITORY 包：

sql

-- 创建自定义 ASH 报告
EXEC DBMS_WORKLOAD_REPOSITORY.create_ash_report(
  begin_time => SYSDATE - 1/24,
  end_time => SYSDATE,
  report_type => 'HTML',
  report_name => 'custom_ash_report.html'
);

-- 查看自定义报告
SELECT DBMS_WORKLOAD_REPOSITORY.get_ash_report(
  begin_time => SYSDATE - 1/24,
  end_time => SYSDATE,
  report_type => 'TEXT'
) FROM dual;

使用 SQL 生成自定义分析：

sql

-- 生成等待事件热力图数据
SELECT TO_CHAR(sample_time, 'HH24:MI') AS time_slot,
       wait_class,
       COUNT(*) AS wait_count
FROM v$active_session_history
WHERE sample_time > SYSDATE - 2/24  -- 最近 2 小时
  AND wait_class NOT IN ('Idle')
GROUP BY TO_CHAR(sample_time, 'HH24:MI'), wait_class
ORDER BY time_slot, wait_count DESC;

-- 生成 SQL 性能趋势
SELECT TO_CHAR(sample_time, 'HH24:MI') AS time_slot,
       sql_id,
       COUNT(*) AS sample_count
FROM v$active_session_history
WHERE sample_time > SYSDATE - 1/24
  AND sql_id IS NOT NULL
GROUP BY TO_CHAR(sample_time, 'HH24:MI'), sql_id
ORDER BY time_slot, sample_count DESC;

ASH 报告优化策略

1. 实时性能监控

设置自动 ASH 报告：定期生成 ASH 报告，监控性能变化
使用 Enterprise Manager：利用 EM 的实时监控功能
创建自定义监控脚本：基于 V$ACTIVE_SESSION_HISTORY 视图创建监控脚本
设置性能告警：当特定等待事件超过阈值时触发告警

2. 快速问题诊断

及时生成 ASH 报告：在性能问题发生时立即生成报告
分析等待事件：快速识别主要性能瓶颈
定位问题会话：使用 ASH 数据定位问题会话
分析 SQL 语句：找出消耗资源最多的 SQL

3. SQL 优化

识别问题 SQL：通过 ASH 报告识别高消耗 SQL
分析执行计划：查看 SQL 的执行计划
使用绑定变量：减少硬解析
添加索引：为高频查询添加合适的索引
重写 SQL 语句：优化复杂 SQL 的结构

4. 资源管理

识别资源瓶颈：通过 ASH 报告识别 CPU、I/O、内存等资源瓶颈
调整资源分配：根据 ASH 分析结果调整资源分配
优化内存使用：分析内存相关的等待事件，调整内存参数
优化 I/O 性能：分析 I/O 相关的等待事件，优化存储配置

5. 并发控制

识别锁争用：通过 ASH 报告识别锁争用问题
分析阻塞链：找出阻塞源和被阻塞的会话
优化事务设计：减少事务长度，避免长时间持有锁
使用适当的隔离级别：根据业务需求选择合适的事务隔离级别

6. 系统调优

分析系统级等待事件：如 log file sync、buffer busy waits 等
调整系统参数：根据 ASH 分析结果调整系统参数
优化存储配置：改善 I/O 性能
调整并行度：根据 ASH 数据调整并行执行参数

常见问题（FAQ）

Q1: ASH 报告中的数据保留多长时间？

A1: ASH 数据的保留时间取决于以下因素：

内存中的 ASH 数据：通常保留约 1 小时，具体取决于数据库活动和内存大小
AWR 中的 ASH 数据：与 AWR 数据的保留时间相同，默认为 7 天
可以通过修改 AWR 保留时间来调整：使用 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS 过程

Q2: 如何确定 ASH 报告的时间范围？

A2: 确定 ASH 报告时间范围的方法：

问题发生时间：确保报告覆盖性能问题发生的时间段
时间长度：一般选择 5-30 分钟的时间段，太短可能无法捕捉到问题，太长可能包含过多无关信息
采样密度：ASH 报告的时间范围越短，数据越详细

Q3: 如何分析 ASH 报告中的 "enqueue" 等待事件？

A3: 分析 "enqueue" 等待事件的方法：

确定锁类型：查看等待事件的详细信息，确定锁的类型
查找阻塞源：在阻塞分析部分查找阻塞会话
分析 SQL 语句：查看阻塞会话正在执行的 SQL 语句
采取措施：根据具体情况，可能需要终止阻塞会话或优化 SQL 语句

Q4: 如何使用 ASH 报告识别 CPU 瓶颈？

A4: 识别 CPU 瓶颈的方法：

查看等待事件：CPU 瓶颈通常表现为 "CPU time" 或 "busy CPU" 等待
分析 SQL 语句：查看消耗 CPU 最多的 SQL 语句
检查会话：查看消耗 CPU 最多的会话
分析 PL/SQL：检查消耗 CPU 最多的 PL/SQL 程序

Q5: ASH 报告中的 "buffer busy waits" 等待事件如何解决？

A5: 解决 "buffer busy waits" 等待事件的方法：

原因分析：
- 热点块竞争
- 段头竞争
- 回滚段竞争
解决方法：
- 对于热点块：使用更小的块大小，或考虑分区
- 对于段头竞争：增加 FREELISTS 和 FREELIST GROUPS
- 对于回滚段竞争：确保有足够的回滚段
- 使用自动段空间管理（ASSM）

Q6: 如何使用 ASH 报告监控数据库的实时性能？

A6: 监控实时性能的方法：

定期生成 ASH 报告：例如每 15 分钟生成一次
使用实时 ASH 视图：查询 V$ACTIVE_SESSION_HISTORY 视图
创建监控脚本：基于 ASH 数据创建自定义监控脚本
设置性能告警：当特定指标超过阈值时触发告警

Q7: 如何分析 ASH 报告中的 "db file sequential read" 等待事件？

A7: 分析 "db file sequential read" 等待事件的方法：

原因分析：
- 索引扫描
- 回滚段读取
- 数据字典读取
解决方法：
- 检查索引使用情况，确保使用了合适的索引
- 优化 SQL 语句，减少索引扫描的范围
- 考虑使用索引组织表（IOT）
- 检查存储性能，确保 I/O 子系统性能良好

Q8: 如何使用 ASH 报告评估优化措施的效果？

A8: 评估优化措施效果的方法：

生成优化前后的 ASH 报告：在相同的负载条件下生成报告
比较关键指标：
- 等待事件分布的变化
- 高消耗 SQL 的性能变化
- 会话等待时间的变化
- 资源使用率的变化
分析趋势：观察优化措施实施后的性能趋势
综合评估：结合业务指标（如响应时间、吞吐量）进行综合评估

Oracle ASH 报告分析 ​

ASH 报告简介 ​

ASH 报告的主要特点 ​

ASH 报告与 AWR 报告的区别 ​

生成 ASH 报告 ​

使用 ashrpt.sql 脚本 ​

使用 ashrpti.sql 脚本（指定实例） ​

使用 Enterprise Manager ​

使用 DBMS_WORKLOAD_REPOSITORY 包 ​

ASH 报告分析方法 ​

1. 报告头部信息分析 ​

2. 等待事件分析 ​

3. SQL 语句分析 ​

4. 会话分析 ​

5. 服务和模块分析 ​

6. 时间模型分析 ​

7. 阻塞分析 ​

8. PL/SQL 分析 ​

ASH 报告分析实例 ​

分析步骤 ​

案例分析 ​

ASH 报告的高级使用 ​

1. 实时 ASH 分析 ​

2. ASH 数据挖掘 ​

3. ASH 报告与其他工具结合使用 ​

4. 自定义 ASH 报告 ​

ASH 报告优化策略 ​

1. 实时性能监控 ​

2. 快速问题诊断 ​

3. SQL 优化 ​

4. 资源管理 ​

5. 并发控制 ​

6. 系统调优 ​

常见问题（FAQ） ​

Q1: ASH 报告中的数据保留多长时间？ ​

Q2: 如何确定 ASH 报告的时间范围？ ​

Q3: 如何分析 ASH 报告中的 "enqueue" 等待事件？ ​

Q4: 如何使用 ASH 报告识别 CPU 瓶颈？ ​

Q5: ASH 报告中的 "buffer busy waits" 等待事件如何解决？ ​

Q6: 如何使用 ASH 报告监控数据库的实时性能？ ​

Q7: 如何分析 ASH 报告中的 "db file sequential read" 等待事件？ ​

Q8: 如何使用 ASH 报告评估优化措施的效果？ ​

Oracle ASH 报告分析

ASH 报告简介

ASH 报告的主要特点

ASH 报告与 AWR 报告的区别

生成 ASH 报告

使用 ashrpt.sql 脚本

使用 ashrpti.sql 脚本（指定实例）

使用 Enterprise Manager

使用 DBMS_WORKLOAD_REPOSITORY 包

ASH 报告分析方法

1. 报告头部信息分析

2. 等待事件分析

3. SQL 语句分析

4. 会话分析

5. 服务和模块分析

6. 时间模型分析

7. 阻塞分析

8. PL/SQL 分析

ASH 报告分析实例

分析步骤

案例分析

ASH 报告的高级使用

1. 实时 ASH 分析

2. ASH 数据挖掘

3. ASH 报告与其他工具结合使用

4. 自定义 ASH 报告

ASH 报告优化策略

1. 实时性能监控

2. 快速问题诊断

3. SQL 优化

4. 资源管理

5. 并发控制

6. 系统调优

常见问题（FAQ）

Q1: ASH 报告中的数据保留多长时间？

Q2: 如何确定 ASH 报告的时间范围？

Q3: 如何分析 ASH 报告中的 "enqueue" 等待事件？

Q4: 如何使用 ASH 报告识别 CPU 瓶颈？

Q5: ASH 报告中的 "buffer busy waits" 等待事件如何解决？

Q6: 如何使用 ASH 报告监控数据库的实时性能？

Q7: 如何分析 ASH 报告中的 "db file sequential read" 等待事件？

Q8: 如何使用 ASH 报告评估优化措施的效果？