【oracle性能優化】- 使用AWR定位oracle性能瓶頸

1 AWR簡介

AWR（全稱Automatic Workload Repository）是Oracle 10g版本推出的新特性，隨數據庫一塊兒被安裝的性能收集和分析工具。AWR能夠收集場景運行期間的各方面性能數據，還能夠從統計數據中分析出度量數據，經過分析報告，能夠了解整個系統的運行狀況，於是，oracle數據庫經常使用的性能調優利器。

2 生成AWR報告

AWR是經過對比兩次快照(snapshot)收集到的統計信息來生成報告。報告格式能夠選擇TXT或HTML，一般會選擇生成方便閱讀的HTML格式的報告。

生成AWR報告的方法以下：
一、使用sqlplus或pl/sql鏈接數據庫，執行快照生成命令，注意執行的用戶必須擁有DBA角色：
exec dbms_workload_repository.create_snapshot;

二、執行awr報告生成腳本，命令以下，注意在執行該命令前，一般會在場景執行後和結束前分別執行一次上述的快照命令：
@$ORACLE_HOME/rdbms/admin/awrrpt.sql

效果以下：

若是使用pl/sql，在命令窗口（Command Window）指定awrrpt.sql的絕對路徑，執行該腳本便可。

三、執行腳本會進入交互模式，輸入html,即指定生成html格式的報告，如圖：

四、輸入要讀取多少天內的快照信息，一般輸入1，即最近1天內的快照，如圖：

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

六、輸入要生成awr報告的名字，以.html結尾，默認之前面輸入的snap_id命名，如圖：

七、腳本執行完成便可生成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）, 說明系統壓力不大。

二、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消耗內存的佔比；

三、Top 5 Timed Events分析

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

四、SQL Statistics分析

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

五、IO 分析

該部分列出了每一個表空間的I/O統計數據。經過，Av Rd(ms)不該該超過30，不然認爲有I/O爭用。

4 其餘資源

關於python學習、分享、交流，筆者開通了微信公衆號【小蟒社區】，感興趣的朋友能夠關注下，歡迎加入，創建屬於咱們本身的小圈子，一塊兒學python。