印刻数据库

外观

Oracle AWR/ASH报告指标解读 ​

AWR报告关键指标 ​

数据库实例概览 ​

DB Time ​

含义：数据库实例处理用户请求所花费的总时间（以秒为单位）

计算公式：DB Time = 所有会话在数据库级别消耗的CPU时间 + 等待时间

正常范围：与Elapsed Time的比值（DB Time/Elapsed Time）应在CPU核心数的2-4倍之间

19c vs 21c差异：21c中DB Time计算更加精确，包含了更多类型的等待事件

分析方法：

  • 比值过高：数据库负载过重，需要优化
  • 比值过低：数据库资源利用率不足

Instance Efficiency Percentages ​

Buffer Nowait Ratio

含义：缓冲区立即获取成功的比例

计算公式：Buffer Nowait Ratio = (1 - (buffer waits / logical reads)) * 100

正常范围：> 99%

分析方法：

  • 低于99%：缓冲区争用严重，考虑增加SGA或优化热点块
  • 结合Buffer Hit Ratio一起分析

Buffer Hit Ratio

含义：数据块从缓冲区缓存中命中的比例

计算公式：Buffer Hit Ratio = (1 - (physical reads / logical reads)) * 100

正常范围：> 95%

分析方法：

  • 低于95%：考虑增加DB_CACHE_SIZE或优化SQL减少逻辑读
  • OLTP系统要求更高，OLAP系统可适当降低

Top 5 Timed Foreground Events ​

含义：前台会话最耗时的5个等待事件

正常范围：

  • CPU time应位列前三
  • 单个等待事件占比不应超过总等待时间的30%

19c vs 21c差异：21c新增了更多细粒度的等待事件分类

分析方法：

  • 识别主要瓶颈：如IO、锁、网络等
  • 结合Wait Classes分析整体等待模式
  • 参考对应等待事件的详细信息

SQL Statistics ​

Elapsed Time (s) ​

含义：SQL语句执行的总耗时

正常范围：根据业务需求调整，一般OLTP查询应<1秒

分析方法：

  • 排序查看最耗时SQL
  • 结合Execution Count分析平均耗时
  • 检查执行计划和统计信息

CPU Time (s) ​

含义：SQL语句消耗的CPU时间

正常范围：与Elapsed Time的比值应>50%

分析方法：

  • 比值过低：SQL存在大量等待（如IO、锁）
  • 比值过高：SQL计算密集，考虑优化算法或增加CPU资源

Buffer Gets ​

含义：SQL语句从缓冲区读取的数据块数量

正常范围：根据SQL复杂度调整，一般OLTP查询应<10,000

分析方法：

  • 结合Rows Processed分析每行的缓冲区访问效率
  • 检查是否存在全表扫描或索引失效
  • 考虑优化SQL或调整索引

Segment Statistics ​

Physical Reads ​

含义：从磁盘读取的数据块数量

分析方法：

  • 排序查看物理读最多的段
  • 考虑为这些段创建或优化索引
  • 检查是否存在全表扫描

Buffer Busy Waits ​

含义：段级别的缓冲区忙等待次数

分析方法：

  • 识别热点段
  • 考虑分区、增加 freelists 或使用 ASSM
  • 优化并发访问模式

ASH报告关键指标 ​

ASH报告概览 ​

Sample Count ​

含义：ASH采样的总次数

分析方法：

  • 采样数越多，报告越准确
  • 结合Elapsed Time计算采样频率

Top Events by Wait Time ​

含义：按等待时间排序的前N个等待事件

分析方法：

  • 与AWR的Top 5 Timed Events对比，确认是否为持续性问题
  • 查看事件的详细信息，包括等待的对象和会话

Top SQL by Event ​

含义：按特定等待事件排序的SQL语句

分析方法：

  • 识别导致特定等待的SQL
  • 结合SQL的执行计划和统计信息分析
  • 考虑优化SQL或调整相关资源

Top Sessions ​

含义：最活跃的会话列表

分析方法：

  • 查看会话的等待事件和SQL语句
  • 检查会话的资源使用情况
  • 考虑是否存在异常会话或应用问题

Top Blocks ​

含义：被频繁访问的热点数据块

分析方法：

  • 识别热点块对应的表和索引
  • 考虑分区、增加 freelists 或使用 ASSM
  • 优化并发访问模式

指标分析最佳实践 ​

综合分析方法 ​

  1. 从整体到局部：先查看DB Time、Instance Efficiency，再深入到具体等待事件和SQL
  2. 对比历史报告：与基线报告对比，识别性能变化趋势
  3. 结合多份报告：AWR提供长期趋势，ASH提供实时快照，结合使用效果更佳
  4. 参考系统配置：将指标与系统硬件配置（CPU核心数、内存大小、存储类型）结合分析

常见性能问题识别 ​

CPU瓶颈 ​

识别特征：

  • CPU time位列Top 5 Timed Events首位
  • DB Time/Elapsed Time > CPU核心数*4
  • 大量SQL的CPU Time/Elapsed Time > 80%

