由于LoadRunner对Linux系统的性能指标监控功能不够完善，因此我们主要用nmon工具来监控性能测试过程中服务器的资源使用情况。
- 首先，在测试电脑上安装好Xmanager后，打开Xshell。
- 双击打开连接工具，新建一个连接。
- 输入自定义的连接名称和要监控的服务器IP地址，点击确定。
- 打开ftp工具 把nmon_x86_64_opensuse文件拷贝到服务器的/mnt目录下
- 回到Xshell窗口，进入/mnt目录，输入命令chmod +x nmon_x86_64_opensuse并执行
- 再输入命令mv nmon_x86_64_opensuse /usr/local/bin/nmon并执行
- 执行之后输入nmon，查看nmon工具是否安装成功。如出现以下画面，则nmon可以正常使用了。
- 在运行性能测试场景之前，我们先在Xshell内输入好nmon监控命令
- nmon -s10 -c25 -f -m /mnt/
- 参数解释：
- -s10 每 10 秒采集一次数据。
- -c25 采集 25 次，即为采集250秒的数据。根据我们场景运行的总时间来进行设置
- -f 生成的数据文件名中包含文件创建的时间。
- -m 生成的数据文件的存放目录。
- 这样就会生成一个 nmon 文件，并每十秒更新一次，直到250秒后。
- 自动在当前目录生成一个hostname_timeSeries.nmon的文件，如果hosname为test1，生产的文件为：test1_090308_1313.nmon。
- nmon -h查看更多帮助信息。
- 在性能测试场景运行完成后，把/mnt目录下生成的nmon文件通过ftp工具拷贝到测试电脑上。
- 打开nmon analyser v42.xlsm文件，点击analyze nmon data按钮
如果我们要对Oracle数据库的性能进行分析，则要采集数据库的Awr报告，流程如下。
- 用Xshell连接上服务器之后，输入 su oracle 登录oracle数据库
- 进入数据库sqlplus sys/sys as sysdba;
- 要测试前生成快照 execute DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT()
- 然后开始做性能测试，当性能测试场景运行结束后，再生成一次快照,execute DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT()
- 接着就可以进行awr报告的抽取,输入命令 @?/rdbms/admin/awrrpt
在软件性能测试过程中，如果我们仅仅对应用服务器和数据库服务器资源进行了监控，就会经常有这样的疑问：资源使用不紧张为何事务响应时间这么长？数据库性能怎么样？哪些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:：ManageabilityMonitor 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 firstbuffer结果，发现服务器端的处理时间的消耗很大，网络上的消耗时间可以忽略不计，由此可以得出初步的结论瓶颈出现在服务器端的处理上。
那这样的结果，是应用造成的还是数据库造成的呢，配合AWR报告来看就比较容易得到正确的答案。
将第4步产生的HTML脚本粘贴出来，用IE打开看看，一个指定时间段的完整的数据库性能报告就展现在我们面前了。下面是部分截图（其中CPU per Exec(s)为单个sql的cpu耗时）：
通过和开发人员确认，图中耗时最长的两个sql分别是获取企业发票种类和对应数量、获取企业基本信息调用需要的，属于被多个地方反复调用公用存储过程，需要重点优化。随后经过多轮sql优化和性能测试配合验证，这两个sql的执行效率有了明显的提升，整个发票缴销的并发性能结果也达到了预期的测试目标。