1 AWR簡介

AWR（全稱Automatic Workload Repository）是Oracle 10g版本推出的新特性，隨資料庫一起被安裝的效能收集和分析工具。AWR可以收集場景執行期間的各方面效能資料，還可以從統計資料中分析出度量資料，通過分析報告，可以瞭解整個系統的執行情況，因而，oracle資料庫常用的效能調優利器。

2 生成AWR報告

AWR是通過對比兩次快照(snapshot)收集到的統計資訊來生成報告。報告格式可以選擇TXT或HTML，通常會選擇生成方便閱讀的HTML格式的報告。

生成AWR報告的方法如下：
1、使用sqlplus或pl/sql連線資料庫，執行快照生成命令，注意執行的使用者必須擁有DBA角色：
exec dbms_workload_repository.create_snapshot;

2、執行awr報告生成指令碼，命令如下，注意在執行該命令前，通常會在場景執行後和結束前分別執行一次上述的快照命令：
@$ORACLE_HOME/rdbms/admin/awrrpt.sql

效果如下：

如果使用pl/sql，在命令視窗（Command Window）指定awrrpt.sql的絕對路徑，執行該指令碼即可。

3、執行指令碼會進入互動模式，輸入html,即指定生成html格式的報告，如圖：

4、輸入要讀取多少天內的快照資訊，通常輸入1，即最近1天內的快照，如圖：

5、指定需要比對的開始快照和結束快照的id，如圖：

6、輸入要生成awr報告的名字，以.html結尾，預設以前面輸入的snap_id命名，如圖：

7、指令碼執行完成即可生成awr報告，預設報告會生成在當前路徑，如oracle使用者的家目錄，或者使用pl/sql,預設在工具目錄下。

3 分析AWR報告

3.1 AWR報告組成部分

AWR報告提供了詳細的資料，通過Main Report部分可以快速瞭解SQL、例項活動、等待事件、段統計等各部分的度量資料，如圖所示：

3.2 AWR報告分析

1、前言分析

從該部分可以瞭解到資料庫的空閒程度，如果DB Time遠遠小於Elapsed時間，說明資料庫比較空閒。從上圖可知，在3.15分鐘的時間段內，資料庫耗時31.11分鐘，該時間是累加了所有CPU的時間，伺服器有48個CPU，平均每個CPU耗時0.64（31/48），CPU利用率約20%（0.64/3.15）, 說明系統壓力不大。

2、Report Summary分析

Report Summary的Cache Sizes部分顯示了SGA中每個區域的大小，其中，Buffer Cache用於快取物理磁碟上的磁碟塊，加快對磁碟資料的訪問速度；shared pool主要包括library cache和dictionary cache。library cache用來儲存最近解析（或編譯）後SQL、PL/SQL和Java classes等。 dictionary cache用來儲存最近引用的資料字典。發生在library cache或dictionary cache的cache miss代價要比發生在buffer cache的代價高得多，因此shared pool的設定要確保最近使用的資料都能被cache。

Load Profile 顯示資料庫整體負載情況。經驗上Logons大於每秒2個、Hard parses大於每秒100、全部parses超過每秒300表示可能有爭用問題。

該部分資料顯示了Oracle關鍵指標的記憶體命中率及資料庫例項的操作效率。各指標的期望資料是100%,但需要根據應用的特點判斷是否存在瓶頸。

Buffer Nowait：表示在記憶體獲得資料的未等待比例，Buffer Nowait的這個值一般需要大於99%，否則可能存在爭用；

buffer hit：表示從記憶體中命中資料塊的比率，如果此值低於80%，應該給資料庫分配更多的記憶體。資料塊在資料緩衝區中的命中率，通常應在95%以上；

Redo NoWait：表示在LOG緩衝區獲得Buffer的未等待比例,這個值一般需要大於90%；

library hit：表示從Library Cache中檢索到一個解析過的SQL語句的比率，通常應該保持在95%以上，否則需要要考慮加大共享池、使用繫結變數、修改cursor_sharing等引數；

Latch Hit：通常Latch Hit要大於99%，否則意味著Shared Pool latch爭用，可能由於未共享的SQL，或者Library Cache太小，可使用繫結變數或調大Shared Pool解決；

Parse CPU to Parse Elapsd：解析實際執行時間/(解析實際執行時間+解析中等待資源時間)，越高越好；

Non-Parse CPU ：SQL實際執行時間/(SQL實際執行時間+SQL解析時間)，太低表示解析消耗時間過多；

Execute to Parse：是語句執行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析後被重複執行的次數越多；

In-memory Sort：在記憶體中排序的比率，如果過低說明有大量的排序在臨時表空間中進行，需考慮調大PGA。如果低於95%，可以通過適當調大初始化引數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決；

Soft Parse：軟解析的百分比（softs/softs+hards），近似sql在共享區的命中率，如果太低，則需要調整應用使用繫結變數；

Memory Usage %：對於已經執行一段時間的資料庫來說，Memory Usage使用率應該穩定在75%-90%間，如果太小，說明Shared Pool有浪費，而如果高於90，說明共享池中有爭用，記憶體不足；

SQL with executions>1：執行次數大於1的sql比率，如果此值太小（一般是70%），說明需要在應用中更多使用繫結變數，避免過多SQL解析；

Memory for SQL w/exec>1：執行次數大於1的SQL消耗記憶體的佔比；

3、Top 5 Timed Events分析

該部分顯示了系統中最嚴重的5個等待，並按所佔等待時間的比例倒序列示。效能問題診斷或調優時，通常會首先從這裡入手，根據等待事件確定排查和優化方向。在沒有效能問題的資料庫中，CPU time總是列在第一個。

4、SQL Statistics分析

該部分依據資源類別列出了資源消耗最嚴重的SQL語句，並顯示它們在統計期內所佔資源的比例，為效能調優提供方向。如CPU資源是系統性能瓶頸時，優化CPU time 最多的SQL語句將獲得最大效果，而在I/O等待最嚴重的系統中，優化Reads最多的SQL語句往往能獲得明顯效果。

5、IO 分析

該部分列出了每個表空間的I/O統計資料。通過，Av Rd(ms)不應該超過30，否則認為有I/O爭用。