引言
在非功能性能测试过程中，Oracle数据库的性能表现是测试人员关注的重点之一。通过分析Oracle数据库的AWR报告，分析并找出系统的性能瓶颈。下面针对在性能测试过程中遇到的问题和提出的解决办法进行梳理，分享经验。
1. AWR报告的打印
AWR报告的原理是基于Oracle数据库的定时镜像功能。默认情况下，Oracle数据库后台进程会以一定间隔(一小时)收集系统当前状态镜像，并且保存在数据库中。生成AWR报告时，只需要指定进行分析的时间段，就可以生成该时间段的性能分析情况。AWR镜像保存在数据库中的时间为一个月左右。
下面我们回顾下AWR报告的手工打印过程。
(1) 以oracle用户登录到数据库服务器
(2) 进入sqlplus
(3) 执行脚本awrrpt.sql
(4) 设定生成报告的格式
(5) 设定报告的时间段的天数
(6) 设定报告的开始时间点
(7) 设定报告结束时间点
(8) 设定报告名称
(9) AWR报告生成正常结束
当数据库出现问题，一般都会想到查看Oracle的AWR报告来定位解决问题，因此如何快速解读分析AWR报告就是问题解决效率的关键。对于Oracle AWR报告的分析，一般先定位到AWR报告中的TOP 5 Timed Foreground Events，通常在这里能够迅速定位数据库的瓶颈，如下图所示：
图1 AWR数据库报告
下面针对表中的具体事件进行详尽分析
2. Log file sync
log filesync是前台交易直接等待的日志方面的时间，对前台交易性能体现很直接。一般它的等待时间为0~5ms，且为串行执行。
在灾备测试过程中，曾经遇到log file sync等待时间很长，超过5ms，经过Oracle专家讲解上方的逻辑架构图，发现是Commit请求过多，导致请求堆积在Log buffer所致，从而定位到LoadRunner脚本的问题。在脚本中，每一个脚本包含4个SQL语句；而在weblogic上部署的应用，是对于每一个SQL执行Commit一次。将脚本改成针对每4个SQL语句执行一次Commit，上述问题得到解决。
总结产生此类问题的原因：
(1) 硬件磁盘老化
(2) Commit请求过多
(3) Log buffer设置过小
3.全表扫描问题
在AWR报告中的TOP 5 Timed Foreground Events中directpath read的等待时间很长，不符合常规，如下图所示：
图2 Oracle数据库AWR报告
所谓direct path read就是不经过cache，直接去磁盘上读。而且这种全表扫描还可能导致的现象就是TPS的波动(超时)。
一般引起它消耗的时间很长的原因：
(1) 全表扫描
(2) SQL语句中有某种排序(order by等等)
接下来我们在main report中点击SQL statistics，如下图所示：
图3、Main Report报告
之后会显示SQL ordered by Elapsed Time，这是SQL语句的执行时间列表，如下图所示：
图4、SQL语句耗时图
从上图可以看出，第一条SQL语句的执行时间很长，所以很值得怀疑，点开它的SQL ID，就会呈现这条SQL语句：
然后在Toad上执行这条语句，图标是救护车的摸样
执行之后就会显示这条语句的执行计划，可以查看是不是走的索引。
也可以直接在sqlplus上查看，执行下述语句：
(1)explain plan for +SQL语句
select * from 表名(explain.display());
(2) set autotrace on
随便执行一条SQL，会打印出它的执行计划
(3) set autotrace off
4. 数据被Cache住的问题
现象：无论怎么增大压力，IOPS无任何变化，并且AWR报告中的physic read的量很少，Logic read的量很多，如下图所示：
图4、Oracle数据库AWR报告
解决办法:
(1) 减小cache
(2) 增大数据离散化
之前预埋到数据库的数据是从企业现金中截取出来的，其中主键是随便选择的，只要保证唯一性，没有一定的规律性，此外loadrunner的参数文件对大小有限制，不能超过40W行，所以这样就对于接下来的数据离散化有限制。经过商讨，利用主键自增，重新埋数，这样修改后的主键的数值是顺序的，在后期select的时候，随便random一个范围内的数值就可以了，这样选择出来的数据会比较离散(sequence.nextval)。
