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爭用。