（原創）性能測試中，Oracle服務器定位CPU使用率高的瓶頸（SQL）

本篇博客記錄一次性能測試過程當中，定位對CPU使用率高的瓶頸問題，主要定位SQL爲準

（注：本篇博客爲原創博客，任何轉發，請註明轉載並貼上原貼地址，不然一概視爲抄襲，並保留追究法律責任的權利！）

 

前言：用lr執行壓力測試場景，讓腳本每15秒增長併發10個，最大併發持續15min，發現腳本在100併發的時候即到達瓶頸點，TPS再也不隨併發上升

監控應用服務器資源，發現資源利用率並不高。轉而監控數據庫資源，發現CPU利用率高達90%幾！！本次就針對這次問題進行一個分析和定位

 

1、用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相差達到一倍！！）

 

 

2、用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緣由，再結合着業務場景以及溝通，看看是否優化吧~~~~