尧图网页设计 
简介这份PDF文档面向Oracle数据库管理员与运维工程师系统讲解AWRAutomatic Workload Repository报告的解读方法帮助读者从快照数据中定位数据库性能瓶颈、优化配置。内容围绕WORKLOAD REPOSITORY report展开涵盖DB Name、Snap Id、Elapsed与DB Time等关键字段含义并通过Report A与Report B的对比实例演示如何用DB Time与CPU时间比值判断系统负载还涉及AIX环境下bindprocessor查看处理器、Buffer Cache与Shared Pool等SGA区域大小分析以及Load Profile中Redo size、Logical reads、Hard parses等指标的判读要点并强调选择代表性分析时间段的重要性。资源包为1个PDF文件大小约1.18MB结构紧凑便于随时查阅。目前已有580人学习下载适合希望掌握AWR报告分析思路、提升数据库调优能力的读者参考。1. 拿到 AWR 报告先别翻 Top SQL从 DB Time 和 Elapsed 的比值读出系统真实压力很多人拿到一份 AWR 报告第一反应是直接跳到「SQL ordered by Elapsed Time」找最慢的语句然后开始加索引、改 SQL。这个顺序大概率是错的。AWR 是 Oracle 10g 引入的自动负载信息库Automatic Workload Repository它靠对比两次快照之间的统计差值生成报表本质是一份「时间都花在哪了」的账单。账单没看懂就动手等于闭着眼睛调优。这份《OracleAWR报告详细分析.pdf》的价值在于它没有停在指标定义层面而是把 Load Profile、Instance Efficiency、Top 5 Timed Events、RAC Statistics、Wait Events 这几大块串成了一条从「判断系统忙不忙」到「定位具体等待」的链路。它适合两类人一是刚接手 Oracle 运维、需要照着报告逐项读的 DBA二是遇到性能告警、想快速判断是数据库问题还是应用问题的后端工程师。核心判断逻辑其实就一句话——先看 DB Time 和 Elapsed 的比值再决定要不要往下深挖。2. 读懂负载概况DB Time、Elapsed 与 CPU 核数的三角关系2.1 DB Time 到底统计了什么DB Time 是 AWR 里最容易被误读的指标。它的定义是所有非后台进程在数据库运算和等待不含空闲等待上花费的总时间公式为 DB Time CPU Time 非空闲 Wait Time。注意两个限定词——「非后台进程」和「非空闲等待」。这意味着 DB Time 不包含 Oracle 后台进程如 DBWR、LGWR、PMON消耗的时间也不包含像sql*net message from client这类空闲等待。文档里给了一个很直观的例子79 分钟内收集了 3 次快照DB Time 只有 11 分钟而系统有 8 个逻辑 CPU。平均每个 CPU 耗时 11/8 ≈ 1.4 分钟CPU 利用率约 1.4/79 ≈ 2%。这个数字说明系统压力非常小根本不需要调优。反过来如果 DB Time 接近甚至超过 Elapsed × CPU 核数说明数据库已经把 CPU 吃满了这时候才需要认真看后面的等待事件。2.2 用 Report A 和 Report B 做对比判断负载文档里用两份报告做了对比这个对比方法值得直接抄下来用报告Elapsed (mins)DB Time (mins)CPU 核数DB Time / (Elapsed × 核数)结论Report A59.51466.378466.37 / (59.51×8) ≈ 98%CPU 几乎被 Oracle 占满Report B59.6319.49819.49 / (59.63×8) ≈ 4%平均负载很低Report A 里60 分钟窗口内 8 个核总共提供 480 分钟的 CPU 时间DB Time 466.37 分钟意味着 CPU 有 98% 的时间在处理 Oracle 的非空闲操作。Report B 只有 4%说明服务器大部分时间在闲着。这里有个关键提醒对于批量系统数据库负载往往集中在某个时间段。如果快照周期没覆盖到那段高峰或者跨度太长把大量空闲时间也包进来了算出来的比值会严重偏低分析结论就是废的。所以选分析时间段时一定要选能代表性能问题的那段窗口而不是随便挑一个整点。提示DB Time 远小于 Elapsed 不代表没问题只代表「平均下来不忙」。如果业务方反馈某个时刻卡顿你需要把快照粒度调细或者直接查那个时间段的 ASH 数据。2.3 从 Cache Sizes 和 Load Profile 看资源分配Cache Sizes 部分显示 SGA 各区域大小包括 Buffer Cache、Shared Pool Size、Log Buffer 和 Std Block Size。文档特别指出Shared Pool 里的 library cache 和 dictionary cache 发生 cache miss 的代价远高于 buffer cache所以 Shared Pool 的设置要确保最近使用的数据都能被缓存。这个判断在后续 Instance Efficiency 的 Library Hit 指标里会得到验证。Load Profile 部分按 Per Second 和 Per Transaction 两个维度列出负载指标。文档给了一组阈值参考Logons 大于每秒 1~2 个、Hard Parses 大于每秒 100、全部 Parses 超过每秒 300就可能有争用问题。Redo size 反映数据变更频率Logical reads 反映逻辑读压力Block changes 反映修改频率。这些值单独看没有「正确」答案必须和基线对比才有意义。3. 实例效率与等待事件从命中率到 Top 5 的排查路径3.1 Instance Efficiency 里的关键命中率怎么读Instance Efficiency Percentages 这一节列了一堆百分比文档明确说「没有所谓正确的值」只能根据应用特点判断。但有几个阈值是业界共识可以直接拿来用指标理想值低于阈值时的动作Buffer Nowait % 99%存在缓冲区争用查等待事件确认Buffer Hit %OLTP 95%低于 80% 考虑加内存检查 top physical reads SQLLibrary Hit % 95%考虑加大 Shared Pool、使用绑定变量Latch Hit % 99%检查 Shared Pool latch 争用可能需绑定变量或调大 Shared PoolIn-memory Sort % 95%调大 PGA_AGGREGATE_TARGET 或 SORT_AREA_SIZESoft Parse % 95%低于 80% 说明 SQL 基本没复用需绑定变量文档里有个反直觉的点值得注意Buffer Hit 高不一定代表系统好。比如大量非选择性索引被频繁访问会造成命中率很高的假象实际伴随大量db file sequential read。真正要警惕的是命中率的突变——突然增大就查 top buffer get SQL突然减小就查 top physical reads SQL。3.2 用 Top 5 Timed Events 确定下一步方向Top 5 Timed Events 是报告概要的最后一节按等待时间占比倒序列出最严重的 5 个等待。文档给了一个非常实用的排查路径如果buffer busy wait严重 → 继续看 Buffer Wait 和 File/Tablespace IO 区识别哪些文件导致问题如果 I/O 事件严重 → 看按物理读排序的 SQL识别哪些语句在大量 I/O如果 LATCH 等待高 → 看详细 LATCH 统计识别具体是哪个 latch一个性能良好的系统CPU time 应该排在 Top 5 的前面。文档里那个例子CPU time 排第一但log file parallel write占了 7%说明日志写入有一定压力。如果 CPU time 不在前面说明系统大部分时间在等待这时候就要顺着等待事件往下挖。3.3 常见等待事件的定位与处理文档对几个高频等待事件给了详细说明这里整理成可操作的排查步骤db file scattered read文件分散读取通常与全表扫描或 fast full index scan 有关。排查时结合v$session_longops看长时间运行的操作确认全表扫描是否必要。如果希望某条语句走索引可以调整optimizer_index_cost_adj默认 100理解为 FULL SCAN COST / INDEX SCAN COST。db file sequential read文件顺序读取单块读等待通常因表连接顺序糟糕或使用了非选择性索引。检查索引扫描是否必须确认多表连接的驱动行源是否正确。buffer busy wait缓冲区忙这个值不应大于 1%。排查时先查v$event_name确认参数含义——9i 的 p3 是 id10g 的 p3 是 class#。然后按等待位置分类处理-- 获取产生 buffer busy waits 的 SQL 语句 select sql_text from v$sql t1, v$session t2, v$session_wait t3 where t1.address t2.sql_address and t1.hash_value t2.sql_hash_value and t2.sid t3.sid and t3.event buffer busy waits; -- 获取等待块的类型和所在 segment select Segment Header class, a.segment_type, a.segment_name, a.partition_name from dba_segments a, v$session_wait b where a.header_file b.p1 and a.header_block b.p2 and b.event buffer busy waits union select Freelist Groups class, a.segment_type, a.segment_name, a.partition_name from dba_segments a, v$session_wait b where a.header_file b.p1 and b.p2 between a.header_block 1 and (a.header_block a.freelist_groups) and a.freelist_groups 1 and b.event buffer busy waits;第一段查询把等待事件和当前会话、SQL 文本关联起来定位到具体语句。第二段查询通过 p1文件号和 p2块号反查 segment判断等待发生在段头、freelist 组还是数据块。参数 p1、p2、p3 的含义在不同版本有差异9i 的 p3 是等待原因编号10g 变成了块类型编号这个版本差异是排查时最容易翻车的地方。如果等待在段头说明 freelist 块太少可以增加 freelist 或 freelist groups如果在 undo header增加回滚段如果在 undo block增加提交频率如果在 data block说明有热块可以增大 PCTFREE、减小块大小、优化 SQL 或增加 INITRANS通常设 5 就够每个 ITL 槽占 24 字节。4. 避坑与常见问题AWR 分析里最容易翻车的五个地方4.1 快照窗口选错分析结论全废现象报告显示系统很空闲但业务方持续反馈卡顿。原因批量系统的负载集中在特定时段如果快照周期没覆盖高峰或者跨度太长把大量空闲时间包进来DB Time / Elapsed 的比值会被严重拉低。解决先和业务确认性能问题发生的具体时间段然后用DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动创建快照或者调整快照间隔默认 60 分钟到更细的粒度。分析时只选覆盖问题时段的那对快照。4.2 把 DB Time 当成响应时间现象看到 DB Time 很大就认为系统慢看到 DB Time 小就认为没问题。原因DB Time 是累计时间不是单次请求的响应时间。它统计的是所有非后台进程在数据库上花的总时间和并发数、请求量都有关系。解决DB Time 要和 Elapsed、CPU 核数一起看算比值判断整体压力。单次请求的响应时间要看 Average Active SessionsAAS或者具体 SQL 的 Elapsed Time per Exec。4.3 硬解析阈值生搬硬套现象Hard Parses 每秒超过 100 就急着改cursor_sharing。原因文档明确说cursor_sharingsimilar存在 bug可能导致执行计划不优。而且硬解析阈值和系统类型有关DSS 系统和 OLTP 系统的标准完全不同。解决先确认 SQL 是否真的没有复用——看SQL with executions1的比例如果低于 80% 才考虑绑定变量。改cursor_sharing之前先在测试环境验证执行计划优先从应用层改 SQL 写法。4.4 忽略 RAC 相关的全局等待现象单实例分析没问题RAC 环境下性能就是上不去。原因RAC 报告里有 Global Cache Load Profile 和 Global Cache Efficiency Percentages如果Buffer access - remote cache %偏高说明实例间数据传递频繁互联网络可能成为瓶颈。解决关注Avg global cache cr block receive time和Avg global cache current block receive time如果超过 1ms 就要检查互联网络。同时看Estd Interconnect traffic评估网络带宽是否足够。4.5 用命中率高低直接判断性能好坏现象Buffer Hit 98% 就认为没问题或者低于 90% 就急着加内存。原因文档明确指出高命中率可能是假象——大量非选择性索引被频繁访问会造成命中率很高但伴随大量db file sequential read。命中率的突变比绝对值更值得关注。解决命中率要和 Top 5 Timed Events、Top SQL 一起看。如果命中率高但 I/O 等待也高说明问题不在缓存大小而在 SQL 访问路径。如果命中率突然下降查 top physical reads SQL看是否有索引被删除或执行计划突变。5. 从报告到行动把 AWR 指标转成可执行的调优清单5.1 建立基线比单次分析更重要文档反复强调一个观点单个报告的数据只说明应用的负载情况绝大多数指标没有「正确」值必须和基线对比。我一般会在系统稳定运行期采集 3~5 份 AWR 报告作为基线记录 Load Profile 和 Instance Efficiency 的关键值。之后每次出现性能问题先和基线对比看哪些指标发生了突变。突变点往往就是问题源头。比如Execute to Parse这个指标计算公式是100 * (1 - Parses/Executions)。文档例子里差不多每 5 次执行需要 1 次解析所以这个值在 80% 左右。如果基线是 90%突然掉到 50%说明解析次数暴增要么是 SQL 没复用要么是 shared pool 出了问题。如果这个值小于 0说明 Parses 大于 Executions通常意味着 shared pool 设置有问题或者语句效率极差reparse 严重。5.2 用 SQL 定位具体问题语句AWR 报告里的 Top SQL 区域按不同维度排序常用的有 Elapsed Time、CPU Time、Buffer Gets、Physical Reads。我一般按这个顺序查-- 查当前等待事件对应的 SQL实时排查用 select s.sid, s.serial#, s.username, s.sql_id, s.event, s.wait_class, s.seconds_in_wait, q.sql_text from v$session s join v$sql q on s.sql_id q.sql_id where s.status ACTIVE and s.wait_class Idle order by s.seconds_in_wait desc; -- 查历史 SQL 统计AWR 快照范围内 select sql_id, executions, elapsed_time/1000000 as elapsed_sec, cpu_time/1000000 as cpu_sec, buffer_gets, disk_reads, rows_processed, sql_text from dba_hist_sqlstat h join dba_hist_sqltext t on h.sql_id t.sql_id where h.snap_id between begin_snap and end_snap order by h.elapsed_time_delta desc fetch first 20 rows only;第一段查当前活跃会话的非空闲等待直接定位到正在拖慢系统的语句。第二段查历史快照范围内的 SQL 统计elapsed_time_delta是两次快照之间的增量比绝对值更有参考意义。buffer_gets高说明逻辑读多disk_reads高说明物理读多rows_processed和executions的比值可以看出单次执行返回多少行。5.3 共享池与解析问题的处理技巧Shared Pool Statistics 里有两个指标很关键Memory Usage %应该稳定在 75%~90%太低说明 Shared Pool 设置过大带来管理负担太高说明有争用。SQL with executions1的比例如果太小说明需要在应用中更多使用绑定变量。我处理解析问题的顺序是先看Soft Parse %低于 95% 就查SQL with executions1的比例如果这个比例也低说明 SQL 确实没复用优先从应用层改绑定变量如果应用层短期改不了再考虑session_cached_cursors参数让 fast parse 在 PGA 中命中。文档里提到 fast parse 是直接在 PGA 中命中的情况设置session_cached_cursorsn后生效。这个参数对 OLTP 系统效果明显但要注意每个 session 会占用额外 PGA 内存。5.4 一个我踩过的坑早些年我拿到一份 AWR 报告看到log file parallel write排在 Top 5 第二位占了 7% 的等待时间第一反应是把 redo log 文件挪到更快的盘上。结果折腾了半天发现真正的问题是应用端批量提交太频繁导致 LGWR 写入压力大。后来我养成一个习惯看到任何 I/O 相关等待先查Physical Writes和Redo size的 Per Second 值确认是数据库配置问题还是应用写入模式问题。如果是应用写入模式问题换再快的盘也是治标不治本。从那以后我每次分析 AWR 报告都强制走一遍「DB Time / Elapsed → Top 5 Timed Events → 对应区域的详细指标 → Top SQL」这条链路不跳步。这份《OracleAWR报告详细分析.pdf》把这条链路上的每个节点都讲到了包括 RAC 环境下的全局缓存指标和常见等待事件的参数含义适合放在手边当速查手册用。希望帮到你。本文还有配套的精品资源点击获取 Oracle AWR 报告分析实战：从 DB Time 到 Top 5 等待事件的调优链路
简介这份PDF文档面向Oracle数据库管理员与运维工程师系统讲解AWRAutomatic Workload Repository报告的解读方法帮助读者从快照数据中定位数据库性能瓶颈、优化配置。内容围绕WORKLOAD REPOSITORY report展开涵盖DB Name、Snap Id、Elapsed与DB Time等关键字段含义并通过Report A与Report B的对比实例演示如何用DB Time与CPU时间比值判断系统负载还涉及AIX环境下bindprocessor查看处理器、Buffer Cache与Shared Pool等SGA区域大小分析以及Load Profile中Redo size、Logical reads、Hard parses等指标的判读要点并强调选择代表性分析时间段的重要性。资源包为1个PDF文件大小约1.18MB结构紧凑便于随时查阅。目前已有580人学习下载适合希望掌握AWR报告分析思路、提升数据库调优能力的读者参考。1. 拿到 AWR 报告先别翻 Top SQL从 DB Time 和 Elapsed 的比值读出系统真实压力很多人拿到一份 AWR 报告第一反应是直接跳到「SQL ordered by Elapsed Time」找最慢的语句然后开始加索引、改 SQL。这个顺序大概率是错的。AWR 是 Oracle 10g 引入的自动负载信息库Automatic Workload Repository它靠对比两次快照之间的统计差值生成报表本质是一份「时间都花在哪了」的账单。账单没看懂就动手等于闭着眼睛调优。这份《OracleAWR报告详细分析.pdf》的价值在于它没有停在指标定义层面而是把 Load Profile、Instance Efficiency、Top 5 Timed Events、RAC Statistics、Wait Events 这几大块串成了一条从「判断系统忙不忙」到「定位具体等待」的链路。它适合两类人一是刚接手 Oracle 运维、需要照着报告逐项读的 DBA二是遇到性能告警、想快速判断是数据库问题还是应用问题的后端工程师。核心判断逻辑其实就一句话——先看 DB Time 和 Elapsed 的比值再决定要不要往下深挖。2. 读懂负载概况DB Time、Elapsed 与 CPU 核数的三角关系2.1 DB Time 到底统计了什么DB Time 是 AWR 里最容易被误读的指标。它的定义是所有非后台进程在数据库运算和等待不含空闲等待上花费的总时间公式为 DB Time CPU Time 非空闲 Wait Time。注意两个限定词——「非后台进程」和「非空闲等待」。这意味着 DB Time 不包含 Oracle 后台进程如 DBWR、LGWR、PMON消耗的时间也不包含像sql*net message from client这类空闲等待。文档里给了一个很直观的例子79 分钟内收集了 3 次快照DB Time 只有 11 分钟而系统有 8 个逻辑 CPU。平均每个 CPU 耗时 11/8 ≈ 1.4 分钟CPU 利用率约 1.4/79 ≈ 2%。这个数字说明系统压力非常小根本不需要调优。反过来如果 DB Time 接近甚至超过 Elapsed × CPU 核数说明数据库已经把 CPU 吃满了这时候才需要认真看后面的等待事件。2.2 用 Report A 和 Report B 做对比判断负载文档里用两份报告做了对比这个对比方法值得直接抄下来用报告Elapsed (mins)DB Time (mins)CPU 核数DB Time / (Elapsed × 核数)结论Report A59.51466.378466.37 / (59.51×8) ≈ 98%CPU 几乎被 Oracle 占满Report B59.6319.49819.49 / (59.63×8) ≈ 4%平均负载很低Report A 里60 分钟窗口内 8 个核总共提供 480 分钟的 CPU 时间DB Time 466.37 分钟意味着 CPU 有 98% 的时间在处理 Oracle 的非空闲操作。Report B 只有 4%说明服务器大部分时间在闲着。这里有个关键提醒对于批量系统数据库负载往往集中在某个时间段。如果快照周期没覆盖到那段高峰或者跨度太长把大量空闲时间也包进来了算出来的比值会严重偏低分析结论就是废的。所以选分析时间段时一定要选能代表性能问题的那段窗口而不是随便挑一个整点。提示DB Time 远小于 Elapsed 不代表没问题只代表「平均下来不忙」。如果业务方反馈某个时刻卡顿你需要把快照粒度调细或者直接查那个时间段的 ASH 数据。2.3 从 Cache Sizes 和 Load Profile 看资源分配Cache Sizes 部分显示 SGA 各区域大小包括 Buffer Cache、Shared Pool Size、Log Buffer 和 Std Block Size。文档特别指出Shared Pool 里的 library cache 和 dictionary cache 发生 cache miss 的代价远高于 buffer cache所以 Shared Pool 的设置要确保最近使用的数据都能被缓存。这个判断在后续 Instance Efficiency 的 Library Hit 指标里会得到验证。Load Profile 部分按 Per Second 和 Per Transaction 两个维度列出负载指标。文档给了一组阈值参考Logons 大于每秒 1~2 个、Hard Parses 大于每秒 100、全部 Parses 超过每秒 300就可能有争用问题。Redo size 反映数据变更频率Logical reads 反映逻辑读压力Block changes 反映修改频率。这些值单独看没有「正确」答案必须和基线对比才有意义。3. 实例效率与等待事件从命中率到 Top 5 的排查路径3.1 Instance Efficiency 里的关键命中率怎么读Instance Efficiency Percentages 这一节列了一堆百分比文档明确说「没有所谓正确的值」只能根据应用特点判断。但有几个阈值是业界共识可以直接拿来用指标理想值低于阈值时的动作Buffer Nowait % 99%存在缓冲区争用查等待事件确认Buffer Hit %OLTP 95%低于 80% 考虑加内存检查 top physical reads SQLLibrary Hit % 95%考虑加大 Shared Pool、使用绑定变量Latch Hit % 99%检查 Shared Pool latch 争用可能需绑定变量或调大 Shared PoolIn-memory Sort % 95%调大 PGA_AGGREGATE_TARGET 或 SORT_AREA_SIZESoft Parse % 95%低于 80% 说明 SQL 基本没复用需绑定变量文档里有个反直觉的点值得注意Buffer Hit 高不一定代表系统好。比如大量非选择性索引被频繁访问会造成命中率很高的假象实际伴随大量db file sequential read。真正要警惕的是命中率的突变——突然增大就查 top buffer get SQL突然减小就查 top physical reads SQL。3.2 用 Top 5 Timed Events 确定下一步方向Top 5 Timed Events 是报告概要的最后一节按等待时间占比倒序列出最严重的 5 个等待。文档给了一个非常实用的排查路径如果buffer busy wait严重 → 继续看 Buffer Wait 和 File/Tablespace IO 区识别哪些文件导致问题如果 I/O 事件严重 → 看按物理读排序的 SQL识别哪些语句在大量 I/O如果 LATCH 等待高 → 看详细 LATCH 统计识别具体是哪个 latch一个性能良好的系统CPU time 应该排在 Top 5 的前面。文档里那个例子CPU time 排第一但log file parallel write占了 7%说明日志写入有一定压力。如果 CPU time 不在前面说明系统大部分时间在等待这时候就要顺着等待事件往下挖。3.3 常见等待事件的定位与处理文档对几个高频等待事件给了详细说明这里整理成可操作的排查步骤db file scattered read文件分散读取通常与全表扫描或 fast full index scan 有关。排查时结合v$session_longops看长时间运行的操作确认全表扫描是否必要。如果希望某条语句走索引可以调整optimizer_index_cost_adj默认 100理解为 FULL SCAN COST / INDEX SCAN COST。db file sequential read文件顺序读取单块读等待通常因表连接顺序糟糕或使用了非选择性索引。检查索引扫描是否必须确认多表连接的驱动行源是否正确。buffer busy wait缓冲区忙这个值不应大于 1%。排查时先查v$event_name确认参数含义——9i 的 p3 是 id10g 的 p3 是 class#。然后按等待位置分类处理-- 获取产生 buffer busy waits 的 SQL 语句 select sql_text from v$sql t1, v$session t2, v$session_wait t3 where t1.address t2.sql_address and t1.hash_value t2.sql_hash_value and t2.sid t3.sid and t3.event buffer busy waits; -- 获取等待块的类型和所在 segment select Segment Header class, a.segment_type, a.segment_name, a.partition_name from dba_segments a, v$session_wait b where a.header_file b.p1 and a.header_block b.p2 and b.event buffer busy waits union select Freelist Groups class, a.segment_type, a.segment_name, a.partition_name from dba_segments a, v$session_wait b where a.header_file b.p1 and b.p2 between a.header_block 1 and (a.header_block a.freelist_groups) and a.freelist_groups 1 and b.event buffer busy waits;第一段查询把等待事件和当前会话、SQL 文本关联起来定位到具体语句。第二段查询通过 p1文件号和 p2块号反查 segment判断等待发生在段头、freelist 组还是数据块。参数 p1、p2、p3 的含义在不同版本有差异9i 的 p3 是等待原因编号10g 变成了块类型编号这个版本差异是排查时最容易翻车的地方。如果等待在段头说明 freelist 块太少可以增加 freelist 或 freelist groups如果在 undo header增加回滚段如果在 undo block增加提交频率如果在 data block说明有热块可以增大 PCTFREE、减小块大小、优化 SQL 或增加 INITRANS通常设 5 就够每个 ITL 槽占 24 字节。4. 避坑与常见问题AWR 分析里最容易翻车的五个地方4.1 快照窗口选错分析结论全废现象报告显示系统很空闲但业务方持续反馈卡顿。原因批量系统的负载集中在特定时段如果快照周期没覆盖高峰或者跨度太长把大量空闲时间包进来DB Time / Elapsed 的比值会被严重拉低。解决先和业务确认性能问题发生的具体时间段然后用DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动创建快照或者调整快照间隔默认 60 分钟到更细的粒度。分析时只选覆盖问题时段的那对快照。4.2 把 DB Time 当成响应时间现象看到 DB Time 很大就认为系统慢看到 DB Time 小就认为没问题。原因DB Time 是累计时间不是单次请求的响应时间。它统计的是所有非后台进程在数据库上花的总时间和并发数、请求量都有关系。解决DB Time 要和 Elapsed、CPU 核数一起看算比值判断整体压力。单次请求的响应时间要看 Average Active SessionsAAS或者具体 SQL 的 Elapsed Time per Exec。4.3 硬解析阈值生搬硬套现象Hard Parses 每秒超过 100 就急着改cursor_sharing。原因文档明确说cursor_sharingsimilar存在 bug可能导致执行计划不优。而且硬解析阈值和系统类型有关DSS 系统和 OLTP 系统的标准完全不同。解决先确认 SQL 是否真的没有复用——看SQL with executions1的比例如果低于 80% 才考虑绑定变量。改cursor_sharing之前先在测试环境验证执行计划优先从应用层改 SQL 写法。4.4 忽略 RAC 相关的全局等待现象单实例分析没问题RAC 环境下性能就是上不去。原因RAC 报告里有 Global Cache Load Profile 和 Global Cache Efficiency Percentages如果Buffer access - remote cache %偏高说明实例间数据传递频繁互联网络可能成为瓶颈。解决关注Avg global cache cr block receive time和Avg global cache current block receive time如果超过 1ms 就要检查互联网络。同时看Estd Interconnect traffic评估网络带宽是否足够。4.5 用命中率高低直接判断性能好坏现象Buffer Hit 98% 就认为没问题或者低于 90% 就急着加内存。原因文档明确指出高命中率可能是假象——大量非选择性索引被频繁访问会造成命中率很高但伴随大量db file sequential read。命中率的突变比绝对值更值得关注。解决命中率要和 Top 5 Timed Events、Top SQL 一起看。如果命中率高但 I/O 等待也高说明问题不在缓存大小而在 SQL 访问路径。如果命中率突然下降查 top physical reads SQL看是否有索引被删除或执行计划突变。5. 从报告到行动把 AWR 指标转成可执行的调优清单5.1 建立基线比单次分析更重要文档反复强调一个观点单个报告的数据只说明应用的负载情况绝大多数指标没有「正确」值必须和基线对比。我一般会在系统稳定运行期采集 3~5 份 AWR 报告作为基线记录 Load Profile 和 Instance Efficiency 的关键值。之后每次出现性能问题先和基线对比看哪些指标发生了突变。突变点往往就是问题源头。比如Execute to Parse这个指标计算公式是100 * (1 - Parses/Executions)。文档例子里差不多每 5 次执行需要 1 次解析所以这个值在 80% 左右。如果基线是 90%突然掉到 50%说明解析次数暴增要么是 SQL 没复用要么是 shared pool 出了问题。如果这个值小于 0说明 Parses 大于 Executions通常意味着 shared pool 设置有问题或者语句效率极差reparse 严重。5.2 用 SQL 定位具体问题语句AWR 报告里的 Top SQL 区域按不同维度排序常用的有 Elapsed Time、CPU Time、Buffer Gets、Physical Reads。我一般按这个顺序查-- 查当前等待事件对应的 SQL实时排查用 select s.sid, s.serial#, s.username, s.sql_id, s.event, s.wait_class, s.seconds_in_wait, q.sql_text from v$session s join v$sql q on s.sql_id q.sql_id where s.status ACTIVE and s.wait_class Idle order by s.seconds_in_wait desc; -- 查历史 SQL 统计AWR 快照范围内 select sql_id, executions, elapsed_time/1000000 as elapsed_sec, cpu_time/1000000 as cpu_sec, buffer_gets, disk_reads, rows_processed, sql_text from dba_hist_sqlstat h join dba_hist_sqltext t on h.sql_id t.sql_id where h.snap_id between begin_snap and end_snap order by h.elapsed_time_delta desc fetch first 20 rows only;第一段查当前活跃会话的非空闲等待直接定位到正在拖慢系统的语句。第二段查历史快照范围内的 SQL 统计elapsed_time_delta是两次快照之间的增量比绝对值更有参考意义。buffer_gets高说明逻辑读多disk_reads高说明物理读多rows_processed和executions的比值可以看出单次执行返回多少行。5.3 共享池与解析问题的处理技巧Shared Pool Statistics 里有两个指标很关键Memory Usage %应该稳定在 75%~90%太低说明 Shared Pool 设置过大带来管理负担太高说明有争用。SQL with executions1的比例如果太小说明需要在应用中更多使用绑定变量。我处理解析问题的顺序是先看Soft Parse %低于 95% 就查SQL with executions1的比例如果这个比例也低说明 SQL 确实没复用优先从应用层改绑定变量如果应用层短期改不了再考虑session_cached_cursors参数让 fast parse 在 PGA 中命中。文档里提到 fast parse 是直接在 PGA 中命中的情况设置session_cached_cursorsn后生效。这个参数对 OLTP 系统效果明显但要注意每个 session 会占用额外 PGA 内存。5.4 一个我踩过的坑早些年我拿到一份 AWR 报告看到log file parallel write排在 Top 5 第二位占了 7% 的等待时间第一反应是把 redo log 文件挪到更快的盘上。结果折腾了半天发现真正的问题是应用端批量提交太频繁导致 LGWR 写入压力大。后来我养成一个习惯看到任何 I/O 相关等待先查Physical Writes和Redo size的 Per Second 值确认是数据库配置问题还是应用写入模式问题。如果是应用写入模式问题换再快的盘也是治标不治本。从那以后我每次分析 AWR 报告都强制走一遍「DB Time / Elapsed → Top 5 Timed Events → 对应区域的详细指标 → Top SQL」这条链路不跳步。这份《OracleAWR报告详细分析.pdf》把这条链路上的每个节点都讲到了包括 RAC 环境下的全局缓存指标和常见等待事件的参数含义适合放在手边当速查手册用。希望帮到你。本文还有配套的精品资源点击获取