解决方法：

  • 优化高CPU消耗的SQL
  • 考虑增加CPU资源
  • 调整并行度设置

IO瓶颈 ​

识别特征：

  • 大量IO相关等待事件（如db file sequential read、db file scattered read）
  • Physical Reads/Executions 过高
  • 磁盘IO利用率超过80%

解决方法：

  • 优化SQL减少物理读
  • 创建或优化索引
  • 考虑使用更快的存储设备
  • 调整存储参数（如DB_FILE_MULTIBLOCK_READ_COUNT）

锁瓶颈 ​

识别特征：

  • 大量锁相关等待事件（如enqueue、row lock contention）
  • ASH报告中显示大量会话等待锁
  • 存在长时间运行的事务

解决方法：

  • 优化事务逻辑，减少锁持有时间
  • 调整隔离级别
  • 检查是否存在死锁
  • 考虑使用乐观锁替代悲观锁

阈值设置建议 ​

核心指标阈值 ​

指标警告阈值严重阈值备注
DB Time/Elapsed Time> CPU核心数*3> CPU核心数*5考虑系统负载和业务需求
Buffer Hit Ratio< 95%< 90%OLTP系统要求更高
Library Cache Hit Ratio< 95%< 90%检查共享池配置和SQL绑定变量使用
Redo Log Buffer Space Wait> 0.1%> 1%考虑增加LOG_BUFFER或调整归档频率
Enqueue Waits> 0.5%> 2%检查锁争用情况

等待事件阈值 ​

等待事件警告阈值严重阈值备注
db file sequential read> 10ms> 50ms随机读延迟
db file scattered read> 20ms> 100ms顺序读延迟
log file sync> 50ms> 200ms提交延迟
latch free> 10ms> 50msLatch争用
enqueue> 100ms> 500ms锁等待

版本差异注意事项 ​

Oracle 19c ​

  • AWR报告默认保留8天
  • ASH采样间隔默认为1秒
  • 支持自动基线模板
  • 提供SQL计划管理功能

Oracle 21c ​

  • AWR报告默认保留14天
  • ASH采样间隔可调整为更细粒度（如0.1秒）
  • 新增了更多细粒度的等待事件
  • 提供实时SQL监控增强功能
  • 支持AWR报告的HTML5格式

常见问题（FAQ） ​

Q: AWR报告中的DB Time为什么会大于Elapsed Time？ ​

A: 因为DB Time是所有会话的累积时间，当存在多个并发会话时，DB Time会超过Elapsed Time。例如，在一个4核心CPU的系统上，10个并发会话运行1秒，DB Time会是10秒，而Elapsed Time是1秒。

Q: 如何判断一个SQL语句是否需要优化？ ​

A: 可以从以下几个方面判断：

  • 高Elapsed Time或CPU Time
  • 高Buffer Gets或Physical Reads
  • 低Execution Plan Cardinality Accuracy
  • 全表扫描或索引失效
  • 大量等待事件

Q: ASH报告和AWR报告有什么区别？ ​

A: AWR报告提供的是长期（默认1小时）的性能统计，而ASH报告提供的是实时（默认1秒采样）的会话活动快照。AWR适合分析长期性能趋势，ASH适合诊断实时性能问题。

Q: 如何设置AWR报告的保留时间？ ​

A: 可以使用以下命令调整AWR报告的保留时间：

sql
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => 43200); -- 保留30天（分钟）

Q: 如何解读"Buffer Busy Waits"等待事件？ ​

A: 这个等待事件表示会话等待访问一个被其他会话占用的缓冲区。可能的原因包括：

  • 热点块：多个会话同时访问同一个数据块
  • 缓冲区不足：需要等待缓冲区被释放
  • 并发控制：如 freelist 争用

解决方法包括：

  • 分区表或索引，分散热点
  • 使用自动段空间管理（ASSM）
  • 增加DB_CACHE_SIZE
  • 优化SQL减少对热点块的访问

Q: 如何识别和优化高CPU消耗的SQL？ ​

A: 可以通过以下步骤识别和优化：

  1. 在AWR报告中查看Top SQL by CPU Time
  2. 分析这些SQL的执行计划
  3. 检查是否存在：
    • 不必要的函数调用
    • 低效的连接操作
    • 不合理的并行度设置
    • 缺少索引导致的全表扫描
  4. 优化SQL或调整相关参数

Q: 如何监控AWR报告的生成情况？ ​

A: 可以使用以下SQL查询AWR快照的生成情况：

sql
SELECT * FROM DBA_HIST_SNAPSHOT ORDER BY SNAP_ID DESC;

如果快照生成异常，可以检查MMON进程状态或手动生成快照：

sql
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

总结 ​

AWR和ASH报告是Oracle数据库性能监控和优化的重要工具。通过深入理解和分析报告中的关键指标，可以快速识别数据库性能瓶颈，采取有效的优化措施。在实际运维中，建议结合系统配置、业务需求和历史数据进行综合分析，制定合理的性能优化策略。同时，注意不同Oracle版本之间的指标差异，选择适合当前版本的优化方法。