本篇博客記錄一次性能測試過程中，定位對CPU使用率高的瓶頸問題，主要定位SQL為准
（注：本篇博客為原創博客，任何轉發，請注明轉載並貼上原貼地址，否則一律視為抄襲，並保留追究法律責任的權利！）
前言：用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原因，再結合着業務場景以及溝通，看看是否優化吧~~~~
