Oracle 11g的自动数据库诊断监视器（ADDM）并不是一个独立运行的工具，而是AWR快照采集体系中的智能分析层。每次AWR生成新快照后，ADDM会自动比较相邻快照之间的数据库时间（DB time）分布，找出对性能影响最大的问题，并给出修复建议。过去DBA拿到AWR报告后需要逐项排查等待事件和SQL统计，而ADDM将这一过程自动化。AWR基线则进一步把这套诊断从单次比较升级为趋势对比，让DBA能够判断当前性能问题是否属于异常偏离。只有理解二者的数据来源和协作方式，才能在实际运维中高效使用。
在Oracle 11g中，ADDM和AWR基线都得到了增强。ADDM新增了实时分析能力和更精细的RAC全局分析；AWR基线则支持移动窗口基线和基线模板，使得性能基线的维护更加自动化。本文将围绕这两个新特性展开，说明它们如何协同工作，并通过实际示例展示从创建基线到定位SQL瓶颈的完整过程。
ADDM与AWR基线如何协同工作
AWR（自动工作负载仓库）以快照形式保存实例的性能数据，包括等待事件、时间模型、SQL统计、活动会话历史等。默认情况下，快照每小时采集一次，并保留8天。ADDM在每次AWR快照完成后自动运行，它读取两个相邻快照之间的数据，计算出数据库时间在各维度上的占比。数据库时间是ADDM分析的核心指标，它表示前台进程消耗的总时间，包括CPU时间和所有非空闲等待时间。ADDM会按照占比从高到低列出问题，这些问题被称为Findings。
AWR基线的作用是给ADDM提供一个参照系。没有基线时，ADDM只能告诉你当前两个快照之间有哪些高消耗项，但无法判断这些高消耗是否正常。例如，一个批处理作业每天凌晨都会运行，消耗大量CPU，这是预期行为；如果ADDM每次都报告同样的SQL，DBA容易陷入报警疲劳。而通过创建基线，DBA可以保存健康运行态的快照区间，后续分析时可以将当前快照与基线快照进行对比，只有当指标明显偏离基线时，才被认定为异常。这种对比机制大幅减少了误报，也让ADDM的建议更有针对性。
Oracle 11g在AWR基线方面引入了移动窗口基线。系统默认存在一个窗口大小为8天的移动基线，也就是说，过去8天的所有AWR快照会自动构成基线。当ADDM或服务器生成的预警检测到指标超过自适应阈值时，就会结合移动窗口基线判断偏离程度。自适应阈值解决了传统固定阈值无法适应业务波动的难题，它会根据移动窗口基线的统计分布动态计算告警界限，使得告警更加贴合实际负载。
创建与管理AWR基线的实践方法
Oracle 11g支持两类主要基线：静态基线和移动窗口基线。静态基线由DBA手工指定起始快照和结束快照，适用于保存一次典型业务高峰或一次版本升级前的性能状态。创建静态基线的常用方式是调用DBMS_WORKLOAD_REPOSITORY包的CREATE_BASELINE过程。以下代码将快照100到快照120创建为一个名为NORMAL_WEEKDAY_BASELINE的基线，并设置过期时间为30天。
BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(
start_snap_id => 100,
end_snap_id => 120,
baseline_name => 'NORMAL_WEEKDAY_BASELINE',
expiration => 30
);
END;
/
创建完成后，可以通过DBA_HIST_BASELINE视图查询基线信息，包括基线名称、类型、起始快照ID、结束快照ID以及过期时间。基线类型字段BASELINE_TYPE在11g中可能显示为STATIC或MOVING_WINDOW。移动窗口基线的窗口大小默认为8天，可以根据业务周期调整，例如将窗口大小改为7天，使其与一周的业务波动保持一致。修改窗口大小使用MODIFY_BASELINE_WINDOW_SIZE过程。
BEGIN
DBMS_WORKLOAD_REPOSITORY.MODIFY_BASELINE_WINDOW_SIZE(
window_size => 7
);
END;
/
除了静态基线和移动窗口基线，Oracle 11g还提供了基线模板功能。基线模板允许DBA定义一个重复的时间周期，例如每周一凌晨1点到3点，系统会在每个周期自动创建相应的基线。这种方式非常适合具有规律性批处理作业的环境。创建基线模板可以使用DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE过程。它减少了手工操作，确保基线始终覆盖关键业务窗口。管理基线时，DBA需要定期查看过期基线并清理，或者使用DROP_BASELINE过程删除不再需要的基线，以节省AWR存储空间。
解读ADDM报告并利用基线偏离定位问题
生成ADDM报告最简单的方法是在SQL*Plus中运行Oracle自带的addmrpt.sql脚本，该脚本位于$ORACLE_HOME/rdbms/admin目录下。运行后脚本会提示输入起始快照ID和结束快照ID，然后生成一份文本报告。报告的核心内容是Findings列表，每一条Finding包含问题描述、影响的数据库时间百分比以及建议操作。典型的Finding可能包括：SQL语句消耗大量CPU、存在严重的日志文件同步等待、I/O子系统响应过慢、某些会话持有锁竞争等。DBA需要优先处理数据库时间占比最高的Finding。
结合基线分析时，不能只看当前ADDM报告中的绝对值，还要对比基线时段的指标。例如，当前ADDM报告发现某条SQL的CPU时间占比为45%，但如果基线中该SQL在相同业务时段的CPU时间占比通常在40%到50%之间，那么这条SQL很可能不是新出现的问题，而是常规负载的一部分。相反，如果基线中该SQL平均占比只有10%，而当前报告达到45%，则说明SQL执行计划发生变化或者业务量激增，需要进一步分析。这种对比可以通过查询DBA_HIST_SYSMETRIC_SUMMARY视图完成，该视图保存了系统指标的统计汇总，可以按基线时间段和当前时间段分别取出平均值和最大值。
SELECT metric_name, average, maxval FROM dba_hist_sysmetric_summary WHERE snap_id BETWEEN 200 AND 210 AND metric_name = 'Host CPU Utilization (%)' ORDER BY snap_id;
更直接的方法是使用DBMS_WORKLOAD_REPOSITORY包中与基线相关的函数，例如SELECT_BASELINE_DETAILS可以返回基线区间内指定指标的具体数值。通过将当前快照区间的相同指标放在一起比较，DBA可以直观地看到偏离程度。实践中，建议将基线对比的结果与ADDM报告交叉验证，因为基线偏离只说明负载发生了变化，而ADDM能够解释变化背后的原因。两者结合能够大幅提高性能诊断的准确率和效率。
实战案例：从基线偏离到SQL优化
假设某系统运行在Oracle 11g上，DBA已创建一个覆盖正常工作日的静态基线。某个周三下午，业务人员反馈订单查询页面响应变慢。DBA首先查看当前时段与基线时段的数据库时间对比，发现当前时段的CPU使用率和DB time都明显高于基线平均值。接着生成该问题时段前后两个快照之间的ADDM报告，报告第一条Finding指向一个SQL_ID为abc123的SQL语句，称其消耗了60%的数据库时间，并且执行次数大幅增加。
为了确认这是否属于异常偏离，DBA查询AWR中的SQL统计历史，分别取出基线时段和当前时段该SQL的执行次数、CPU时间和缓冲区获取次数。比较后发现，当前时段该SQL的执行次数只比基线增加了20%，但每次执行的缓冲区获取次数却增加了5倍，说明执行计划可能发生了变化。进一步查看该SQL的执行计划历史，发现优化器从索引范围扫描变成了全表扫描。原因是相关表在近期完成了大量数据加载，统计信息未及时更新，导致优化器错误估算返回行数。
SELECT snap_id, executions_delta, cpu_time_delta,
elapsed_time_delta, buffer_gets_delta
FROM dba_hist_sqlstat
WHERE sql_id = 'abc123'
AND snap_id BETWEEN 200 AND 220
ORDER BY snap_id;
定位到根因后，DBA可以采取两种修复动作：立即收集相关表的统计信息，或者使用SQL Profile固定原有高效执行计划。如果业务不允许停机，可以先手动执行DBMS_STATS收集统计信息，让优化器重新选择正确的索引路径。之后再次生成ADDM报告，确认该SQL的数据库时间占比已经回落到基线正常范围内。这个案例说明，ADDM提供了问题定位的入口，而AWR基线则提供了正常性能的参考标准，两者配合能够快速区分常规波动与真正需要干预的异常。
在Oracle 11g环境中，建议将移动窗口基线保持默认或按业务周期调整，同时对关键业务时段创建静态基线和基线模板。每次性能排查时，先通过基线偏离判断是否异常，再通过ADDM报告深入根因。这种结构化的诊断方式比单独查看AWR报告或依赖经验判断更加可靠，尤其适合需要快速响应的生产环境。
Oracle 11gADDMAWR基线修改时间：2026-08-19 08:35:56