在软件性能测试过程中，如果我们仅仅对应用服务器和数据库服务器资源进行了监控，就会经常有这样的疑问：资源使用不紧张为何事务响应时间这么长？数据库性能怎么样？哪些sql最耗时？哪些事件在等待？为了获取更多的Oracle性能，Oracle自带的awr工具为我们提供了很好的解决方案。
一、AWR工具简单介绍
AWR 实质上是一个 Oracle 的内置工具，它采集与性能相关的统计数据，并从那些统计数据中导出性能量度，以跟踪潜在的问题。也就是说可以收集到数据库运行的各方面统计信息和等待信息，用以诊断分析，作为一段时期内数据库性能调整的参考。
AWR的采样方式默认以固定的时间间隔为其所有重要的统计信息和负载信息执行一次采样，并将采样信息保存在AWR中。AWR采用默认策略是每小时对v$active_session_history进行采样一次，并将信息保存到磁盘中，并且保留7天，7天后旧的记录才会被覆盖。这些采样信息被保存在视图 wrh$_active_session_history中，而这个采样频率（1小时）和保留时间（7天）是可以根据实际情况进行调整的，除了采用命令方式设定采样频率外Oracle也可以通过执行命令方式来发出采集请求，这就为执行性能测试时主动采集性能数据提供了方便。快照由一个称为 MMON 的新的后台进程（及其从进程）以及MMNL后台进程自动地每隔固定时间采样一次，我们先来看一下10g的概念指南中对这两个新增加的后台进程的介绍：
MMON：Manageability Monitor的简写。MMON进程负责执行多种和管理相关（manageability-related）的后台任务。例如：
1）当某个测量值（metrics）超过了预设的限定值（threshold value）后提交警告
2）创建新的 MMON 隶属进程（MMON slave process）来进行快照（snapshot）
3）捕获最近修改过的 SQL 对象的统计信息
MMNL:：Manageability Monitor Light的简写。MMNL进程负责执行轻量级的且频率较高的和可管理性相关的后台任务，例如捕获会话历史信息，测量值计算等。如果MMON进程没有按照必要的频繁程度将ASH数据写至AWR，那么MMNL后台进程就负责完成这个工作。
二、AWR报告内容包含什么内容
AWR报告包含等待事件段，Load Profile段，实例效率统计段，Shared Pool统计段，Cache Size段，其中最重要的是等待事件段，它告诉我们在性能测试时间内数据库遇到哪些性能瓶颈，它们将是性能调整或问题诊断的主要候选对象。以下为AWR报告主要包含的内容。
Report summary
Wait events statistics
SQL statistics
Instance activity statistics
I/O statistics
Buffer pool statistics
Advisory statistics
Wait statistics
Undo statistics
Latch statistics
Segment statistics
Dictionary cache statistics
Library cache statistics
SGA statisics
Resource limit statistics
init.ora parameters
三、如何生成AWR
AWR当然可以由Oracle自动产生，但是也可以通过DBMS_WORKLOAD_REPOSITORY包来手工创建、删除和修改，也可以使用desc命令查看该包中的过程。
下面介绍一下awr相关的一些常用操作命令：
1、手工创建一个快照snapshot
为了获取快照可以在SQLPLUS状态下运行下列语句：
SQL> begin
dbms_workload_repository.create_snapshot();
end;
2、手工删除指定范围的快照snapshot
SQL> begin
dbms_workload_repository.drop_snapshot_range(low_snap_id => 388, high_snap_id => 388, dbid => 1483744007);
end;
其中的删除条件可以通过查询表wrh$_active_session_history来获取。
3、修改采集时间和统计信息保留时间，如将收集间隔时间改为30 分钟一次。并且保留5天时间（单位都是分钟）：
SQL>exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>5*24*60);
其中interval参数可以修改AWR信息的采样频率，retention设置的是AWR的保存时间，单位为分钟。
4、设置基线，保存这些数据主要用于将来的分析和比较。
SQL>exec dbms_workload_repository.create_baseline(start_snap_id => 1003,end_snap_id => 1013, 'apply_interest_1');
5.删除基线
SQL>exec DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name =>'apply_interest_1', cascade => FALSE);
6.生成报表
得到任意两个快照之间的AWR报告只需要在SQLPLUS状态下运行下列语句：
@?/rdbms/admin/awrrpt.sql并按下列操作步骤即可完成：
首先, 输入生成报告类型。目前AWR提供txt和html两种格式，需要确认生成格式，默认是html格式。
选择快照的天数，确认生成AWR报告的时间范围。
输入天数信息后，AWR生成代码会将天数范围内的snapshot镜像点列出，供输入选择。输入开始snapshot编号和终止snapshot编号，这两个快照决定了定义的报表产生的时间间隔。
输入生成报告的名称，报告写到用户指定的目录和文件下。
上述操作步骤完成后就可以在指定目录上看到相应的报告文件。
四、AWR报告在性能测试中的实践
为了确保系统稳定运行的同时，系统运行效率能够满足业务需求，浙江地税大集中工程办在系统集成阶段就引入了性能测试来评估开发阶段系统的性能状态，保障系统性能质量，避免系统上线运行后出现性能故障。在这个项目的性能测试过程中，AWR报告对于性能测试结果的分析和性能的提升提供强有力的数据保障。以下为税务发票发售测试用例压力测试过程中，Loadrunner与AWR报告配合查找性能瓶颈的示例。
第1步，设置好性能测试运行场景，在性能测试运行之前手工创建一个snapshot镜像点，该操作并不影响测试结果。
第2步，按照设定的测试场景执行200用户并发进行发票发售的压力测试，测试时间为十分钟；
第3步，测试结束后再次手工创建一个snapshot快照。
第4步，生成测试开始和测试结束两个快照之间的AWR报告。
通过分析Loadrunner测试结果，发现通过地税编码获取企业发票信息事务的平均响应时间为16.479秒，远远超出了事务响应时间不大于5秒的测试要求，经分析发现耗时***请求的耗时为通过企业ID获取企业发票缴销种类和数量的请求，进一步分析该请求对应的time to first buffer结果，发现服务器端的处理时间的消耗很大，网络上的消耗时间可以忽略不计，由此可以得出初步的结论瓶颈出现在服务器端的处理上。
那这样的结果，是应用造成的还是数据库造成的呢，配合AWR报告来看就比较容易得到正确的答案。
将第4步产生的HTML脚本粘贴出来，用IE打开看看，一个指定时间段的完整的数据库性能报告就展现在我们面前了。下面是部分截图（其中CPU per Exec(s)为单个sql的cpu耗时）：
通过和开发人员确认，图中耗时最长的两个sql分别是获取企业发票种类和对应数量、获取企业基本信息调用需要的，属于被多个地方反复调用公用存储过程，需要重点优化。随后经过多轮sql优化和性能测试配合验证，这两个sql的执行效率有了明显的提升，整个发票缴销的并发性能结果也达到了预期的测试目标。
结束语：
实际的AWR报告分析远比上述示例复杂，本文也仅仅是抛砖引玉，说明手工生成AWR报告对性能测试过程中Oracle数据库性能分析是一个简便而实用的方法。总之，学会分析AWR报告并获得对自己有用的信息，是性能分析不可或缺的一个方面，如果再能与压力测试和应用服务的日志结合分析的话，是能够分析出一些关键的存在性能问题的SQL，由此再由技术团队进行优化，循序渐进，不断改进。这篇文章的目的只为介绍 AWR在性能测试过程中的简单应用，只涉及非常基本的一些操作和内容，关于更完整的内容可以参见相关技术文档。
