Oracle AWR 报告指标全解析：深入理解数据库性能优化的关键

一、引言

在 Oracle 数据库管理与性能优化领域，AWR（Automatic Workload Repository）报告扮演着极为重要的角色。它犹如一位精准的诊断专家，能够对数据库的运行状况进行全面、细致的剖析，为数据库管理员（DBA）提供丰富且关键的信息，助力其深入洞察数据库的性能表现，精准定位潜在问题，并制定出切实有效的优化策略。本文将深入且系统地对 Oracle AWR 报告中的各项指标展开详细解析，旨在帮助读者全面掌握这些指标的内涵、相互关系以及在数据库性能优化过程中的实际应用。

二、AWR 基础概述

（一）AWR 与 SYSAUX 表空间
AWR 和 SYSAUX 均是在 Oracle 10g 版本中引入的重要特性，它们紧密协作，共同为数据库性能调优提供坚实支持。AWR 所收集的大量历史性能数据就存储在 SYSAUX 表空间之上。这些数据涵盖了数据库运行过程中的诸多关键信息，犹如一座数据宝库，为后续的性能分析提供了丰富的素材。

（二）快照间隔与保存时长
默认情况下，AWR 快照的间隔设定为 1 小时。在不同的 Oracle 版本中，快照的保存时长有所差异，10g 版本保存 7 天，而 11g 版本则延长至 8 天。这些快照犹如数据库在不同时间点的“快照照片”，通过对比不同时间点的快照，能够清晰地捕捉到数据库性能的变化趋势。

（三）AWR 程序核心
AWR 程序的核心是 dbms_workload_repository 包。在本实例中，可通过 @?/rdbms/admin/awrrpt 来调用相关功能；在 RAC（Real Application Clusters）环境中，则需使用 @?/rdbms/admin/awrrpti 并选择相应的实例号。这一核心包犹如 AWR 的“大脑中枢”，掌控着数据的收集、存储与报告生成等关键操作。

（四）维护者：MMON 及其小工进程
负责维护 AWR 的主要是 MMON（Manageability Monitor Process）及其小工进程（m00x）。MMON 承担着多项重要职责：

1. 它能够启动 slave 进程 m00x 去执行 AWR 快照的采集工作，确保数据的及时获取与更新。
2. 当某个度量阈值被超越时，MMON 会迅速发出 alert 告警，如同数据库的“预警哨兵”，及时提醒管理员关注潜在的性能风险。
3. 它还会为最近发生改变的 SQL 对象捕获相关指标信息，为深入分析 SQL 语句的性能变化提供有力依据。

（五）手动操作

1. 手动执行一个快照可使用如下语句：Exec dbms_workload_repository.create_snapshot; 这一操作在特定场景下，如需要立即获取当前数据库状态数据时非常有用。
2. 创建一个 AWR 基线可通过：Exec DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id，end_snap_id,baseline_name); 基线的创建有助于在性能对比分析中确定一个稳定的参考标准，以便更准确地评估数据库性能的变化。

三、AWR 报告主要部分解析

（一）报告总结

1. 基本信息
   • 报告首先呈现出数据库的基本概况，包括 DB Name（数据库名称）、DB Id（数据库标识符）、Instance（实例名）、Inst num（实例编号）、Startup Time（启动时间）、Release（数据库版本）以及是否为 RAC 环境等关键信息。例如，在示例中展示的数据库相关信息能够让管理员快速确定所分析的数据库对象的基本属性。
   • 同时还会给出 Host Name（主机名）、Platform（操作系统平台）、CPUs（CPU 数量）、Cores（CPU 核心数）、Sockets（CPU 插槽数）以及 Memory (GB)（内存大小）等硬件资源信息，这些信息对于理解数据库运行的硬件环境以及评估资源是否充足具有重要意义。
