[原創-性能調優]藉助AWR報告分析解決oracleCPU太高的問題

 簡介：
在oracle數據庫中，有兩個很是實用的自帶監控工具EM（Enterprise Manager）和AWR（Automatic Workload Repository）。其中，經過AWR報告能夠生成易於閱讀的監控報告，可協助進行性能問題的診斷和分析。
本期將介紹一些AWR報告的基本使用和在性能問題診斷中的應用。
 什麼是AWR：
      從oracle 10g開始，使用名爲GATHER_STATS_JOB的計劃任務來收集AWR的統計數據，AWR報告中收集了許多不一樣的統計數據，包括等待事件、各類系統級和會話級的統計數據及使用較多資源的SQL語句相關的信息。
    在默認狀況下，Oracle數據庫後臺進程會以必定間隔（一小時）收集系統當前狀態鏡像，而且保存在數據庫中，默認的保留時間是8天，此策略可根據實際狀況進行調整。在特殊的時間點，如測試執行先後，能夠經過手動建立快照的方式來增長快照。在生成AWR報告時，經過快照點來選擇生成指定時間段的統計報告。
 AWR的生成：
1、手動產生AWR報告
1）在Oracle數據庫服務器上，用SYSDBA身份登入sqlplus。
2）運行腳本
在sqlplus中輸入awrrpt執行命令。
@?/rdbms/admin/awrrpt.sql
3）輸入報告參數
a) 選擇要生成AWR報告的類型，可選擇text類型和html類型，輸入html（默認）。
b)報告涉及天數範圍
選擇要生成報告的日期是多少天的記錄。輸入天數後，（輸入1，則表示要生成今天0點開始到目前的時間段內的報告；輸入2，則表示要生成昨天0點開始到如今的時間段內的報告；以此類推。）界面顯示出改時間段的數據表格，每一個時間點對應一個snap id，間隔時間oracle默認爲1小時。
c）輸入要生成報告的開始和結束snap編號。
d）肯定報告名稱。
不輸入直接回車，系統會自動生成一個默認名字的報告。
e)生成報告。
提示報告輸出結束後，AWR報告存放在指定目錄（用sqlplus登陸oracle數據庫的目錄）下 。
案例分析：
現象：
 某交易單場景，發現數據庫CPU平均使用率達近90%。本案例數據庫爲12Core，從Instance CPU上看，oracle佔用的CPU佔服務器中CPU資源（89.9%）的99.5%。

分析過程：
    爲了定位數據庫CPU太高的問題，測試過程當中使用AWR報告，觀察數據庫的使用狀況：
1）先總體查看報告頭信息（header）和性能指標（Buffer Nowait，Buffer Hit，Library Hit，Execute to Parse，Parse CPU to Parse Elapsd，Redo NoWait ）。
2）看Time Model Statistics，在整個sql執行時間（sql execute elapsed time）時間爲15499秒中，解析時間（parse time elapsed）用了26秒，硬解析時間（hard parse elapsed time）用了26 秒，可知解析時間是花的不多的，因此能夠判斷出，sql的解析沒有成爲性能瓶頸，進一步推測，sql在獲取數據的過程當中遇到了瓶頸。
4）關注下負載的概要信息。數據庫層面的TPS僅爲1.3，TPS較低。
5）進一步分析發現，從SQL ordered by CPU Time來看，SQL id 爲cjnzff37c9gr3和cq32agu0qkpd8的SQL語句，執行次數多，耗CPU較高。
6）針對這2個SQL語句，執行命令，獲取sql 執行計劃。（需輸入SQL id）
@$ORACLE_HOME/rdbms/admin/awrsqrpt.sql
7）經過查看執行計劃，對CTR_LOAN_CONT的表讀取佔用的cost較多，須要根據索引讀取196000行數據。其中CTR_LOAN_CONT表爲1200多萬條數據，佔用空間5888m，統計更新也較準確。部分計劃以下：

8）查看 Segments by Logical Reads，96%的邏輯讀都爲CTR_LOAN_CONT 表的讀取。最終定位爲，數據庫CPU太高爲SQL致使。
 
處理方法：
（1）轉移數據庫服務器的一部分邏輯處理到應用服務器。即將數據庫中的一些經過SQL判斷的邏輯經過應用代碼進行實現，從而適當的下降數據庫服務器的複雜計算。
（2）針對XX模塊仍然採用視圖，但在視圖中添加第三方平臺做爲條件過濾，並將歸併方法UNION（表連接後篩選掉重複的記錄再排序）改成UNION ALL（無排序去重）。
調優後效果:
（1）CTR_LOAN_CONT的表讀取佔用的cost從15359下降到276。
（2）數據庫服務器的CPU平均使用率從89.9%下降到11.6%。

 

--圖後續補上