在軟件性能測試過程中，如果我們僅僅對應用服務器和數據庫服務器資源進行了監控，就會經常有這樣的疑問：資源使用不緊張為何事務響應時間這么長？數據庫性能怎么樣？哪些sql最耗時？哪些事件在等待？為了獲取更多的Oracle性能，Oracle自帶的awr工具為我們提供了很好的解決方案。

一、AWR工具簡單介紹

AWR 實質上是一個 Oracle 的內置工具，它采集與性能相關的統計數據，并從那些統計數據中導出性能量度，以跟蹤潛在的問題。也就是說可以收集到數據庫運行的各方面統計信息和等待信息，用以診斷分析，作為一段時期內數據庫性能調整的參考。

AWR的采樣方式默認以固定的時間間隔為其所有重要的統計信息和負載信息執行一次采樣，并將采樣信息保存在AWR中。AWR采用默認策略是每小時對v$active_session_history進行采樣一次，并將信息保存到磁盤中，并且保留7天，7天后舊的記錄才會被覆蓋。這些采樣信息被保存在視圖 wrh$_active_session_history中，而這個采樣頻率（1小時）和保留時間（7天）是可以根據實際情況進行調整的，除了采用命令方式設定采樣頻率外Oracle也可以通過執行命令方式來發出采集請求，這就為執行性能測試時主動采集性能數據提供了方便。快照由一個稱為 MMON 的新的后臺進程（及其從進程）以及MMNL后臺進程自動地每隔固定時間采樣一次，我們先來看一下10g的概念指南中對這兩個新增加的后臺進程的介紹：

     MMON：Manageability Monitor的簡寫。MMON進程負責執行多種和管理相關（manageability-related）的后臺任務。例如：
    1）當某個測量值（metrics）超過了預設的限定值（threshold value）后提交警告
    2）創建新的 MMON 隸屬進程（MMON slave process）來進行快照（snapshot）
    3）捕獲最近修改過的 SQL 對象的統計信息

MMNL:：Manageability Monitor Light的簡寫。MMNL進程負責執行輕量級的且頻率較高的和可管理性相關的后臺任務，例如捕獲會話歷史信息，測量值計算等。如果MMON進程沒有按照必要的頻繁程度將ASH數據寫至AWR，那么MMNL后臺進程就負責完成這個工作。

二、AWR報告內容包含什么內容

AWR報告包含等待事件段，Load Profile段，實例效率統計段，Shared Pool統計段，Cache Size段，其中最重要的是等待事件段，它告訴我們在性能測試時間內數據庫遇到哪些性能瓶頸，它們將是性能調整或問題診斷的主要候選對象。以下為AWR報告主要包含的內容。

Report summary
Wait events statistics
SQL statistics
Instance activity statistics
I/O statistics
Buffer pool statistics
Advisory statistics
Wait statistics
Undo statistics
Latch statistics
Segment statistics
Dictionary cache statistics
Library cache statistics
SGA statisics
Resource limit statistics
init.ora parameters

三、如何生成AWR

AWR當然可以由Oracle自動產生，但是也可以通過DBMS_WORKLOAD_REPOSITORY包來手工創建、刪除和修改，也可以使用desc命令查看該包中的過程。
下面介紹一下awr相關的一些常用操作命令：

1、手工創建一個快照snapshot

為了獲取快照可以在SQLPLUS狀態下運行下列語句：
SQL> begin
     dbms_workload_repository.create_snapshot();
end;

2、手工刪除指定范圍的快照snapshot
SQL> begin
    dbms_workload_repository.drop_snapshot_range(low_snap_id => 388, high_snap_id => 388, dbid => 1483744007);
    end;
其中的刪除條件可以通過查詢表wrh$_active_session_history來獲取。

3、修改采集時間和統計信息保留時間，如將收集間隔時間改為30 分鐘一次。并且保留5天時間（單位都是分鐘）：
SQL>exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>5*24*60);
 其中interval參數可以修改AWR信息的采樣頻率，retention設置的是AWR的保存時間，單位為分鐘。