2. 快照信息
   • Snap Id（快照编号）、Snap Time（快照时间）、Sessions（会话数）、Cursors/Session（每个会话的游标数）等信息展示了不同快照点的数据库会话相关状态。其中，Elapsed（时间跨度）表示该 AWR 性能报告所涵盖的自然时间长度，例如从一个快照生成时间到另一个快照生成时间的间隔。DB Time（数据库时间）则是所有前台 session 花费在 database 调用上的总和时间，它是衡量数据库总体负载的一个关键指标，但需要注意的是，DB TIME 高并不一定意味着响应慢，低也不一定表示响应快，需要与 Elapsed Time 结合起来综合判断。例如，当 DB Time = 60min，Elapsed Time = 60min 时，Average Active Session AAS = 60/60 = 1，负载一般；若 DB Time = 1min，Elapsed Time = 60min，则 AAS = 1/60，负载很轻；而当 DB Time = 60000min，Elapsed Time = 60min 时，AAS = 1000，系统可能出现 hang 住的情况。

（二）内存参数大小

1. 缓存区大小
   • Buffer Cache（缓冲区缓存）、Shared Pool Size（共享池大小）、Log Buffer（日志缓冲区）等缓存区的大小信息在 AWR 报告中清晰可见。例如，Buffer Cache 的大小在示例中显示了其在快照开始和结束时的容量，这些缓存区的大小设置直接影响数据库的性能。合理设置 Buffer Cache 大小能够减少物理读，提高数据读取效率；Shared Pool Size 的合理配置则与 SQL 语句的解析和执行密切相关；Log Buffer 的大小会影响日志写入的性能，过小可能导致频繁的日志切换等问题。

（三）Load Profile（负载概况）

1. 指标含义
   • redo size（重做日志大小）：单位为 bytes，它可用于估量 update/insert/delete 的频率。较大的 redo size 往往会对 lgwr 写日志和 arch 归档造成 I/O 压力。例如，在一个 OLTP 系统中，如果 redo size 过大，可能意味着有大量的数据修改操作，需要关注存储的 I/O 性能是否能够承受。Per Transaction（每个事务）这一维度可以用来分辨事务的类型，是大量小事务还是少量大事务。如每秒 redo 约 1MB，每个事务 800 字节，符合 OLTP 特征。
   • Logical Read（逻辑读）：单位为（次数*块数），逻辑读会消耗 CPU 资源，主频和 CPU 核数对其性能有重要影响。逻辑读高则 DB CPU 往往也高，并且可能会出现 latch: cache buffer chains 等待事件。例如，在一个查询频繁的应用中，如果逻辑读过高，可能需要优化查询语句或者调整缓存区大小以减少逻辑读操作。
   • Block changes（数据块变化）：单位为（次数*块数），它描绘了数据变化的频率，能够反映出数据库中数据更新的活跃程度。
   • Physical Read（物理读）：单位为（次数*块数），物理读消耗 IO 读资源，体现在 IOPS（每秒输入/输出操作数）和吞吐量等不同维度上。减少物理读可能意味着需要消耗更多 CPU 资源，例如通过增大缓存区来减少物理读，但这可能会增加内存管理的开销。好的存储每秒物理读能力能够达到几 GB，如 Exadata。这里的 physical read 包含了 physical reads cache 和 physical reads direct。
   • Physical writes（物理写）：单位为（次数*块数），主要是 DBWR 写 datafile，也有 direct path write。dbwr 长期写出慢会导致定期 log file switch(checkpoint no complete)检查点无法完成的前台等待。这个 physical write 包含了 physical writes direct + physical writes from cache。
   • User Calls（用户调用数）：单位次数，反映了用户对数据库的操作请求数量。
   • Parses（解析次数）：包括软解析和硬解析，软解析优化得不好，则可能几乎等于每秒 SQL 执行次数，理想情况是解析一次到处运行，减少不必要的解析开销。
   • Hard Parses（硬解析）：被视为“万恶之源”，因为它会消耗更多的 CPU 时间片并产生解析争用，如 Cursor pin s on X，library cache: mutex X，latch: row cache objects shared pool 等问题都可能与硬解析相关。硬解析最好少于每秒 20 次。
   • W/A MB processed（工作区处理数据量）：单位 MB，结合 In - memory Sort%可进一步分析内存排序的情况。
   • Logons（登陆次数）：结合 AUDIT 审计数据一起看，能够了解数据库的用户登录情况。
   • Executes（执行次数）：反应 SQL 语句的执行频率，对于评估数据库的繁忙程度有重要参考价值。
   • Rollbacks（回滚次数）：反应回滚频率，但这个指标不太精确，不过较高的回滚次数可能暗示着事务处理过程中存在问题，如数据不一致或者业务逻辑错误等。
   • Transactions（每秒事务数）：是数据库层的 TPS（每秒事务处理量），可作为压力测试或比对性能时的一个重要指标，但孤立看无意义，需要结合其他指标综合评估数据库的性能。
   • % Blocks changed per Read（每次逻辑读导致数据块变化的比率）：如果’redo size’，‘block changes’‘pct of blocks changed per read’三个指标都很高，则说明系统正执行大量 insert/update/delete 操作。
   • Recursive Call %（递归调用的比率）：Recursive Call%=(recursive calls)/(user calls)，递归调用的比例过高可能暗示着数据库内部存在一些复杂的操作或者函数调用导致额外的开销。
   • Rollback per transaction %（事务回滚比率）：Rollback per transaction %=(rollback)/(transactions)，较高的事务回滚比率需要深入分析事务处理过程中的问题根源。
   • Rows per Sort（平均每次排序涉及到的行数）：Rows per Sort=(sorts(rows))/(sorts(disk)+sorts(memory))，这一指标对于评估排序操作的效率和资源消耗有一定帮助。
