原文地址:http://www.cnblogs.com/crystal-guoguo/p/4213458.html
簡介：
在oracle數據庫中，有兩個非常實用的自帶監控工具EM（Enterprise Manager）和AWR（Automatic Workload Repository）。其中，通過AWR報告可以生成易於閱讀的監控報告，可協助進行性能問題的診斷和分析。
本期將介紹一些AWR報告的基本使用和在性能問題診斷中的應用。
什麼是AWR：
從oracle 10g開始，使用名為GATHER_STATS_JOB的計劃任務來收集AWR的統計數據，AWR報告中收集了許多不同的統計數據，包括等待事件、各種系統級和會話級的統計數據及使用較多資源的SQL語句相關的信息。
在默認情況下，Oracle數據庫後台進程會以一定間隔（一小時）收集系統當前狀態鏡像，並且保存在數據庫中，默認的保留時間是8天，此策略可根據實際情況進行調整。在特殊的時間點，如測試執行前後，可以通過手動創建快照的方式來增加快照。在生成AWR報告時，通過快照點來選擇生成指定時間段的統計報告。
AWR的生成：
一、手動產生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%。
