一、AWR報告生成步驟
起因，因為一個網站的查詢效率十分的低下，客戶已經很不滿意，提了好幾次。所以公司就讓我去現場看看具體是什么情況。分別可以從這幾項入手：1、數據庫內存組件大小對比：show parameter sga; (查看內存占用情況)
2、對比數據庫之間的索引，判斷是否正常引用索引；3、調整數據庫的優化方式和優化級別；4、度量磁盤 I/O吞吐量是否一致；5、查看操作系統參數。
對於SQL調優，局部的SQL,我們可以看執行計划。但是對於整個系統而言，看AWR報告，是比較能直觀的感受到的。這邊博客主要介紹下AWR。有不足的地方，還希望讀者幫我指出來，感謝。
AWR全稱Automatic Workload Repository，自動負載信息庫，是Oracle 10g版本后推出的一種性能收集和分析工具，提供了一個時間段內整個系統的報表數據。通過AWR報告，可以分析指定的時間段內數據庫系統的性能。
1.1 工具的選擇
對於Oracle的數據，我們可以選擇PL/SQL或者直接就sqlplus，干就完了。
sqlplus使用
沖沖沖~~~
進入數據庫
sqlplus / as sysdba
PL/SQL使用
PL/SQL也可以使用，登錄之后，選擇文件(File)->新建(New)->命令窗口(Command Window)
1.2 自動創建快照
可跳過
開始壓測后執行：
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();
可以通過dba_hist_wr_control查看當前的配置情況，當前awr為每1小時做一次數據快照，保留時間為8天。
select * from dba_hist_wr_control;
修改配置，每隔30分鍾收集一次，保存1天
execute dbms_workload_repository.modify_snapshot_settings(interval=>30,retention=>14000);
關閉AWR自動收集
SQL>exec dbms_workload_repository.modify_snapshot_settings (interval=>0,retention=>24*60);
注：10g默認是自動開啟awr信息收集的，會對系統有一定的影響（很小）；如果要關閉awr信息收集，只需設置interval參數為0即可。但interval設0后，AWR報告無法生成。
1.3 手工創建快照
除了有自動，當然還有手動
select dbms_workload_repository.create_snapshot() from dual;
1.4 生成AWR報告
在sqlplus或者PL/SQL使用命令，${ORACLE_HOME}是Oracle的安裝路徑
@/${ORACLE_HOME}/.../RDBMS/ADMIN/awrrpt.sql
例如我的命令如下：
@D:/app/Administrator/product/11.2.0/dbhome_1/RDBMS/ADMIN/awrrpt.sql
這個命令就是你awrrpt.sql 存在哪個文件夾下，然后執行這個sql
執行命令之后，會提示你輸入一些參數
- (1) Enter value of report_type
意思是生成報告的格式有兩種，html和txt，這里選擇html - (2) Enter value of num_days
收集幾天的報告信息，數字，可以輸入1 - (3) Enter value of begin_snap
輸入開始快照id，要根據日志打印的快照id范圍來填
或者一天的報告。時間為0點到現在。日志打印的快照id范圍為：16431~16447
我填寫begin_snap為:16431 截止為16447
report_name則是你報告的命令，隨意點：
要注意下：這個報告生成的位置，則位於你進cmd的時候，那個地址下：
我的則在C:\Users\Administrator文件夾下。
二、AWR報告分析
2.1 AWR之DB Time
DB Time(請求時間)= DB Wait Time（DB等待時間）+ DB CPU Time（DB CPU服務時間）
上述等式中右邊DB等待時間不包括后台進程上CPU開銷的時間以及前台進程非空閑等待時間。
優化不僅僅是減少等待。它旨在改善最終用戶的響應時間或最小化每個請求使用的平均資源。有時候這些需要一起進行調整，但在其他情況下，有權衡。例如，使用並行查詢，並行查詢或者並行DML則是更多的利用系統資源來達到快速完成事務或完成查詢等相關業務。一般來說，可以調整的方式是減少或避免對系統資源的長時間占用或過度消耗。一旦當資源的占用減少，也就意味着資源可以服務更多的請求來達到提高吞吐量的目的。
由上圖可知等待時間是所有等待各種數據庫實例資源的總和。 CPU時間是實際工作在請求上花費的時間的總和。這些時間不一定由一個等待和一個CPU時間塊組成。通常，進程將經歷較短的DB資源等待，然后在CPU上短暫運行，並重復執行此操作。
因此優化包括減少或消除數據庫資源等待時間並減少CPU時間。此定義適用於任何應用程序類型，在線事務處理（OLTP）或數據倉庫（DW）。
注意：一個非常繁忙的系統顯示更長的DB CPU時間，這可能會膨脹其他時間。
AWR報告頭部
該數據庫報告打印的時候，CPUS沒有顯示出來，本服務器為8CPUS
從上圖可知，在自然流逝時間內，900分鍾，DB層調用花費的時間為5566分鍾。也即是說是自然時間的6倍左右，數據庫處於正常狀態。
當前數據庫邏輯CPU為8個，因此每CPU平均服務時間為5566.08/8=695.76min
按前面DB Time的描述，DB Time = DB Wait Time + DB CPU Time 因此 695.76min需要進一步確認是否為真實的使用率。
2.2 Load Profile
load_profile指標主要用來顯示當前系統的一些指示性能的總體參數，這里介紹一些Redo_size，用來顯示平均每秒的日志尺寸和平均每個事務的日志尺寸，有時候可以結合Transactions這個每秒事務數，分析當前事務的繁忙程度
從上圖可知，
DB Time(s) 行，每一個自然時間秒，DB Time對應為6.2s，據此推算6.2 * 899.94 * 60/60 約等於頭部的DB Time 5566.08分鍾。
DB CPU(s) 行，每一個自然時間秒，CPU的開銷為1.2s，即899.94 * 60 * 1.2=64795s，也就是說花在CPU上的時間為1078分鍾左右。
Redo size 行，每秒產生的redo較多，符合OLTP數據庫業務場景。
Executes與Transactions也表明當前的業務場景為OLTP類型。
2.3 Efficiency percentages
efficiency percentages是一些命中率指標。Buffer Hint、Library Hint等表示SGA(System global area)的命中率；Soft Parse指標表示共享池的軟解析率，如果小於90%，就說明存在未綁定變量的情況。
2.4 首要等待時間
上圖為首要等待事件，總體來說，數據庫等待時間較長。
文件讀取時間太長。通過上面的計算可知當前的數據庫非空閑等待較為嚴重。
2.5時間統計模型
上圖為時間統計模型。
sql execute elpased time時間占主導，即時間耗用主要是在SQL執行上面。
這些SQL的執行對應得等待事件見前面的Top Event，也就是說等待和爭用比較突出。
注意該時間模型中的指標存在包含關系所以存在Time Model Statistics加起來超過100%情形。
2.6 SQL Statistics
SQL Statistics從幾個維度列舉了系統執行比較慢的SQL，點擊SQL id 可以具體看到SQL的內容，然后拿SQL去調優，調優SQL可以用執行計划看看。更方便我們進行判斷。如上圖，一個不常用的語句執行這么多次，我們可以進一步去判斷是否哪里出現問題，是否有定時任務，或者是被爬蟲了。等等。