Oracle AWR报告深度解析-时间模型与等待事件 (Time Model and Wait Events)

原创二两烧麦 2025-09-04

205

1. 时间模型基础

数据库性能本质上是时间的消耗。Oracle使用两个核心公式来量化这一点：

响应时间公式：Response Time = Service Time + Wait Time
- Service Time（服务时间）：指进程在CPU上真正执行任务的时间，对应AWR报告中的 DB CPU。这是数据库有效工作的部分。
- Wait Time（等待时间）：指进程等待各种资源的时间，例如等待磁盘I/O、锁存器(latch)、锁(lock)等。这部分时间是开销，越少越好。
DB Time：这是AWR报告中一个极为重要的概念。
- 定义：DB Time = CPU Time + Wait Time（不含空闲等待）。它表示所有用户进程花费在数据库调用上的总时间（CPU时间加上非空闲等待时间）。
- 解读：DB Time 是衡量数据库整体负载和压力的关键指标。
  - 如果 DB Time 远大于 Elapsed Time（AWR快照实际时间间隔），说明数据库在此期间非常繁忙。
  - 如果 DB Time 很小，说明数据库负载较轻。

理解这些概念是分析等待事件的基础。

2. Top 5 Timed Foreground Events

这是AWR报告中最需要关注的部分，它直接显示了系统最主要的时间消耗在哪里。

等待事件 (Wait Event)	含义与可能原因	优化方向
`DB CPU`	数据库进程消耗的CPU时间。一个健康的系统，它通常应位于前5甚至第一位。如果占比过高，说明系统可能是CPU密集型，需要优化高消耗的SQL。	优化高逻辑读、高CPU消耗的SQL语句（如未用索引、复杂计算）。
`db file sequential read`	通常与索引扫描相关，表示等待从数据文件读取单个块。常见于索引访问、回表操作。	检查磁盘I/O性能（如I/O延迟是否过高），考虑优化SQL（减少逻辑读），增大 `db_cache_size`。
`db file scattered read`	通常与全表扫描（FTS）相关，表示等待从数据文件多块读（一次I/O读取多个块）。	检查磁盘I/O性能，优化SQL（是否缺少索引？），考虑增大 `db_cache_size`。
`log file sync`	当用户提交（COMMIT）事务时，等待LGWR进程将重做日志缓冲区内容写入磁盘。	检查重做日志文件所在磁盘的I/O性能（这是最常见原因），评估应用提交频率是否过高。
`enq: TX - row lock contention`	行级锁争用。一个会话正在等待另一个会话释放它持有的行级锁。	检查应用逻辑，优化事务设计（避免长事务，及时提交），查找并处理阻塞源。
`latch: cache buffers chains`	缓存缓冲区链latch争用。高逻辑读的SQL语句访问相同的数据块时容易引发此争用。	优化高逻辑读的SQL（减少访问块数），解决热点块问题。
`buffer busy waits`	缓冲区忙等待。多个会话想要同时访问或修改同一个数据块。	识别热点块或段，考虑使用自由列表（freelist）或ASSM管理段空间。

分析要点：

% DB Time：该等待事件占总数据库时间的百分比。通常，单个事件占比超过30%就需要优先关注。
Wait Time (s)：该事件的总等待时间（秒）。
Avg Wait (ms)：每次等待的平均时间。对于I/O类事件（如 db file sequential read），平均等待时间通常不应超过10-20毫秒，否则可能表明存储子系统存在瓶颈。

3. 时间模型统计 (Time Model Statistics)

这部分提供了更详细的时间分解，帮助你回答“时间到底花在了哪些操作上”这样的问题。

统计项 (Statistic Name)	含义与解读
`DB CPU`	所有前台和后台进程消耗的CPU时间总和。
`sql execute elapsed time`	SQL语句执行所花费的总时间。在正常系统中，这个比率应该较高（如90%以上）。
`parse time elapsed`	SQL解析所占用的总时间。如果过高，说明解析开销大。
`hard parse elapsed time`	硬解析所占用的时间。硬解析需要完全编译SQL，消耗大量CPU和共享池latch，应尽可能避免。理想情况下，硬解析应非常少。
`PL/SQL execution elapsed time`	执行PL/SQL代码所花费的时间。
`connection management call elapsed time`	管理数据库连接（建立和断开）所花费的时间。如果过高，可能意味着连接池配置不当或应用频繁创建关闭连接。

分析要点：

比较各项时间占总 DB Time 的比例，找出时间消耗的主要操作类型。
如果 parse time elapsed（特别是 hard parse elapsed time）占比过高，需要检查绑定变量的使用和共享池的大小。
如果 connection management call elapsed time 占比过高，应检查应用层的连接管理策略（如是否使用了连接池）。

4. 等待事件与SQL关联

AWR报告的强大之处在于它能将等待事件与具体的SQL语句关联起来。

SQL ordered by Elapsed Time：按总耗时（CPU时间+等待时间）排序的SQL。
SQL ordered by CPU Time：按消耗CPU时间排序的SQL。通常伴随高逻辑读。
SQL ordered by Gets：按逻辑读（Buffer Gets）排序的SQL。逻辑读是CPU消耗的主要来源。
SQL ordered by Reads：按物理读（Disk Reads）排序的SQL。直接反映磁盘I/O。
SQL ordered by Executions：按执行次数排序的SQL。即使单条很快，海量执行也可能成为负担。

分析要点：

从 Top 5 Timed Events 确定主要等待类型（例如，主要是 db file sequential read）。
去相应的SQL列表（例如，SQL ordered by Gets 或 SQL ordered by Elapsed Time）中找到那些消耗高且与主要等待事件相关的SQL。
这些SQL就是需要优先优化的对象。

5. 综合分析建议

确立基线：在系统性能良好时创建AWR基线，为后续异常时期的对比分析提供参照。
分析流程：
- 看头尾：先看报告头部的 DB Time/Elapsed Time 比率确认负载压力，再看尾部的 Top 5 Wait Events 确认主要瓶颈类型。
- 由宏观到微观：分析 Load Profile -> 分析 Instance Efficiency -> 锁定 Top 5 Wait Events -> 深入到 SQL Statistics 找到具体SQL。
- 对比历史：与历史同时间段或性能正常时段的AWR报告进行对比，观察指标变化趋势。
常见优化动作：
- 高CPU时间：优化高逻辑读的SQL（添加索引、重写SQL）。
- 高物理读/低Buffer Hit：优化高逻辑读的SQL（根源），考虑增大缓冲区缓存 (db_cache_size)。
- 高硬解析：强制使用绑定变量（cursor_sharing=FORCE），调整应用代码，增大共享池 (shared_pool_size)。
- log file sync等待：优化重做日志文件的I/O（使用更快磁盘、分离I/O），评估提交频率。
- 行锁争用：优化应用逻辑，避免长事务和频繁访问热点行。

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者

Oracle AWR报告深度解析-时间模型与等待事件 (Time Model and Wait Events)

目录

1. 时间模型基础

2. Top 5 Timed Foreground Events

3. 时间模型统计 (Time Model Statistics)

4. 等待事件与SQL关联

5. 综合分析建议

评论