本篇博客记录一次性能测试过程中，定位对CPU使用率高的瓶颈问题，主要定位SQL为准
本人原篇博客地址：http://www.cnblogs.com/life-for-test/p/6840314.html
前言：用lr执行压力测试场景，让脚本每15秒增加并发10个，最大并发持续15min，发现脚本在100并发的时候即到达瓶颈点，TPS不再随并发上升
监控应用服务器资源，发现资源利用率并不高。转而监控数据库资源，发现CPU利用率高达90%几！！本次就针对此次问题进行一个分析和定位
一、用SQL命令定位
1.首先用TOP命令监控oracle服务器资源，如果是AIX系统，就用topas，进入TOP命令的滚动刷新数据时，发现userCPU高达98%！！
保持top的状态下，按shift+p，可以将所有进程按CPU使用率高低排序，这样可以了解消耗CPU最多的进程是哪些
可以看到，当前userCPU使用率高达98%，且此时TPS不再随并发数上升了，可以认为已经达到性能瓶颈了，且是由CPU瓶颈造成的
2.排序完后，将上图排在第一位的CPU使用率最高的PID记录下来（此处是172928），
①然后进入dba权限的用户，su oracle （也可以用pl_sql进入）
②然后进去sql命令行和dba权限
sqlplus / as sysdba
③现在v$process 视图中找到pid对应的地址addr，将进程号pid和oracle的session联系起来
SQL：select addr from v$process where spid=172928;
（简介：v$process视图包含当前系统oracle运行的所有进程信息。常被用于将oracle或服务进程的操作系统进程ID与数据库session之间建立联系。也就是可以通过进程PID来寻找数据库的session）
④再通过刚才的addr，在v$session表找到对应的sql_id
SQL：select sql_id from v$session where paddr='00000003CEA444C8';
⑤再通过sql_id可以找到对应的SQL是哪条
SQL：select * from v$sql where sql_id = '00000003CEA444C8';
实际上，上面是三个SQL可以联表，
SQL如下：
select t3.SQL_TEXT
from v$process t1
inner join v$session t2
on t1.ADDR = t2.PADDR
inner join v$sql t3
on t2.SQL_ID = t3.SQL_ID
where t1.SPID = 172928（这个pid就是进程id）;
用命令行得到的结果如下：
用PL_sql得到如下结果：
到这里既已经定位出占用CPU高的SQL之一的，在可以结合业务场景和SQL的效率，以及和开发人员/DBA等沟通是否优化或如何优化
（顺便此处提示，数据库中不同的数据量会对性能差距影响很大，本次测试中，10W的数据量和20W的数据量，TPS相差达到一倍！！）
二、用AWR报告定位CPU高的SQL
AWR报告如何导出，可以见本人此篇博客内容
http://www.cnblogs.com/life-for-test/p/6825127.html
导出AWR报告之后，
①在main report的SQL statistics中，点击开，结果如下：
②进入SQL的统计中，看到下面这个结果
③点击SQL ordered by CPU Time
在total这行可以看到累计消耗CPU最高的SQL，
④点击SQL的id，即可看到完整的SQL结果，如下述：
5.点开以后，可以看到的SQL如下所示，这个两个就是占用CPU高的SQL原因，再结合着业务场景以及沟通，看看是否优化吧~~~~
