周传炽这期分享，源自我们重庆思庄在实际运维中经常被问到的一个高频问题：客户业务系统突然变慢，远程上去第一件事就是想先拉一份 AWR 报告看看趋势，可不少兄弟还在慢慢点 Enterprise Manager，或者打开 SQL*Plus 手动敲脚本，等报告出来业务高峰早都过去了。其实，Oracle 生成 AWR 报告本身就不该是个慢活儿，关键是你要把流程吃透，把该避的坑都避开，才能做到“一分钟出报告，报告出来就能看出个大概”。
这篇内容我会完整梳理 Oracle AWR 报告的快速生成方式，从快照原理、报告生成命令、常见报错到自动化思路一次讲透，适合刚从安装部署入门、需要自己做性能分析的使用者，也适合那些已经写过不少报告但偶尔被各种环境差异卡住的 DBA 同行。文章里所有命令我都基于 11g、12c、19c 做过验证，部分语句在更高版本同样适用，可以放心参考。
1. 先说清楚：为什么你总觉得生成 AWR 报告“不够快”
很多人对 AWR 报告的第一印象是“要等很久”，但等你把生成过程拆开看，就会发现真正耗时的从来不是报告生成那几秒，而是前面这些环节：
第一，快照时间窗口没选对。AWR 报告本质上是基于两个快照之间的采集数据做对比分析，如果你指定的起止快照时间跨度太大，比如从早上八点到晚上十点，那报告里的数据会被大量空闲时段稀释，看不出来问题；如果跨度太小，比如前后两个快照只隔五分钟，那很多时候统计信息还没凑够，同样没有分析价值。快照选得不合适，报告生成出来也白搭。
第二，很多人习惯打开 EM 网页控制台去点。不可否认，图形界面在某些场景下直观，但在生产环境尤其是数据库负载已经很高的时候，EM 自身是共享数据库资源的，你开一个页面就要多一组查询，要是数据库已经处于“喘不过气”的状态，打开 EM 可能都要半天。而且 EM 有时还会因为 agent 状态、权限配置等问题连不上，反而耽误事。
第三，如果数据库链接字符串、tnsnames 配置、用户权限这些基础项没搞清楚，你会反复卡在连接不上、权限不足这些报错上。等你在那一步步排查环境的时候，时间早就过去了。
所以，要做到“快速”，核心不在于手速，而在于你清楚整条链路：快照状态确认、报告类型选择、文件生成位置、内容快速解读。这篇后面就会按这个链路往下拆，每一步我都会补充实际运维中总结的经验。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. AWR 报告快速入门：快照的本质与生命周期管理
在真正开始手敲命令之前，建议先把 AWR 快照这套机制在脑子里过一遍。很多人会用 AWR 但说不清楚快照是什么时候创建的、能保留多久、为什么有时候手动执行创建快照会报错，这些坑我都踩过，这里一次讲清楚。
2.1 快照到底在采集什么
AWR 快照采集的核心，是数据库内部一系列性能统计视图的快照数据，比如会话活动、SQL 执行次数、等待事件、系统统计信息、段统计信息等。快照不是把整个数据库“拍照”备份，它采集的是一组与性能相关的计数器数值。每两个快照之间的差值，就是这段时间内数据库的真实活动情况。
这个设计思路有点像你家的电表：月初抄一次数字，月末再抄一次数字，差值就是你这个月用了多少电。AWR 报告就是通过两次“抄表”来还原数据库在某个时间段经历了什么。
数据库从 10g 开始默认开启 AWR，默认每个小时自动生成一个快照，快照在默认配置下保留 8 天。你可以通过以下方式查看当前数据库的快照频率和保留策略：
sql复制SELECT snap_interval, retention
FROM dba_hist_wr_control;
这里查出来的结果一般是这样：
| 参数 | 默认值 | 含义 |
|---|---|---|
| SNAP_INTERVAL | +00000 01:00:00.0 | 每 1 小时采集一次快照 |
| RETENTION | +00008 00:00:00.0 | 快照保留 8 天 |
| TOPNSQL | 30 | 默认采集 Top SQL 数量限制 |
2.2 手动创建快照的适用场景
自动快照颗粒度是 1 小时，理论上你生产环境每小时都留有采样点，但遇到下面这几种场景，手动创建快照就非常有必要：
场景一：业务方反馈“刚才那十几分钟系统特别卡”，现在已经恢复了。如果你不提前留快照点，等系统恢复后再去查，自动快照可能把“卡顿段”和“恢复段”混在同一个小时内，报告就看不出来当时的异常。这时候你应该在业务异常开始时立刻执行一次手动快照，等异常结束后再执行一次手动快照，两个快照就能精确定位异常窗口。
场景二：你准备做一次大的配置变更，比如调整 shared_pool 大小、加索引、修改 optimizer 模式。变更前打一个快照，变更后跑一段时间再打一个快照，这个对比报告就是你判断变更是否生效、有没有引入新问题的直接依据。
手动创建快照的命令只有一行：
sql复制EXEC dbms_workload_repository.create_snapshot();
执行完之后查一下最新的快照：
sql复制SELECT snap_id, begin_interval_time, end_interval_time
FROM dba_hist_snapshot
ORDER BY snap_id DESC
FETCH FIRST 5 ROWS ONLY;
这里提醒一下：不同 Oracle 版本对 FETCH 语法的支持不太一样，12c 及以后支持 FETCH FIRST，11g 可以用 ROWNUM <= 5 代替，我平时在两个版本间切换会注意这一点。
2.3 快照生命周期管理：保留策略与清理
生产库快照默认保留 8 天，8 天之前的历史快照会被自动清理。但有些场景下你要做长时间的性能对比，比如月底复盘整个月的趋势，你会发现 8 天根本不够。这时候需要修改保留策略：
sql复制BEGIN
dbms_workload_repository.modify_snapshot_settings(
retention => 43200, -- 单位是分钟，43200分钟即30天
interval => 30 -- 每 30 分钟采集一次
);
END;
/
修改完可以再用第一段里的查询确认一下生效情况。生产环境修改采集频率要慎重，快照间隔越短，AWR 表里的数据量增长越快，对 SYSAUX 表空间占用也会增加。如果 SYSAUX 空间本来就紧张，可能触发 Space 相关的告警，这块后续在常见问题里我会再展开讲。
3. 生成 AWR 报告的主流方式与选型对比
快照攒好了，接下来就是真正生成报告。很多人习惯直接敲 awrrpt.sql 脚本，但这只是其中一条路。我把实际工作中常用到的几种方式整理出来对比了一下，方便你根据场景选择。
3.1 命令行交互式执行 awrrpt.sql，最通用的做法
这是绝大多数 Oracle 手册里会写到的标准方法，也是我在客户服务器上最常用的应急手段。11g、12c、19c 的白名单机制下，脚本路径基本一致，但要注意统一放在 $ORACLE_HOME/rdbms/admin 目录下。
操作流程在命令行里就是：
sql复制sqlplus / as sysdba
SQL> @?/rdbms/admin/awrrpt.sql
执行时会依次提示你输入：
- 报告类型：
html还是 `tex