4、設置基線，保存這些數據主要用于將來的分析和比較。
SQL>exec dbms_workload_repository.create_baseline(start_snap_id => 1003,end_snap_id => 1013, 'apply_interest_1');

5.刪除基線
SQL>exec DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name =>'apply_interest_1', cascade => FALSE);

6.生成報表
得到任意兩個快照之間的AWR報告只需要在SQLPLUS狀態下運行下列語句：
@?/rdbms/admin/awrrpt.sql并按下列操作步驟即可完成：

首先, 輸入生成報告類型。目前AWR提供txt和html兩種格式，需要確認生成格式，默認是html格式。
選擇快照的天數，確認生成AWR報告的時間范圍。
輸入天數信息后，AWR生成代碼會將天數范圍內的snapshot鏡像點列出，供輸入選擇。輸入開始snapshot編號和終止snapshot編號，這兩個快照決定了定義的報表產生的時間間隔。
輸入生成報告的名稱，報告寫到用戶指定的目錄和文件下。

上述操作步驟完成后就可以在指定目錄上看到相應的報告文件。

四、AWR報告在性能測試中的實踐

為了確保系統穩定運行的同時，系統運行效率能夠滿足業務需求，浙江地稅大集中工程辦在系統集成階段就引入了性能測試來評估開發階段系統的性能狀態，保障系統性能質量，避免系統上線運行后出現性能故障。在這個項目的性能測試過程中，AWR報告對于性能測試結果的分析和性能的提升提供強有力的數據保障。以下為稅務發票發售測試用例壓力測試過程中，Loadrunner與AWR報告配合查找性能瓶頸的示例。

第1步，設置好性能測試運行場景，在性能測試運行之前手工創建一個snapshot鏡像點，該操作并不影響測試結果。

第2步，按照設定的測試場景執行200用戶并發進行發票發售的壓力測試，測試時間為十分鐘；

第3步，測試結束后再次手工創建一個snapshot快照。

第4步，生成測試開始和測試結束兩個快照之間的AWR報告。

通過分析Loadrunner測試結果，發現通過地稅編碼獲取企業發票信息事務的平均響應時間為16.479秒，遠遠超出了事務響應時間不大于5秒的測試要求，經分析發現耗時***請求的耗時為通過企業ID獲取企業發票繳銷種類和數量的請求，進一步分析該請求對應的time to first buffer結果，發現服務器端的處理時間的消耗很大，網絡上的消耗時間可以忽略不計，由此可以得出初步的結論瓶頸出現在服務器端的處理上。

那這樣的結果，是應用造成的還是數據庫造成的呢，配合AWR報告來看就比較容易得到正確的答案。

將第4步產生的HTML腳本粘貼出來，用IE打開看看，一個指定時間段的完整的數據庫性能報告就展現在我們面前了。下面是部分截圖（其中CPU per Exec(s)為單個sql的cpu耗時）：

通過和開發人員確認，圖中耗時最長的兩個sql分別是獲取企業發票種類和對應數量、獲取企業基本信息調用需要的，屬于被多個地方反復調用公用存儲過程，需要重點優化。隨后經過多輪sql優化和性能測試配合驗證，這兩個sql的執行效率有了明顯的提升，整個發票繳銷的并發性能結果也達到了預期的測試目標。

結束語：

實際的AWR報告分析遠比上述示例復雜，本文也僅僅是拋磚引玉，說明手工生成AWR報告對性能測試過程中Oracle數據庫性能分析是一個簡便而實用的方法。總之，學會分析AWR報告并獲得對自己有用的信息，是性能分析不可或缺的一個方面，如果再能與壓力測試和應用服務的日志結合分析的話，是能夠分析出一些關鍵的存在性能問題的SQL，由此再由技術團隊進行優化，循序漸進，不斷改進。這篇文章的目的只為介紹 AWR在性能測試過程中的簡單應用，只涉及非常基本的一些操作和內容，關于更完整的內容可以參見相關技術文檔。