简介这份PDF文档面向Oracle数据库管理员与运维工程师系统讲解AWRAutomatic Workload Repository报告的解读方法帮助定位数据库性能瓶颈、优化配置。内容围绕WORKLOAD REPOSITORY report展开涵盖DB Name、Snap Id、Elapsed与DB Time等关键字段含义并通过Report A与Report B的对比案例演示如何用DB Time与CPU时间比值判断系统负载高低同时讲解Buffer Cache、Shared Pool Size、Log Buffer等SGA区域信息与初始参数的比对思路以及Load Profile中Redo size、Logical reads、Hard parses等指标的分析要点并强调选择代表性快照时间段的重要性。资源为1个PDF文件压缩包约1.18MB结构紧凑便于随时查阅。目前已有580人学习下载适合需要掌握AWR报告分析、排查批量系统性能问题的DBA参考。1. 从一份 OracleAWR报告详细分析.pdf 说起性能排查到底该看哪几页很多人拿到一份OracleAWR报告详细分析.pdf第一反应是从头翻到尾结果被上百页的指标淹没最后只记住几个「DB Time 很高」的结论。真实场景里AWR 报告不是用来通读的而是用来回答一个具体问题的过去某个时间段数据库到底把时间花在哪了。它解决的是「事后复盘」——故障已经发生、业务方在催、你手上只有一份快照区间需要快速定位是 SQL、等待事件还是配置问题。适合谁适合每天要盯 Oracle 数据库的 DBA、后端开发和运维尤其是刚接手一套陌生库、需要在一两个小时内给出结论的人。这份 PDF 的价值不在页数而在于你能不能按固定路径把 Top 事件、Top SQL、负载概要三块串起来。下面我按自己排查时的顺序把这份报告拆成可复现的步骤。2. 先立住理论AWR 快照、DB Time 与等待模型怎么读2.1 AWR 快照的采集机制与报告区间含义AWR 的本质是 Oracle 后台进程 MMON 周期性把内存里的性能统计刷到 SYSAUX 表空间默认每小时一个快照保留 8 天。你手上这份 PDF 的头部会写明Begin Snap和End Snap两个编号以及对应时间这个区间决定了后面所有数字的统计口径。很多人忽略一点如果区间跨了业务高峰和低谷平均值会被稀释Top 事件看起来「都不高」实际高峰段早就爆了。所以第一步永远是确认区间必要时用DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动打一个快照把区间卡在故障发生的那 30 分钟里。-- 查看现有快照确认故障时间点附近有没有可用区间 SELECT snap_id, TO_CHAR(begin_interval_time,YYYY-MM-DD HH24:MI) AS begin_time, TO_CHAR(end_interval_time,YYYY-MM-DD HH24:MI) AS end_time FROM dba_hist_snapshot WHERE begin_interval_time SYSDATE - 2 ORDER BY snap_id;这段查询的作用是列出最近两天的快照边界。snap_id是快照编号生成报告时用?/rdbms/admin/awrrpt.sql输入起止编号即可。参数上注意SYSDATE - 2控制回溯窗口库大时dba_hist_snapshot数据量不小别一上来就查全表。如果发现故障时段没有快照说明采集间隔被改过或实例重启过这时候只能靠 ASH 或告警日志补别硬拿一个错区间的报告下结论。2.2 DB Time 与 Elapsed Time判断负载的第一把尺报告开头的「Load Profile」和「Top 10 Foreground Events by Total Wait Time」是核心。DB Time 是所有前台会话消耗的数据库时间总和Elapsed Time 是墙上时钟。两者比值反映并发度DB Time 远大于 Elapsed说明并发高、排队严重DB Time 接近 Elapsed说明负载轻。我一般先算DB Time / Elapsed再乘上 CPU 核数粗略判断是否已经打满。比如 8 核机器比值 6意味着平均有 6 个会话在同时干活还没到瓶颈比值 30 就要警惕了。等待模型是 AWR 的灵魂任何一次响应时间都能拆成 CPU 时间加等待时间。报告里% DB Time那一列告诉你哪个等待事件吃掉了最多时间。常见的有db file sequential read索引单块读、db file scattered read全表扫描多块读、log file sync提交等待、enq: TX - row lock contention行锁。看到db file sequential read排第一别急着加索引先看 Top SQL 是不是某条语句执行次数暴涨很多时候是执行计划突变导致的。2.3 从 Top SQL 到执行计划把等待落到具体语句Top SQL 分两种排序按 Elapsed Time 和按 CPU Time。前者适合找「拖慢整体」的语句后者适合找「吃 CPU」的语句。点开某条 SQL 的SQL_ID报告里会给出执行次数、每次执行耗时、物理读、逻辑读。逻辑读高说明内存里反复扫物理读高说明缓存没命中。真正定位要拿到执行计划用DBMS_XPLAN.DISPLAY_AWR按 SQL_ID 和历史快照查。-- 用 SQL_ID 和历史快照号还原当时的执行计划 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR( sql_id 8knh2t3v9xq1p, plan_hash_value NULL, format ALL));sql_id从报告里直接抄plan_hash_value留空会列出该语句所有历史计划方便对比是否发生计划翻转。format ALL会带出谓词信息和成本排查时比默认格式有用得多。注意DISPLAY_AWR依赖 AWR 里保存的计划如果语句被刷出共享池且没进 AWR就查不到这时候只能靠 SQL 文本反推。3. 动手复现从 PDF 到可执行排查路径3.1 生成一份可对比的 AWR 报告拿到 PDF 只是结果要复现分析过程得自己生成报告。用awrrpt.sql交互式输入起止快照和输出格式选 html 便于展开选 text 便于 grep。生产库上我一般用脚本批量生成避免手抖选错区间。# 在数据库服务器上以 sysdba 身份执行生成文本格式报告 sqlplus -S / as sysdba EOF set pagesize 0 linesize 200 trimspool on set feedback off heading off spool /tmp/awr_12345_12346.txt ?/rdbms/admin/awrrpt.sql EOF交互过程中依次输入报告类型text、起始快照号、结束快照号、输出文件名。spool把结果落到/tmp方便后续用grep抓 Top 事件。参数上pagesize 0是为了避免分页符干扰文本解析。如果库是 RAC要用awrrpt.sql的 rac 版本或指定实例否则拿到的是聚合数据定位不到具体节点。3.2 用 grep 和 awk 快速抽取关键段落一份 text 报告几百 KB人工翻太慢。我习惯用命令行先抓骨架Top 事件、Top SQL、Load Profile 三段。# 抽取 Top 10 前台等待事件段落 awk /Top 10 Foreground Events/,/^$/ /tmp/awr_12345_12346.txt | head -30 # 抽取按 Elapsed Time 排序的 SQL 段落 awk /SQL ordered by Elapsed Time/,/^$/ /tmp/awr_12345_12346.txt | head -40awk的范围匹配靠段落标题head限制行数防止刷屏。这样能在几十秒内看到关键指标。注意不同 Oracle 版本段落标题措辞略有差异11g 和 19c 的Top 10 Foreground Events基本一致但 SQL 段落标题可能带SQL ordered by Elapsed Time或SQL ordered by CPU Time抓之前先grep -n SQL ordered确认。3.3 把等待事件映射到可操作项抓到 Top 事件后要能翻译成动作。下面这张表是我常用的映射覆盖大部分场景。等待事件常见原因优先动作db file sequential read索引单块读多、索引选择差查 Top SQL 执行计划评估索引db file scattered read全表扫描、缺少索引看是否大表全扫考虑分区或索引log file sync提交频繁、日志盘慢批量提交、检查 redo 盘 IOenq: TX - row lock contention行锁冲突、事务过长查阻塞会话缩短事务library cache lock硬解析多、共享池争用绑定变量、加大 shared_pool这张表不是让你照搬而是建立「事件到动作」的条件反射。比如log file sync高先看user commits是不是每秒几千次如果是应用层逐条提交改成批量提交比换 SSD 更有效。3.4 用 ASH 补 AWR 的粒度盲区AWR 是小时级平均值故障往往只持续几分钟这时候 ASH 更管用。ASH 每秒采样一次活动会话能精确到秒。报告里如果有Top Activity或 ASH 部分直接看时间轴上的尖峰。没有的话用dba_hist_active_sess_history查。-- 按分钟统计某时段的活动会话数和主要等待事件 SELECT TO_CHAR(sample_time,HH24:MI) AS minute, COUNT(*) AS active_sessions, event FROM dba_hist_active_sess_history WHERE sample_time BETWEEN TO_TIMESTAMP(2024-05-01 10:00,YYYY-MM-DD HH24:MI) AND TO_TIMESTAMP(2024-05-01 10:30,YYYY-MM-DD HH24:MI) GROUP BY TO_CHAR(sample_time,HH24:MI), event ORDER BY minute, active_sessions DESC;sample_time是采样时间点event是会话当时的等待事件。按分钟聚合能看出哪个事件在尖峰时刻占主导。参数上时间范围别拉太长ASH 数据量大查一天以上会慢。这个查询能补上 AWR 平均值掩盖的瞬时问题。4. 避坑与排查AWR 分析里最容易翻车的五件事4.1 区间选错结论全废现象报告显示 DB Time 平稳但业务方坚称当时卡死。原因快照区间跨了高峰和低谷平均值被拉平。解决先用dba_hist_snapshot确认故障时间点重新生成只覆盖故障时段的报告必要时手动打快照。4.2 把 DB Time 高直接等同于数据库慢现象DB Time 很高但用户没感知。原因DB Time 是累计值并发高时自然大不代表单次响应慢。解决结合Average Active Sessions和User Calls看如果 AAS 高但每次调用耗时正常说明是吞吐量大而非性能问题。4.3 Top SQL 按 Elapsed 排序漏掉高频小语句现象按 Elapsed Time 排第一的语句优化完整体没改善。原因一条执行 10 万次、每次 1ms 的语句总耗时可能超过一条执行 1 次、耗时 5s 的语句。解决同时看按Executions和CPU Time排序的段落高频小语句往往才是 CPU 杀手。4.4 忽略硬解析和版本计数现象CPU 高但 Top SQL 都不慢。原因大量硬解析消耗 CPU报告里Hard Parses和Version Count偏高。解决检查是否没用绑定变量Version Count高的 SQL 要查v$sql_shared_cursor看不能共享的原因。4.5 拿 RAC 聚合报告定位单节点问题现象RAC 环境报告显示负载均衡但某个节点明显慢。原因默认 AWR 报告是实例聚合掩盖了节点差异。解决生成报告时指定INSTANCE_NUMBER或分别生成各实例报告对比重点看gc相关等待事件。5. 进阶技巧用基线对比和 SQL 监控把分析做在前面AWR 最被低估的功能是基线Baseline。与其等故障发生再翻报告不如在系统稳定时打一个基线之后拿故障时段和基线对比差异一目了然。用DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE创建报告里选Compare Period就能看到两个时段的指标差值。-- 把当前快照区间创建为基线命名 PEAK_BASELINE BEGIN DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE( start_snap_id 12345, end_snap_id 12346, baseline_name PEAK_BASELINE); END; /start_snap_id和end_snap_id选业务高峰但运行正常的时段这样基线代表「健康状态」。之后生成报告时选Compare Period把故障时段和基线对比Top 事件的增量、SQL 执行次数的变化都会列出来。参数上基线名别用中文避免脚本处理时编码问题。另一个技巧是开启 SQL 监控。对于执行时间超过 5 秒的语句Oracle 会自动生成 SQL Monitor 报告比 AWR 更细能看到每个执行步骤的实际行数和预估行数差异。-- 查看最近一次 SQL 监控报告 SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR( sql_id 8knh2t3v9xq1p, type ACTIVE) FROM dual;type ACTIVE返回 HTML 格式带执行计划和时间轴能直接看出哪一步耗时最长、哪一步行数估算偏差大。偏差大的步骤往往是统计信息过期或绑定变量窥探导致这时候收集统计信息或加 hint 比盲目加索引有效。我自己踩过最深的一个坑是早期只看 AWR 的 Top 事件就下结论结果把一条db file sequential read高的语句加了索引反而让另一条语句计划变差。后来养成习惯任何改动前先用DISPLAY_AWR把相关 SQL 的历史计划都拉出来对比确认改动不会引发计划翻转再动手。AWR 报告是黑匣子但读法有固定套路按区间、DB Time、等待、Top SQL、执行计划这条线走基本不会跑偏。希望帮到你。本文还有配套的精品资源点击获取
Oracle AWR报告详细分析：从PDF到可执行排查路径
简介这份PDF文档面向Oracle数据库管理员与运维工程师系统讲解AWRAutomatic Workload Repository报告的解读方法帮助定位数据库性能瓶颈、优化配置。内容围绕WORKLOAD REPOSITORY report展开涵盖DB Name、Snap Id、Elapsed与DB Time等关键字段含义并通过Report A与Report B的对比案例演示如何用DB Time与CPU时间比值判断系统负载高低同时讲解Buffer Cache、Shared Pool Size、Log Buffer等SGA区域信息与初始参数的比对思路以及Load Profile中Redo size、Logical reads、Hard parses等指标的分析要点并强调选择代表性快照时间段的重要性。资源为1个PDF文件压缩包约1.18MB结构紧凑便于随时查阅。目前已有580人学习下载适合需要掌握AWR报告分析、排查批量系统性能问题的DBA参考。1. 从一份 OracleAWR报告详细分析.pdf 说起性能排查到底该看哪几页很多人拿到一份OracleAWR报告详细分析.pdf第一反应是从头翻到尾结果被上百页的指标淹没最后只记住几个「DB Time 很高」的结论。真实场景里AWR 报告不是用来通读的而是用来回答一个具体问题的过去某个时间段数据库到底把时间花在哪了。它解决的是「事后复盘」——故障已经发生、业务方在催、你手上只有一份快照区间需要快速定位是 SQL、等待事件还是配置问题。适合谁适合每天要盯 Oracle 数据库的 DBA、后端开发和运维尤其是刚接手一套陌生库、需要在一两个小时内给出结论的人。这份 PDF 的价值不在页数而在于你能不能按固定路径把 Top 事件、Top SQL、负载概要三块串起来。下面我按自己排查时的顺序把这份报告拆成可复现的步骤。2. 先立住理论AWR 快照、DB Time 与等待模型怎么读2.1 AWR 快照的采集机制与报告区间含义AWR 的本质是 Oracle 后台进程 MMON 周期性把内存里的性能统计刷到 SYSAUX 表空间默认每小时一个快照保留 8 天。你手上这份 PDF 的头部会写明Begin Snap和End Snap两个编号以及对应时间这个区间决定了后面所有数字的统计口径。很多人忽略一点如果区间跨了业务高峰和低谷平均值会被稀释Top 事件看起来「都不高」实际高峰段早就爆了。所以第一步永远是确认区间必要时用DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT手动打一个快照把区间卡在故障发生的那 30 分钟里。-- 查看现有快照确认故障时间点附近有没有可用区间 SELECT snap_id, TO_CHAR(begin_interval_time,YYYY-MM-DD HH24:MI) AS begin_time, TO_CHAR(end_interval_time,YYYY-MM-DD HH24:MI) AS end_time FROM dba_hist_snapshot WHERE begin_interval_time SYSDATE - 2 ORDER BY snap_id;这段查询的作用是列出最近两天的快照边界。snap_id是快照编号生成报告时用?/rdbms/admin/awrrpt.sql输入起止编号即可。参数上注意SYSDATE - 2控制回溯窗口库大时dba_hist_snapshot数据量不小别一上来就查全表。如果发现故障时段没有快照说明采集间隔被改过或实例重启过这时候只能靠 ASH 或告警日志补别硬拿一个错区间的报告下结论。2.2 DB Time 与 Elapsed Time判断负载的第一把尺报告开头的「Load Profile」和「Top 10 Foreground Events by Total Wait Time」是核心。DB Time 是所有前台会话消耗的数据库时间总和Elapsed Time 是墙上时钟。两者比值反映并发度DB Time 远大于 Elapsed说明并发高、排队严重DB Time 接近 Elapsed说明负载轻。我一般先算DB Time / Elapsed再乘上 CPU 核数粗略判断是否已经打满。比如 8 核机器比值 6意味着平均有 6 个会话在同时干活还没到瓶颈比值 30 就要警惕了。等待模型是 AWR 的灵魂任何一次响应时间都能拆成 CPU 时间加等待时间。报告里% DB Time那一列告诉你哪个等待事件吃掉了最多时间。常见的有db file sequential read索引单块读、db file scattered read全表扫描多块读、log file sync提交等待、enq: TX - row lock contention行锁。看到db file sequential read排第一别急着加索引先看 Top SQL 是不是某条语句执行次数暴涨很多时候是执行计划突变导致的。2.3 从 Top SQL 到执行计划把等待落到具体语句Top SQL 分两种排序按 Elapsed Time 和按 CPU Time。前者适合找「拖慢整体」的语句后者适合找「吃 CPU」的语句。点开某条 SQL 的SQL_ID报告里会给出执行次数、每次执行耗时、物理读、逻辑读。逻辑读高说明内存里反复扫物理读高说明缓存没命中。真正定位要拿到执行计划用DBMS_XPLAN.DISPLAY_AWR按 SQL_ID 和历史快照查。-- 用 SQL_ID 和历史快照号还原当时的执行计划 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR( sql_id 8knh2t3v9xq1p, plan_hash_value NULL, format ALL));sql_id从报告里直接抄plan_hash_value留空会列出该语句所有历史计划方便对比是否发生计划翻转。format ALL会带出谓词信息和成本排查时比默认格式有用得多。注意DISPLAY_AWR依赖 AWR 里保存的计划如果语句被刷出共享池且没进 AWR就查不到这时候只能靠 SQL 文本反推。3. 动手复现从 PDF 到可执行排查路径3.1 生成一份可对比的 AWR 报告拿到 PDF 只是结果要复现分析过程得自己生成报告。用awrrpt.sql交互式输入起止快照和输出格式选 html 便于展开选 text 便于 grep。生产库上我一般用脚本批量生成避免手抖选错区间。# 在数据库服务器上以 sysdba 身份执行生成文本格式报告 sqlplus -S / as sysdba EOF set pagesize 0 linesize 200 trimspool on set feedback off heading off spool /tmp/awr_12345_12346.txt ?/rdbms/admin/awrrpt.sql EOF交互过程中依次输入报告类型text、起始快照号、结束快照号、输出文件名。spool把结果落到/tmp方便后续用grep抓 Top 事件。参数上pagesize 0是为了避免分页符干扰文本解析。如果库是 RAC要用awrrpt.sql的 rac 版本或指定实例否则拿到的是聚合数据定位不到具体节点。3.2 用 grep 和 awk 快速抽取关键段落一份 text 报告几百 KB人工翻太慢。我习惯用命令行先抓骨架Top 事件、Top SQL、Load Profile 三段。# 抽取 Top 10 前台等待事件段落 awk /Top 10 Foreground Events/,/^$/ /tmp/awr_12345_12346.txt | head -30 # 抽取按 Elapsed Time 排序的 SQL 段落 awk /SQL ordered by Elapsed Time/,/^$/ /tmp/awr_12345_12346.txt | head -40awk的范围匹配靠段落标题head限制行数防止刷屏。这样能在几十秒内看到关键指标。注意不同 Oracle 版本段落标题措辞略有差异11g 和 19c 的Top 10 Foreground Events基本一致但 SQL 段落标题可能带SQL ordered by Elapsed Time或SQL ordered by CPU Time抓之前先grep -n SQL ordered确认。3.3 把等待事件映射到可操作项抓到 Top 事件后要能翻译成动作。下面这张表是我常用的映射覆盖大部分场景。等待事件常见原因优先动作db file sequential read索引单块读多、索引选择差查 Top SQL 执行计划评估索引db file scattered read全表扫描、缺少索引看是否大表全扫考虑分区或索引log file sync提交频繁、日志盘慢批量提交、检查 redo 盘 IOenq: TX - row lock contention行锁冲突、事务过长查阻塞会话缩短事务library cache lock硬解析多、共享池争用绑定变量、加大 shared_pool这张表不是让你照搬而是建立「事件到动作」的条件反射。比如log file sync高先看user commits是不是每秒几千次如果是应用层逐条提交改成批量提交比换 SSD 更有效。3.4 用 ASH 补 AWR 的粒度盲区AWR 是小时级平均值故障往往只持续几分钟这时候 ASH 更管用。ASH 每秒采样一次活动会话能精确到秒。报告里如果有Top Activity或 ASH 部分直接看时间轴上的尖峰。没有的话用dba_hist_active_sess_history查。-- 按分钟统计某时段的活动会话数和主要等待事件 SELECT TO_CHAR(sample_time,HH24:MI) AS minute, COUNT(*) AS active_sessions, event FROM dba_hist_active_sess_history WHERE sample_time BETWEEN TO_TIMESTAMP(2024-05-01 10:00,YYYY-MM-DD HH24:MI) AND TO_TIMESTAMP(2024-05-01 10:30,YYYY-MM-DD HH24:MI) GROUP BY TO_CHAR(sample_time,HH24:MI), event ORDER BY minute, active_sessions DESC;sample_time是采样时间点event是会话当时的等待事件。按分钟聚合能看出哪个事件在尖峰时刻占主导。参数上时间范围别拉太长ASH 数据量大查一天以上会慢。这个查询能补上 AWR 平均值掩盖的瞬时问题。4. 避坑与排查AWR 分析里最容易翻车的五件事4.1 区间选错结论全废现象报告显示 DB Time 平稳但业务方坚称当时卡死。原因快照区间跨了高峰和低谷平均值被拉平。解决先用dba_hist_snapshot确认故障时间点重新生成只覆盖故障时段的报告必要时手动打快照。4.2 把 DB Time 高直接等同于数据库慢现象DB Time 很高但用户没感知。原因DB Time 是累计值并发高时自然大不代表单次响应慢。解决结合Average Active Sessions和User Calls看如果 AAS 高但每次调用耗时正常说明是吞吐量大而非性能问题。4.3 Top SQL 按 Elapsed 排序漏掉高频小语句现象按 Elapsed Time 排第一的语句优化完整体没改善。原因一条执行 10 万次、每次 1ms 的语句总耗时可能超过一条执行 1 次、耗时 5s 的语句。解决同时看按Executions和CPU Time排序的段落高频小语句往往才是 CPU 杀手。4.4 忽略硬解析和版本计数现象CPU 高但 Top SQL 都不慢。原因大量硬解析消耗 CPU报告里Hard Parses和Version Count偏高。解决检查是否没用绑定变量Version Count高的 SQL 要查v$sql_shared_cursor看不能共享的原因。4.5 拿 RAC 聚合报告定位单节点问题现象RAC 环境报告显示负载均衡但某个节点明显慢。原因默认 AWR 报告是实例聚合掩盖了节点差异。解决生成报告时指定INSTANCE_NUMBER或分别生成各实例报告对比重点看gc相关等待事件。5. 进阶技巧用基线对比和 SQL 监控把分析做在前面AWR 最被低估的功能是基线Baseline。与其等故障发生再翻报告不如在系统稳定时打一个基线之后拿故障时段和基线对比差异一目了然。用DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE创建报告里选Compare Period就能看到两个时段的指标差值。-- 把当前快照区间创建为基线命名 PEAK_BASELINE BEGIN DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE( start_snap_id 12345, end_snap_id 12346, baseline_name PEAK_BASELINE); END; /start_snap_id和end_snap_id选业务高峰但运行正常的时段这样基线代表「健康状态」。之后生成报告时选Compare Period把故障时段和基线对比Top 事件的增量、SQL 执行次数的变化都会列出来。参数上基线名别用中文避免脚本处理时编码问题。另一个技巧是开启 SQL 监控。对于执行时间超过 5 秒的语句Oracle 会自动生成 SQL Monitor 报告比 AWR 更细能看到每个执行步骤的实际行数和预估行数差异。-- 查看最近一次 SQL 监控报告 SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR( sql_id 8knh2t3v9xq1p, type ACTIVE) FROM dual;type ACTIVE返回 HTML 格式带执行计划和时间轴能直接看出哪一步耗时最长、哪一步行数估算偏差大。偏差大的步骤往往是统计信息过期或绑定变量窥探导致这时候收集统计信息或加 hint 比盲目加索引有效。我自己踩过最深的一个坑是早期只看 AWR 的 Top 事件就下结论结果把一条db file sequential read高的语句加了索引反而让另一条语句计划变差。后来养成习惯任何改动前先用DISPLAY_AWR把相关 SQL 的历史计划都拉出来对比确认改动不会引发计划翻转再动手。AWR 报告是黑匣子但读法有固定套路按区间、DB Time、等待、Top SQL、执行计划这条线走基本不会跑偏。希望帮到你。本文还有配套的精品资源点击获取