2. 维度分析
   • Load Profile 负载指标提供了 per second（每秒）和 per transaction（每个事务）两个维度。per Second 主要是把快照内的时间值除以快照时间的秒数，例如对于 table scans (long tables) 这一指标，如果在 A 快照中 V$SYSSTAT 视图反应其值为 100，在 B 快照中为 3700，而 A 快照和 B 快照之间间隔了一个小时（3600 秒），则对于 table scans (long tables) per second 就是(3700 - 100)/3600 = 1。per transaction 则是基于事务的维度，与 per second 相比是把除数从时间的秒数改为了该段时间内的事务数。这个维度的很大用户是用来识别应用特性的变化。若两个 AWR 性能报告中该维度指标出现了大幅变化，例如 redo size 从本来 per transaction 1k 变化为 10k per transaction，则说明 SQL 业务逻辑肯定发生了某些变化。

（四）Instance Efficiency Percentages（实例效率百分比）

1. 目标与指标含义
   • 所有指标的目标均为 100%，越大越好。
   • Buffer Nowait %（缓冲区无等待百分比）：session 申请一个 buffer（兼容模式）不等待的次数比例，即需要访问 buffer 时立即可以访问的比率，反映了缓冲区获取的效率。
   • buffer HIT%（缓冲区命中率）：高速缓存命中率，反应物理读和缓存命中间的纠结。需要注意的是，即便该指标达到 99%，也不能说明物理读等待就少了。不合理的 db_cache_size，或者在 SGA 自动管理（ASMM）或 AMM（Automatic Memory Management）下因 db_cache_size 过小都可能引起大量的 db file sequential scattered read 等待事件。此外，与 buffer HIT%相关的指标还有 table scans(long tables)大表扫描、Buffer Pool Statistics、Buffer Pool Advisory 等，这些指标相互关联，共同影响数据库的读取性能。
   • Redo nowait%（重做日志无等待百分比）：session 在生成 redo entry 时不用等待的比例，redo 相关的资源争用例如 redo space request 争用可能造成生成 redo 时需求等待。此项数据来源于 v$sysstat 中的(redo log space requests/redo entries)。一般来说 10g 以后不太用关注 log_buffer 参数的大小，但需要关注是否有十分频繁的 log switch；过小的 redo logfile size 如果配合较大的 SGA 和频繁的 commit 提交都可能造成该问题，可考虑增大 redo logfile 的尺寸，如 1 - 2G 每个，10 - 15 组都是合适的，同时优化 redo logfile 和 datafile 的 I/O。
   • In - memory Sort%（内存排序百分比）：这个指标因为它不计算 workarea 中所有的操作类型，纯粹在内存中完成的排序比例，较高的内存排序比例有助于提高排序操作的效率，减少磁盘 I/O 开销。
   • Library Hit%（库缓存命中率）：申请一个 library cache object 例如一个 SQL cursor 时，其已经在 library cache 中的比例，合理值应大于 95%。较高的库缓存命中率意味着 SQL 语句的重用性较好，减少了解析和编译的开销。
   • Soft Parse（软解析比例）：经典指标，合理值>95%。Soft Parse %是 AWR 中另一个重要的解析指标，该指标反应了快照时间内软解析次数和总解析次数（soft + hard 软解析次数 + 硬解析次数）的比值，若该指标很低，那么说明了可能存在剧烈的 hard parse 硬解析，大量的硬解析会消耗更多的 CPU 时间片并产生解析争用，此时可考虑使用 cursor_sharing = FORCE 等措施来优化解析过程。理论上我们总是希望 Soft Parse %接近于 100%，但并不是说 100%的软解析就是最理想的解析状态，通过设置 session_cached_cursors 参数和反复重用游标我们可以让解析来的更轻量级，即通俗所说的利用会话缓存游标实现的软软解析(soft soft parse)。
   • Execute to Parse%（执行解析比）：指标反映了执行解析比，其公式为 1-(parse/execute)，目标为 100%及接近于只执行而不解析。在 Oracle 中解析往往是执行的先提工作，但是通过游标共享可以解析一次执行多次。不同的执行解析场景会导致该指标的不同结果，如 hard coding（代码硬解析一次，执行一次，理论上其执行解析比为 1:1，则理论上 Execute to Parse = 0 极差，且 soft parse 比例也为 0%）；绑定变量但是仍软解析（软解析一次，执行一次，这种情况虽然比前一种好，但是执行解析比仍是 1:1，理论上 Execute to Parse = 0 极差，但是 soft parse 比例可能很高）；使用静态 SQL、动态绑定、session_cached_cursor、open cursors 等技术实现的解析一次，执行多次，执行解析比为 N:1，则 Execute to Parse = 1-(1/N)，执行次数越多 Execute to Parse 越接近 100%，这种是我们在 OLTP 环境中希望看到的。通俗地说 soft parse%反映了软解析率，而软解析在 Oracle 中仍是较昂贵的操作，我们希望的是解析 1 次执行 N 次，如果每次执行均需要软解析，那么虽然 soft parse% = 100%但是 parse time 仍可能是消耗 DB TIME 的大头。Execute to Parse 反映了执行解析比，Execute to Parse 和 soft parse%都很低那么说明确实没有绑定变量，而如果 soft parse%接近 99%而 Execute to Parse 不足 90%则说明没有执行解析比低，需要通过静态 SQL、动态绑定、session_cached_cursor、open cursors 等技术减少软解析。
   • Latch Hit%（闩命中率）：willing - to - wait latch 闩申请不要等待的比例，对于高并发的 latch 例如 cache buffers chains，其 Pct Misses 应当十分接近于 0。一般的调优原则是，如果 latch: cache buffers chains 是 Top 5 事件，则需要考虑优化 SQL 减少全表扫描并减少 Top buffer gets SQL 语句的逻辑读；如果 latch: redo copy、redo allocation 等待较多，则可以考虑增大 LOG_BUFFER；如果 latch:library cache 发生较多，则考虑增大 shared_pool_size。

（五）Top 10 Foreground Events by Total Wait Time（按总等待时间排名的前 10 个前台事件）

1. 事件信息
   • 该部分详细列出了等待事件的相关信息，包括 Waits（等待事件发生的次数）、Total Wait Time (sec)（该等待事件消耗的总计时间，单位为秒）、Wait Avg(ms)（该等待事件平均等待的时间，实际就是 Times/Waits，单位 ms）、% DB time（该等待事件占 DB 时间的百分比）、Wait Class（等待类型）。常见的等待类型有 Concurrency（并发）、SystemI/O（系统 I/O）、UserI/O（用户 I/O）、Administrative（管理）、Other（其他）、Configuration（配置）、Scheduler（调度）、Cluster（集群）、Application（应用）、Idle（空闲）、Network（网络）、Commit（提交）等。
2. 常见等待事件分析
   • db file scattered read：Avg wait time 应当小于 20ms，如果数据库执行全表扫描或者是全索引扫描会执行 Multi block I/O，此时等待物理 I/O 结束会出现此等待事件。一般从应用程序(SQL）、I/O 方面

欢迎关注公众号《小周的数据库进阶之路》，更多精彩知识和干货尽在其中。