Oracle自带的awr工具完成数据库性能，这篇分析真的太全了！

　　在软件性能测试过程中，如果只监视应用服务器和数据库服务器的资源，资源的使用不紧张，为什么事务的应用时间这么长?数据库性能怎么样?什么样的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:ManageabilityyMonitor的简写。MMON过程负责各种与管理相关的后台任务。例如，如下:

　　1)当某个测量值超过预设的限定值时，提出警告。

　　2)创建新的 MMON 隶属进程(MMON slave process)来进行快照(snapshot)

　　3)捕获**近修改过的 SQL 对象的统计信息。

　　MMNL:：Manageability Monitor Light的简写。MMNL过程负责轻量级、频率高、可管理的后台任务，如捕获会话历史信息、测量值计算等。如果MMON过程没有按照必要的频繁程度将ASH数据写入AWR，MMNL后台过程将负责完成这项工作。

　　二、AWR报告内容包含哪些内容。

　　AWR报告包括等待事件段、Load.Profile段、实例效率统计段、Shared-Pool统计段、Cachesize段，其中**重要的是等待事件段，在性能测试时间内数据库会遇到什么样的性能瓶颈以下是AWR报告主要包内容。

　　Reportsummary。

　　Waiteventstatistics。

　　sltatistics。

　　Instance，activitystatistics。

　　I/Ostatistics。

　　Bufferpoolstatistics。

　　Advisorystatistics。

　　Waitstatistics。

　　Undostatistics。

　　Latchstatistics。

　　Segmentstatistics。

　　Dictionarycachestatistics。

　　Library cache statistics。

　　SGAstatisics。

　　Resourcelimitstatistics。

　　init.oraparameters。

　　三、如何生成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>execdbms_workload_repository.modify_snapshot_settings(interval=>30，retention=>5*24*60)

　　其中interval参数可以修改AWR信息的取样频率，retention设置的是AWR的保存时间，单位为分钟。

　　4、设置基线，保存这些数据主要用于日后的分析和比较。

　　SQL>execdbms_workload_repository.create_baselintart_snapp_id=>1003，nd_snapp_idtid=>1013，手机

　　5.删除基线。

　　SQL>execDBMS_WORKLOAD_REPOSITORY.DROP_BASELINEbaseline_namert=>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报告合作寻找性能瓶颈的例子。

　　***步，设置性能测试运行场景，在性能测试运行前手工制作snapshot镜像点，该操作不影响测试结果。

　　第二步，根据设定的测试场景实施200名用户并发发发票的压力测试，测试时间为10分钟

　　第三步，测试结束后，再次手动制作snapshot快照。

　　第四步，生成测试开始和测试结束两张快照之间的AWR报告。

　　通过分析Loadrunner测试结果，发现通过地税编码获取企业发票信息事务的平均响应时间为16.479秒，远远超出了事务响应时间不大于5秒的测试要求，经分析发现耗时比较大请求的耗时为通过企业ID获取企业发票缴销种类和数量的请求，进一步分析该请求对应的time to first buffer结果，发现服务器端的处理时间的消耗很大，网络上的消耗时间可以忽略不计，由此可以得出初步的结论瓶颈出现在服务器端的处理上。

　　那这样的结果，是应用造成的还是数据库造成的呢，配合AWR报告来看就比较容易得到正确的答案。

　　贴上第四步产生的HTML脚本，用IE打开，指定时间段的完整数据库性能报告书出现在我们面前。以下是一部分屏幕截图(CPUTerExec(s)单个sql的cpu需要时间):

　　通过与开发商确认，图中时间**长的两个sql分别需要获得企业发票的种类和对应数量，获得企业基本信息的调用，在多个地方重复调用公共存储过程，需要重点优化。之后，经过多次sql优化和性能测试的协助验证，这两个sql的执行效率明显提高，收据支付的并发性能结果也达到了预期的测试目标。

　　结束语::结束语:

　　实际的AWR报告分析远比上述示例复杂，本文也只是抛砖引玉，说明手工生成AWR报告在性能测试过程中Oracle数据库性能分析是一种简单实用的方法。总之，学会分析AWR报告，获，获得对自己有用的信息是性能分析不可或缺的一方面，如果能与压力测试和应用服务的日志结合分析，就能分析出重要的性能问题的SQL，技术团队优化，逐提高本文的目的只是为了介绍AWR在性能测试过程中的简单应用，只涉及非常基本的操作和内容，可以参考更完整的内容。