1. 项目概述为什么AWR报告是DBA的“听诊器”在Oracle数据库的日常运维和性能调优工作中AWR报告Automatic Workload Repository Report的地位就像医生手中的听诊器。它不是一个简单的日志文件而是一个由Oracle数据库自身定期、自动采集并存储的性能数据快照集合。当数据库出现性能瓶颈比如某个应用模块突然变慢、CPU使用率异常飙升、或者磁盘I/O响应时间过长时光靠猜测和零散的查询是远远不够的。你需要一份详尽的“体检报告”来告诉你过去一段时间内数据库的“心跳”等待事件、“血压”系统负载和“血液成分”SQL执行情况到底出了什么问题。很多刚接触Oracle的DBA或者开发人员可能会觉得生成AWR报告是个高深莫测的操作需要复杂的脚本和权限。实际上Oracle已经把这个过程封装得非常友好核心步骤就那几步。但难点在于拿到这份动辄几十页甚至上百页的报告后如何从海量的数据中快速定位到核心问题。这就像拿到一份全身体检报告普通人可能只看懂几个箭头偏高或偏低而资深医生却能一眼看出各项指标间的关联和病根所在。本文将不仅手把手教你如何生成一份标准的AWR报告更会以一个十年DBA的视角带你解读报告中最关键的几个部分让你从“看热闹”变成“看门道”。2. AWR报告生成全流程与核心原理2.1 理解AWR的工作机制快照与基线在动手生成报告之前必须先理解AWR的两个核心概念快照和基线。这是读懂AWR报告的前提。快照是AWR机制的基石。你可以把它理解为数据库在某个特定时间点的“全身照”。Oracle后台进程MMONManageability Monitor默认每小时自动采集一次快照并将性能数据存入SYSAUX表空间下的AWR仓库中。这些数据包括但不限于系统统计信息如CPU时间、内存使用、等待事件、SQL语句的执行统计、段表、索引的活动情况等。快照会保留一段时间默认8天之后旧的快照会被自动清理。基线则是一个或多个快照的命名集合。它的作用是为数据库定义一个“健康”或“典型”的性能状态用作后续性能对比的基准。例如你可以将系统上线后平稳运行一周的快照定义一个基线命名为“上线后基准”。当未来某天系统出现性能问题时你就可以生成一份对比报告将问题时段的快照与这个基线进行对比从而快速发现哪些指标发生了显著恶化。注意AWR数据的采集和存储本身会带来轻微的系统开销。在极端高性能或资源极度紧张的环境中可以考虑调整快照采集间隔如改为2小时或缩短保留时间。但对于绝大多数生产系统默认设置是合理且推荐的。2.2 生成AWR报告的三种实战方法生成AWR报告本质上就是指定一个开始快照ID和一个结束快照ID然后让Oracle帮你把这两个时间点之间的性能数据汇总、分析并格式化输出。以下是三种最常用、也最可靠的方法。2.2.1 方法一使用SQL*Plus命令行最经典、最可靠这是DBA在服务器上最直接的操作方式无需图形界面适合所有环境。第一步连接到数据库实例你需要使用具有DBA权限的用户如SYS、SYSTEM或已被授予相应权限的用户登录到SQL*Plus。通常我们会在数据库服务器上直接操作。sqlplus / as sysdba或者使用密码登录sqlplus sys/passwordservice_name as sysdba第二步调用官方脚本生成报告Oracle提供了标准的脚本awrrpt.sql用于生成单实例数据库的文本报告和awrrpti.sql用于生成指定实例的文本报告在RAC环境中常用。脚本通常位于$ORACLE_HOME/rdbms/admin目录下。在SQL*Plus中执行?/rdbms/admin/awrrpt.sql这里的?代表ORACLE_HOME环境变量。第三步交互式输入参数执行脚本后会进入一个交互式界面你需要按顺序输入以下信息报告类型通常选择默认的html格式更友好支持超链接和颜色高亮。text文本格式则更适合在纯终端环境下查看或用于脚本解析。快照天数你想查看最近几天的快照列表输入一个数字比如1查看最近一天的。开始快照ID和结束快照ID系统会列出指定天数内的所有快照包含ID、采集时间。你需要从中选择两个ID代表你要分析的时间窗口。结束快照的时间必须晚于开始快照。报告文件名脚本会建议一个默认名称如awrrpt_1_100_101.html。你可以直接回车接受或输入自定义名称。完成后脚本会在当前目录下生成对应的HTML或TXT文件。实操心得在生成报告前最好先查询一下可用的快照做到心中有数。可以执行SELECT snap_id, TO_CHAR(begin_interval_time, YYYY-MM-DD HH24:MI:SS) begin_time FROM dba_hist_snapshot ORDER BY snap_id DESC;对于分析一个具体的性能事件快照窗口的选择非常关键。理想情况是开始快照刚好在问题发生前结束快照在问题发生后不久。窗口太短可能抓不到完整数据太长则会被大量正常数据稀释问题特征。2.2.2 方法二使用OEM/Cloud Control图形界面最直观如果你所在的环境部署了Oracle Enterprise Manager (OEM) 或 Cloud Control那么生成AWR报告会变得非常可视化。登录OEM控制台。导航到“性能”页签下的“AWR”部分。你可以直接查看最新的AWR报告或者通过时间选择器指定一个时间段系统会自动匹配该时间段内的快照。点击“生成报告”选择格式HTML/文本后即可在线查看或下载。这种方法的好处是无需记忆快照ID操作直观并且OEM通常还提供基于AWR数据的性能分析建议。缺点是需要额外的OEM部署和维护。2.2.3 方法三使用DBMS_WORKLOAD_REPOSITORY包最灵活、可编程对于需要将AWR报告生成集成到自动化脚本或监控平台中的高级场景可以使用PL/SQL包DBMS_WORKLOAD_REPOSITORY。这给了你最大的灵活性。生成HTML报告示例DECLARE l_report CLOB; BEGIN -- 生成快照100到101之间的AWR报告输出为HTML格式 l_report : DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_HTML( dbid NULL, -- NULL表示当前数据库 inst_num NULL, -- NULL表示当前实例 bid 100, -- 开始快照ID eid 101 -- 结束快照ID ); -- 将报告内容插入一张表或输出到文件这里示例输出到DBMS_OUTPUT实际应用中可能写入文件 DBMS_OUTPUT.PUT_LINE(Report length: || LENGTH(l_report)); -- 实际使用时你可能需要用UTL_FILE包将l_report写入服务器文件系统 END; /生成对比报告示例 对比报告能直观显示两个时间段如问题期间和基线期间的性能差异。SELECT DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML( (SELECT dbid FROM v$database), (SELECT instance_number FROM v$instance), 100, 101, -- 第一时段快照 200, 201 -- 第二时段快照基线时段 ) AS diff_report FROM dual;重要提示使用包生成报告时报告内容以CLOB类型返回。在SQL*Plus中直接查看大CLOB可能不完整最佳实践是通过PL/SQL程序将其使用UTL_FILE包写入服务器的文件系统或者由应用程序处理后展示。3. AWR报告核心章节深度解读与性能问题定位生成了报告面对密密麻麻的数据从哪里看起一份标准的AWR报告主要包含以下核心章节我们的分析也应有所侧重。3.1 报告头与概要信息建立第一印象打开报告首先看头部。这里记录了数据库版本、实例名、主机信息、以及你选择的快照时间范围。务必确认时间范围是你想分析的那个问题时段这是所有分析的前提。紧接着是“Report Summary”。这部分是精华摘要即使时间有限也必须快速浏览。Cache Sizes展示了SGA系统全局区内各组件Buffer Cache, Shared Pool等的大小。可以快速判断内存配置是否合理。Load Profile这是重中之重。它提供了每秒和每事务的负载概况。Redo size每秒产生的重做日志量。突然激增可能意味着大量DML操作插入、更新、删除。Logical reads每秒逻辑读。持续过高可能说明SQL效率低下需要大量访问缓冲区或磁盘。Physical reads每秒物理读。如果这个值很高同时Buffer Hit Ratio在后面的“Instance Efficiency Percentages”中很低说明磁盘I/O压力大可能缺少合适索引或SQL全表扫描严重。Instance Efficiency Percentages各项命中率。Buffer Nowait %获取缓冲区未等待的百分比。低于99%可能意味着缓冲区争用。Buffer Hit %缓冲区命中率。理想情况应在95%以上。过低是物理读高的直接原因。Library Hit %库缓存命中率。低于95%可能意味着应用没有使用绑定变量导致大量硬解析消耗大量CPU。3.2 等待事件分析找到系统在“等”什么“Top 10 Foreground Events by Total Wait Time”是定位性能瓶颈的“圣杯”。它列出了在快照期间会话花费时间最多的等待事件。DB CPU如果它排在第一位且等待时间占比很高这通常是一个“好”信号说明系统确实在忙碌地处理数据瓶颈可能在CPU本身的计算能力或低效的SQL消耗了过多CPU。需要结合后面的SQL统计来分析。DB File Sequential Read通常表示索引扫描或单块读取。如果这个事件等待时间很长可能意味着磁盘I/O速度慢或者SQL语句虽然走了索引但需要回表访问大量数据块。DB File Scattered Read通常表示全表扫描或多块读取。等待时间长可能意味着存在大量全表扫描操作。Buffer Busy Waits缓冲区繁忙等待。多个会话试图同时访问或修改同一个数据块。可能是热点块问题常见于高度并发的索引叶块或小表。Enq: TX - Row Lock Contention行锁竞争。这是应用层设计或逻辑问题会话在等待其他会话释放行锁。需要结合后面的“Segments by Row Lock Waits”来定位具体的表和行。分析技巧不要孤立地看等待事件。例如高DB File Sequential Read等待需要去查看“SQL ordered by Reads”部分找到那些物理读最高的SQL进行优化。3.3 SQL统计信息揪出“罪魁祸首”AWR报告提供了多个角度的SQL排序列表这是优化工作的直接输入。SQL ordered by Elapsed Time按总执行时间排序。排在前面的SQL消耗了系统最多的总时间优化它们收益最大。SQL ordered by CPU Time按消耗CPU时间排序。如果DB CPU等待高看这里。SQL ordered by Gets按逻辑读Buffer Gets排序。逻辑读高的SQL即使执行快也可能对缓冲区造成压力影响其他SQL。SQL ordered by Reads按物理读Disk Reads排序。直接关联I/O等待事件。SQL ordered by Executions按执行次数排序。高频率执行的SQL即使单次性能尚可其累积影响也可能很大且其执行计划稳定性至关重要。拿到一条问题SQL后怎么做复制SQL文本和SQL_ID。在报告中查找该SQL的执行计划报告通常会在SQL详情部分提供快照期间的执行计划。关注全表扫描FULL TABLE SCAN、低效的连接方式如笛卡尔积、不合理的索引使用等。查看该SQL的绑定变量信息如果报告中有有时性能问题只发生在特定变量值下。使用SQL_ID在数据库中可以进一步获取更详细的历史执行信息例如使用DBA_HIST_SQLSTAT视图。3.4 段Segment统计信息定位热点对象等待事件和SQL告诉你系统在“怎么等”和“谁在忙”而段统计则告诉你“忙在哪个对象上”。Segments by Logical Reads哪些表或索引被逻辑访问最多Segments by Physical Reads哪些对象导致了最多的物理I/O这通常是添加或优化索引的候选对象。Segments by Row Lock Waits哪些表上的行锁竞争最严重这指向应用逻辑或事务设计问题。例如如果发现某张不大的表长期位居“Segments by Physical Reads”前列很可能它缺少必要的索引导致相关SQL反复进行全表扫描。4. 基于AWR报告的典型性能问题诊断流程理论说了很多我们通过一个虚构但常见的场景串联一下整个诊断流程。场景下午3点客服系统突然变慢页面响应时间从1秒增加到10秒以上。你收到告警后需要快速定位问题。第一步生成问题时段AWR报告登录服务器连接到数据库。查询快照列表发现最近一次自动快照是下午2点Snap ID: 100而3点05分时系统似乎恢复了Snap ID: 101。你决定分析2点到3点这个时间窗口。sqlplus / as sysdba ?/rdbms/admin/awrrpt.sql输入报告类型html天数1开始Snap ID100结束Snap ID101。生成报告awrrpt_100_101.html。第二步快速浏览摘要和等待事件打开报告直接跳到“Top 10 Foreground Events”。发现“DB File Sequential Read”事件平均等待时间高达 80毫秒正常应小于20毫秒且总等待时间占比超过60%。“DB CPU”占比约30%。其他等待事件占比很小。初步判断I/O等待异常突出可能是磁盘性能问题也可能是某些SQL引发了大量低效的单块读。第三步核查负载和效率查看“Load Profile”Physical reads/sec比正常时段飙升了5倍。Buffer Hit %从平时的98%下降到了85%。查看“Instance Efficiency Percentages”Buffer Hit %低确认了物理读问题。Library Hit %为99%说明没有严重的硬解析问题。第四步定位问题SQL转到“SQL ordered by Reads”部分。排在第一位的是一条查询语句其物理读Disk Reads占整个快照期间的40%。记下它的SQL_ID。第五步分析SQL与相关对象查看该SQL的详细信息发现其执行计划对一张百万级的ORDERS表使用了索引范围扫描但需要回表访问大量数据行TABLE ACCESS BY INDEX ROWID成本很高。 同时在“Segments by Physical Reads”中ORDERS表及其上的一个索引也名列前茅。根本原因推断这条高频执行的SQL由于查询条件选择性不高导致通过索引回表访问了海量数据块。这些数据块不在Buffer Cache中引发了大量的物理读DB File Sequential Read而磁盘阵列可能当时也存在性能波动进一步放大了等待时间最终导致应用响应缓慢。解决方案短期考虑优化该SQL例如通过添加复合索引覆盖查询所需的所有列避免回表。长期审查该表的数据模型和索引设计。考虑对磁盘I/O子系统进行性能评估。5. AWR相关的高级技巧与常见问题排查5.1 手动创建与删除快照自动快照每小时一次但当你准备进行一个可能影响性能的重大操作如应用发布、大批量数据迁移时手动创建快照可以精确标记时间点。创建手动快照EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();执行后可以查询DBA_HIST_SNAPSHOT视图获取刚生成的快照ID。删除快照谨慎操作-- 删除指定ID范围的快照 EXEC DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(low_snap_id 100, high_snap_id 110); -- 根据保留策略清理过期快照通常无需手动执行 EXEC DBMS_WORKLOAD_REPOSITORY.PURGE_SNAPSHOT(retention 20160); -- retention单位是分钟20160分钟14天5.2 管理AWR基线基线对于性能趋势分析和容量规划非常有用。创建基线EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE( start_snap_id 150, end_snap_id 160, baseline_name WEEKEND_PEAK_202310, expiration 365 -- 基线保留天数NULL表示永不过期 );生成基线对比报告 可以使用前面提到的AWR_DIFF_REPORT_HTML函数或者通过OEM界面更方便地生成问题时段与基线时段的对比报告。5.3 常见问题与排查技巧实录问题1执行awrrpt.sql脚本时提示“SP2-0310: unable to open file”原因SQL*Plus找不到脚本文件。?符号未正确指向ORACLE_HOME。解决确认当前用户的环境变量ORACLE_HOME已设置正确echo $ORACLE_HOME。使用绝对路径执行脚本/u01/app/oracle/product/19c/dbhome_1/rdbms/admin/awrrpt.sql。或者先进入脚本目录再执行cd $ORACLE_HOME/rdbms/admin 然后awrrpt.sql。问题2生成的AWR报告时间范围不对或者没有数据原因 a) 输入的起始快照ID大于结束快照ID。 b) 快照已被自动或手动清理。 c) 在RAC环境中可能连接到了错误的实例而该实例在所选时间段内没有快照。解决生成报告前务必先用SELECT * FROM dba_hist_snapshot ORDER BY snap_id;查询确认可用的快照。检查AWR保留设置SELECT * FROM dba_hist_wr_control;。RETENTION列是保留分钟数。在RAC环境中使用awrrpti.sql脚本它会提示你选择具体的实例号。问题3AWR报告文件太大打开或分析困难原因快照时间窗口过长如超过4小时或者系统极其繁忙产生了海量数据。解决缩短分析窗口尽量将问题时段缩小到30分钟到1小时以内生成更精确的报告。使用文本格式HTML报告虽然美观但文件体积大。对于纯分析文本格式TXT更轻量处理更快。聚焦关键章节不要试图通读全文。按照“等待事件 - 负载概要 - 关键SQL”的优先级进行阅读。利用第三方工具考虑使用一些能解析AWR报告并做可视化分析的工具如Toad、Spotlight等它们能更高效地呈现关键指标。问题4SYSAUX表空间增长过快怀疑是AWR数据占用原因AWR默认保留8天数据如果系统负载高、实例数多如RACAWR表会占用大量空间。解决查询AWR大小SELECT * FROM v$sysaux_occupants WHERE occupant_nameSM/AWR;适当调整快照间隔和保留策略需谨慎评估EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention 4320, -- 改为3天60*24*3单位分钟 interval 120 -- 改为每2小时采集一次单位分钟 );手动清理历史快照见5.1节。个人踩坑记录有一次处理一个性能问题AWR报告显示“log file sync”等待异常高。按照常规思路我首先去检查重做日志组的配置和磁盘I/O。折腾了半天才发现根本原因是应用在循环中频繁地提交COMMIT小事务。每个COMMIT都需要等待日志写操作完成log file sync。最后通过修改应用逻辑将多个操作合并为一个事务提交性能立刻得到大幅提升。这个经历告诉我AWR报告指出的直接等待事件如I/O等待其根源可能在应用层的行为模式上。