Oracle数据库的性能诊断工作中，Statspack和AWR（Automatic Workload Repository）是两个绕不开的工具。很多DBA在接手一套新环境时，第一个问题就是：这套库到底该用Statspack采集还是直接依赖AWR？要回答这个问题，需要先理解两者的来龙去脉。AWR是Oracle 10g引入的自动负载信息库，依赖初始化参数STATISTICS_LEVEL和后台进程MMON自动采集快照；而Statspack是9i时代的产物，通过一组SQL脚本手工安装和执行快照。两者在数据来源上高度重合，都基于时间模型和各类等待事件统计，但授权要求、采集粒度、报表细节差异明显。
授权成本与适用版本的差异
AWR属于Oracle企业版的诊断包（Diagnostics Pack）功能，使用它需要购买相应授权。这一点经常被忽视：如果数据库是企业版但没买诊断包，开启了AWR自动快照在审计上是有合规风险的。Oracle提供了一个参数CONTROL_MANAGEMENT_PACK_ACCESS，将其设置为NONE可以禁用诊断包相关功能，避免误用。而对于标准版用户，AWR本身就不可用，Statspack成了唯一选择，因为Statspack基于DBMS_STATS和底层视图采集，脚本完全免费，不涉及额外授权。
从版本演进看，Statspack从8.1.7开始提供，到9i全面成熟，10g以后虽然AWR成为主角，但Statspack脚本仍然随数据库软件发布，位于rdbms/admin目录下，比如spcreate.sql、spreport.sql等。换句话说，Statspack在最新的19c、21c里依然可以安装使用，它并不是被废弃的功能，而是Oracle为无诊断包用户保留的官方采集方案。这种定位决定了两者的选择逻辑：有授权就优先AWR，没授权或标准版就用Statspack。
安装配置与快照机制对比
AWR基本零配置。只要STATISTICS_LEVEL设置为TYPICAL或ALL，MMON进程默认每小时自动打一个快照，保留8天（由INTERVAL和RETENTION参数控制），可以通过DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS调整。自动化的好处是出问题时数据一定在，坏处是默认1小时间隔对于短促的性能抖动来说太粗糙，需要临时手工补快照。
Statspack则需要手工搭建。安装时以sysdba登录，指定一个独立的表空间（建议PERFSTAT用户专用，避免污染SYSTEM），然后执行spcreate.sql：
-- 使用spauto.sql设置每小时自动采集 SQL> @?/rdbms/admin/spcreate -- 输入表空间与临时表空间 -- 完成后执行快照 SQL> execute statspack.snap; -- 生成两个快照之间的报告 SQL> @?/rdbms/admin/spreport
Statspack的快照级别从0到10不等，级别5是默认值，采集SQL语句的统计；级别6会额外采集执行计划；级别7开始包含段级统计。采集级别越高，快照耗时和空间占用越大。这种可调节性是Statspack的特点，AWR则没有这么细粒度的级别控制，它始终采集较为完整的指标集合，代价是持续的内存与磁盘开销。另外需要注意，Statspack和AWR可以共存，但要设置不同的快照间隔，避免两个工具同时打快照引发锁竞争。
报告内容与关键指标解读
拿到报告后，两者的阅读方式其实是相通的。以AWR为例，最重要的几个部分包括：负载概况（DB Time与DB CPU的比值）、实例效率百分比（软解析率、命中率）、Top 10前台等待事件、SQL统计（按Elapsed Time、CPU、Buffer Gets排序）以及段级统计和ADDM的初步建议。DB Time是核心指标，它代表实例内所有会话消耗的非空闲时间总和，报告里所有比例和排名都围绕DB Time展开。
Statspack报告结构类似，同样有Load Profile、Top Wait Events、SQL ordered by Gets等章节，但缺少AWR特有的一些内容：比如AWR的等待事件直方图、时间模型统计（Time Model Statistics）、Active Session History（ASH）的一小时采样数据，以及ADDM自动诊断分析。特别是ASH，它是按秒采样活动会话的明细数据，排查"某一分钟到底谁在跑什么"这种问题时极其好用，而Statspack只有累积值的差值，看不到瞬时细节。
在SQL层面，Statspack级别5只记录满足阈值条件的SQL（默认是缓冲区获取超过10000或执行次数超过100的语句），如果问题SQL没达到阈值就会漏掉。AWR的Top SQL捕获基于多维度Top N算法，配合DBMS_SQLTUNE可以一键生成SQL详细报告。所以在精确定位单条问题SQL时，AWR的工作流明显更顺畅，Statspack则往往需要配合10046事件跟踪做二次确认。
实际选择建议与常见误区
综合来看，选择标准可以归纳为三条：第一，看版本与授权，标准版或未购诊断包的企业版，只能选Statspack；第二，看问题类型，周期性、累积型的整体负载分析两者都能胜任，而瞬时抖动、单SQL深挖则AWR加ASH更有优势；第三，看运维成本，AWR自动运行基本免维护，Statspack需要自己规划快照间隔和清理策略，老环境里经常能看到PERFSTAT表空间涨到几十GB没人管的情况。
几个常见误区也值得提醒。其一，认为AWR默认保留8天就够用了，实际上遇到间隔一周才复现的问题，建议把RETENTION调大到30天以上，或者定期将关键AWR报告导出为HTML归档。其二，在Statspack环境里无脑用级别10快照，导致每次快照耗时数分钟，反而影响业务。其三，混淆了快照ID体系，spreport要输入的是Statspack自己的SNAP_ID，不是AWR的SNAP_ID，两者是独立编号，混用会得到空报告或错误区间。
无论选择哪个工具，方法论是一致的：先看DB Time确认问题窗口，再看Top等待事件判断瓶颈类别（CPU、IO、锁、还是应用层），最后下钻到SQL和段级统计定位具体对象。工具只是数据的搬运工，解读能力才是性能诊断的核心竞争力。
StatspackAWR报告Oracle性能诊断修改时间：2026-09-01 12:01:02