1. AWR报告Oracle数据库性能分析的“体检报告”如果你是一名DBA或者正在管理Oracle数据库那你肯定遇到过数据库突然变慢、应用响应卡顿的情况。这时候光靠感觉和经验去猜是没用的你需要一份精准的“体检报告”。在Oracle的世界里这份报告就是AWRAutomatic Workload Repository自动工作负载仓库报告。我干了这么多年DBA处理过无数次性能问题可以负责任地说AWR报告是定位数据库性能瓶颈最核心、最强大的工具没有之一。简单来说Oracle数据库会像智能手表一样每隔一小时默认设置自动“测量”一次自己的各项关键指标比如CPU使用率、内存消耗、SQL执行情况、等待事件等并把这次测量的结果保存为一个“快照”Snapshot。AWR报告就是选取两个特定时间点的快照生成一份这段时间内数据库运行状况的详细对比分析报告。在Oracle 19c里这份报告的功能变得更加强大和集成它不再是孤立的性能数据而是把AWR、ADDM自动数据库诊断监视器和ASH活动会话历史这三块核心内容有机地整合在了一起。这意味着你拿到手的是一份“一站式”的诊断报告不用再像以前那样为了一个问题东奔西跑收集好几份材料。这份报告适合谁看呢无论是刚入门的数据库新手还是经验丰富的老鸟都需要它。对于新手你可以通过报告里的关键指标比如Top 5 Timed Events快速抓住问题重点对于老手你可以深入报告细节结合等待事件、SQL执行计划进行精准的根因分析。接下来我就带你从零开始彻底搞懂Oracle 19c中的AWR报告并分享在不同实战场景下如何高效使用它。2. 实战第一步生成你的第一份AWR报告理论说再多不如亲手操作一遍。生成AWR报告其实非常简单整个过程就像在命令行里做一个问卷调查。你不需要记住复杂的命令只需要找到Oracle自带的神奇脚本然后跟着提示一步步走就行。首先你需要连接到你的Oracle 19c数据库。用sqlplus以sysdba身份登录是最直接的方式sqlplus / as sysdba登录成功后关键的一步是切换到存放AWR脚本的目录。这些脚本是Oracle自带的位于$ORACLE_HOME/rdbms/admin下。你可以直接运行?/rdbms/admin/awrrpt.sql这里的?是一个SQL*Plus的变量代表$ORACLE_HOME非常方便。运行这个命令后交互式界面就开始了。你会看到一系列提示别紧张我们一个一个来。第一步选择报告格式。系统会问你要html、text还是active-html格式。我强烈推荐选择html因为生成的网页报告带有丰富的颜色和可排序的表格阅读体验远好于纯文本。active-html是19c引入的增强格式包含了Performance Hub的链接功能更强但对于初次分析html足够了。第二步确认数据库实例。脚本会自动列出当前连接的数据库IDDB Id、实例名等信息通常直接按回车确认即可。第三步选择快照的时间范围。系统会问你想看最近几天的快照。比如输入2就会列出最近两天内所有的快照。这时屏幕上会显示一个清晰的列表包括快照ID、开始时间等。你需要仔细回想你的性能问题大概发生在什么时间段。比如应用在上午10点到11点之间变慢那你就在列表里找到覆盖这个时间段的快照。第四步输入开始和结束的快照ID。这是最关键的一步。根据上一步的列表输入问题开始时的快照ID作为begin_snap问题结束时的快照ID作为end_snap。比如问题发生在10:00到11:00那么你可能选择154作为开始155作为结束。完成所有输入后脚本就会在后台吭哧吭哧地工作最后告诉你报告生成在了哪里通常是当前目录下一个类似awr_20211009_154_155.html的文件。用浏览器打开它一份几十页甚至上百页的详细性能报告就呈现在你眼前了。我第一次生成报告时看着密密麻麻的数据也发懵但别怕我们接下来就教你抓重点。3. 庖丁解牛读懂AWR报告的核心章节拿到一份HTML格式的AWR报告内容非常多从头到尾逐字阅读效率很低。我们需要像老中医一样学会“望闻问切”抓住几个最关键的部分就能快速对数据库的健康状况做出判断。第一个必看部分Report Summary报告概要。这部分在报告开头相当于“摘要”。你需要重点关注DB Time和Elapsed Time。Elapsed Time是你选择的快照时间间隔比如1小时而DB Time是数据库在这1小时内处理所有用户请求花费的总时间可以理解为所有会话消耗的CPU时间等待时间的总和。如果DB Time远大于Elapsed Time比如1小时内DB Time达到了10小时那就说明数据库在这段时间内非常繁忙存在严重的性能瓶颈。第二个必看部分Top 5 Timed Foreground Events前5个耗时前台等待事件。这是整个报告的“灵魂”是定位性能问题的第一突破口。数据库慢大部分时间都是在“等待”某种资源。这个表格列出了消耗时间最多的5种等待事件。比如如果你看到“db file sequential read”排名第一并且平均等待时间很长这通常意味着SQL语句在进行大量的单块读常见于索引扫描可能需要检查SQL是否缺少合适的索引或者是否在执行低效的全表扫描。如果看到“log file sync”等待很高可能意味着提交太频繁或者redo日志写入存在瓶颈。我处理过一个系统卡顿的案例一打开报告就看到“enq: TX - row lock contention”行锁竞争排在第一位立刻就锁定了问题是应用逻辑导致的事务锁等待而不是硬件或SQL问题。第三个关键部分SQL StatisticsSQL统计信息。数据库的负载最终都会体现在SQL语句上。这部分会列出执行时间最长SQL ordered by Elapsed Time、消耗CPU最多SQL ordered by CPU Time、读取缓冲区最多SQL ordered by Gets的SQL语句。通常排在前几位的SQL就是你需要优化的首要目标。点开SQL ID报告还会显示该SQL的执行计划、执行次数等详细信息为你的优化提供直接依据。第四个需要浏览的部分Instance Activity Stats实例活动统计和Wait Events等待事件统计。这里提供了更细粒度的统计数据。比如你可以查看“physical reads”物理读是否异常高“parse count (hard)”硬解析次数是否过多。过多的硬解析会严重消耗CPU这也是一个常见的性能杀手。对于Oracle 19c的报告你还会发现ADDM Findings和ASH Report的链接或摘要也被整合了进来。ADDM会基于AWR数据给出自动诊断建议比如“建议优化SQL ID ‘abc123’”。而ASH则提供了更细粒度每秒的会话活动信息对于分析短时间比如几分钟的瞬时性能尖峰特别有用。19c的这种整合让你在分析一个时间段的性能问题时信息获取更加连贯和全面。4. 进阶场景RAC、CDB与PDB环境下的AWR报告真实的生产环境往往比单实例数据库更复杂。你可能面对的是Oracle RAC真正应用集群或者是19c流行的多租户架构CDB/PDB。别担心AWR报告家族有对应的工具来应对这些场景。4.1 RAC环境下的全局视野在RAC环境中你的负载分布在多个数据库实例上。如果还用单实例的awrrpt.sql你只能看到其中一个实例的情况就像盲人摸象。这时你需要的是awrgrpt.sqlGlobal AWR Report。这个脚本生成的报告会汇总所有实例的性能数据给你一个集群级别的全局视图。运行方式类似?/rdbms/admin/awrgrpt.sql在生成的全局AWR报告中你会看到每个实例的DB Time分布从而快速识别出集群中的“短板”实例。等待事件、TOP SQL等部分也是汇总了所有实例的数据。这对于诊断那些在实例间流动的全局缓存等待如“gc buffer busy”或跨实例的锁竞争问题至关重要。我曾经遇到过一个RAC系统应用反映时快时慢。查看单实例报告似乎都还行但打开全局报告后发现某个实例的“gc cr block busy”等待异常高最终定位是跨实例的块争用问题通过调整数据分布得以解决。4.2 多租户架构CDB PDB的报告收集Oracle 19c全面推行多租户架构。一个容器数据库CDB里可以包含多个可插拔数据库PDB。性能分析也需要在容器和插拔库两个层面进行。在CDB级别收集报告当你连接到CDB的根容器CDB$ROOT并运行awrrpt.sql时生成的是整个CDB的报告包含了所有PDB的汇总资源消耗以及根容器自身的活动。这对于监控整个数据库服务器的总体负载非常有用。在PDB级别收集报告这才是更常见的需求。你需要分析某个特定PDB比如某个业务应用的数据库的性能。方法很简单首先使用alter session set container命令切换到目标PDB然后再运行awrrpt.sql。-- 连接到CDB根容器 sqlplus / as sysdba -- 切换到特定的PDB ALTER SESSION SET CONTAINER SALESPDB; -- 生成该PDB的AWR报告 ?/rdbms/admin/awrrpt.sql这样生成的报告其数据完全来自于该PDB内部的活动。在19c中PDB级别的AWR报告也集成了该PDB的ASH和ADDM分析功能非常完整。这实现了真正的多租户资源隔离分析你可以清晰地看到是哪个PDB消耗了最多的I/O或CPU而不会受到其他PDB的干扰。4.3 对比报告让性能变化一目了然还有一种超级实用的报告AWR对比报告awrddrpt.sql用于单实例awrgdrpt.sql用于RAC。它用于比较两个不同时间段的性能。比如你今天优化了一条核心SQL想知道优化到底有没有效果你就可以生成一份对比报告将优化前的时段昨天10-11点和优化后的时段今天10-11点进行对比。报告会用清晰的差值Diff和百分比变化%Diff来展示关键指标的变化。你可以直接看到DB Time是否下降那条SQL的Elapsed Time per Exec是否减少buffer gets是否降低。这种直观的数据对比是验证优化效果、说服业务方最有力的证据。我每次做重大变更前后都会习惯性地保存快照ID以便后续做对比分析。5. 高级技巧与避坑指南掌握了基本操作和核心解读你已经能解决80%的性能问题。下面这些实战中积累的高级技巧和常见“坑点”能帮你把AWR报告用到极致提升诊断效率。技巧一手动创建快照捕捉瞬时问题。AWR默认每小时抓一次快照但如果问题突发在两次快照之间你就可能丢失关键数据。这时可以手动创建快照EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();执行后会返回一个快照ID。在问题发生前、后各手动创建一个快照然后用这两个快照ID生成报告就能精准分析问题时段。分析完后如果觉得这些手动快照没必要长期保存可以用DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE过程清理掉。技巧二关注“基线”Baseline建立性能标准。数据库在正常业务时段的性能表现可以作为“健康基线”。你可以使用DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE将一个好的性能时段比如上周二上午10-12点保存为基线。日后若出现性能下降可以生成当前时段与基线的对比报告快速发现哪些指标偏离了正常范围。这是做容量规划和性能趋势分析的好方法。技巧三深入ASH定位分钟级问题。如果性能问题只持续了几分钟在1小时的AWR报告里可能被“平均”掉而看不明显。这时候就要祭出ASH报告。在AWR报告的“附录”部分通常有生成ASH报告的链接或者你可以直接运行?/rdbms/admin/ashrpt.sql。ASH报告以每秒为单位采样活动会话能让你像看“慢动作回放”一样看清那几分钟内到底有哪些会话在等待什么事件执行什么SQL是分析瞬时尖峰的利器。避坑指南快照间隔与保留期默认快照保留8天每小时一次。对于非常繁忙的系统可以考虑缩短快照间隔如30分钟但会增加AWR资料库的存储开销。可以通过DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS过程来调整。生成报告时的常见错误如果提示“指定的开始快照和结束快照ID无效”请检查快照ID是否属于同一个数据库实例以及结束快照ID是否大于开始快照ID。在RAC环境下要确保使用的快照ID在所选实例上存在。报告文件太大打不开对于运行时间很长比如一天的快照间隔生成的HTML报告可能非常大几十MB。如果浏览器打开困难可以尝试生成text格式的报告或者使用active-html格式它有时会更高效。更根本的方法是尽量缩小分析的时间窗口聚焦问题发生的确切时段。不要孤立地看数字AWR报告里的任何一个高数值都不一定直接等于问题。比如高“db file scattered read”等待在多表全表扫描的并行查询中可能是正常的。一定要结合具体的SQL语句、业务场景和系统整体负载来综合判断。我见过不少新手DBA看到某个等待事件高就慌张其实那只是当时一个合理的批处理任务在运行。把AWR报告用熟、用透是每个Oracle DBA的必修课。它就像数据库给你的“自白书”里面记录了所有压力的来源。刚开始看可能会觉得复杂但只要你抓住Top 5等待事件、TOP SQL这几个牛鼻子多分析几份报告慢慢就能建立起直觉。下次数据库再喊“不舒服”你就能从容地拿出这份“体检报告”精准地找到病灶所在。