Oracle的AWR報告分析 Oracle的AWR報告分析

Oracle的AWR報告分析

 

* 定義：awr報告是oracle 10g下提供的一種性能收集和分析工具，它能提供一個時間段內整個系統資源使用狀況的報告，經過這個報告，咱們就能夠了解一個系統的整個運行狀況，這就像一我的全面的體檢報告。

如何分析：

* 在看awr報告的時候，咱們並不須要知道全部性能指標的含義，就能夠判斷出問題的所在，這些性能指標其實表明了oracle內部實現，對oracle理解的越深，在看awr報告的時候，對數據庫性能的判斷也會越準確

* 在看性能指標的時候，內心先要明白，數據庫出現性能問題，通常都在三個地方，io，內存，cpu，這三個又是息息相關的（ps：咱們先假設這個三個地方都沒有物理上的故障），當io負載增大時，確定須要更多的內存來存放，同時也須要cpu花費更多的時間來過濾這些數據，相反，cpu時間花費多的話，有多是解析sql語句，也多是過濾太多的數據，到不必定是和io或內存有關係了

* 當咱們把一條sql送到數據庫去執行的時候，咱們要知道，何時用到cpu，何時用到內存，何時用到io

1. cpu：解析sql語句，嘗試多個執行計劃，最後生成一個數據庫認爲是比較好的執行計劃，不必定是最優的，由於關聯表太多的時候，數據庫並不會窮舉全部的執行計劃，這會消耗太多的時間，oracle怎麼就知道這條數據時你要，另外一個就不是你要的呢，這是須要cpu來過濾的
2. 內存：sql語句和執行計劃都須要在內存保留一段時間，還有取到的數據，根據lru算法也會盡可能在內存中保留，在執行sql語句過程當中，各類表之間的鏈接，排序等操做也要佔用內存
3. io：若是須要的數據在內存中沒有，則須要到磁盤中去取，就會用到物理io了，還有表之間的鏈接數據太多，以及排序等操做內存放不下的時候，也須要用到臨時表空間，也就用到物理io了

這裏有一點說明的是，雖然oracle佔用了8G的內存，但pga通常只佔8G的20%，對於專用服務器模式，每次執行sql語句，表數據的運算等操做，都在pga中進行的，也就是說只能用1.6G左右的內存，若是多個用戶都執行
多表關聯，並且表數據又多，再加上關聯不當的話，內存就成爲瓶頸了，全部優化sql很重要的一點就是，減小邏輯讀和物理讀

如何生成awr報告：

* 1：登錄對應的數據庫服務器
2：找到oracle磁盤空間（d:oracle\product\10.2.0\db_1\RDBMS\Admin)
3：執行cmd-cd d:回車
4: cd d:oracle\product\10.2.0\db_1\RDBMS\Admin 回車
5：sqlplus 用戶名/密碼@服務鏈接名(例：sqlplus carmot_esz_1/carmot@igrp)
6：執行@awrrpt.sql 回車

第一步輸入類型： html
第二步輸入天數： 天數自定義（如1，表明當天，若是2，表明今天和昨天。。。）
第三步輸入開始值與結束值：（你能夠看到上面列出的數據，snap值）
這個值輸入開始，與結束
第四步輸入導出表的名稱：名稱自定義 回車
第五步，由程序自動導完。

第六：到d:oracle\product\10.2.0\db_1\RDBMS\Admin 目錄下。找到剛纔生成的文件。 XXXX.LST文件

具體分析過程： 

* 在分析awr報告以前，首先要肯定咱們的系統是屬於oltp，仍是olap（數據庫在安裝的時候，選擇的時候，會有一個選項，是選擇oltp，仍是olap）
對於不一樣的系統，性能指標的側重點是不同的，好比，library hit和buffer hit，在olap系統中幾乎能夠忽略這倆個性能指標，而在oltp系統中，這倆個指標就很是關鍵了

* 首先要看倆個時間
Elapsed: 240.00 (mins) 代表採樣時間是240分鐘，任何數據都要經過這個時間來衡量，離開了這個採樣時間，任何數據都毫無疑義
DB Time: 92,537.95 (mins) 代表用戶操做花費的時候，包括cpu時間喝等待時間，也許有人會以爲奇怪，爲何在採樣的240分鐘過程當中，用戶操做時間居然有92537分鐘呢，遠遠超過了
採樣時間，緣由是awr報告是一個數據的集合，好比在一分鐘以內，一個用戶等待了30秒，那麼10個用戶就等待了300秒，對於cpu的話，一個cpu處理了30秒，16個cpu就是4800秒，這些時間都是以累積的方式記錄在awr報告中的。

再看sessions，能夠看出鏈接數很是多

* 爲了對數據庫有個總體的認識，先看下面的性能指標

 

1. Buffer Nowait 說明在從內存取數據的時候，沒有經歷等待的比例，指望值是100%
2. Buffer Hit 說明從內存取數據的時候，buffer的命中率的比例，指望值是100%，但100%並不表明性能就好，由於這只是一個比例而已，舉個例子，執行一條 sql語句，# 執行計劃是須要取10000個數據塊，結果內存中還真有這10000個數據塊，那麼比例是100%，表面上看是性能最高的，還有一個執行計劃是須要500 個數據塊，內存中有250個，另外250個須要在物理磁盤中取，
這種狀況下，buffer hit是50%，結果呢，第二個執行計劃性能纔是最高的，因此說100%並不表明性能最好
3. Library Hit 說明sql在Shared Pool的命中率，指望值是100%
4. Execute to Parse 說明解析sql和執行sql之間的比例，越高越好，說明一次解析，處處執行，若是parse多，execute少的話，還會出現負數，由於計算公式是100*（1-parse/execute）
5. Parse CPU to Parse Elapsd 說明在解析sql語句過程當中，cpu佔整個的解析時間比例，，指望值是100%，說明沒有產生等待，須要說明的是，即便有硬解析，只要cpu沒有出現性能問題，也是能夠容忍的，比較硬解析也有它的好處的
6. Redo NoWait 說明在產生日誌的時候，沒有產生等待，指望值是100%
7. Soft Parse 說明軟解析的比例，指望值是100%，有一點要說明的是，不要單方面的追求軟解析的高比例，而去綁定變量，要看性能的瓶頸在哪裏
8. Latch Hit 說明latch的命中率，指望值是100%，latch相似鎖，是一種內存鎖，但只會產生等待，不會產生阻塞，和lock仍是有區別的，latch是在併發的狀況下產生的
9. Non-Parse CPU 說明非解析cpu的比例，越高越好，用100減去這個比例，能夠看出解析sql所花費的cpu，100-99.30=0.7，說明花費在解析sql上的cpu不多

* 結合Time Model Statistics

 


能夠看出，在整個sql執行時間（sql execute elapsed time）時間爲5552019秒中，解析時間（parse time elapsed）用了36秒，硬解析時間（hard parse elapsed time）用了34秒雖然硬解析時間佔了整個解析時間的絕大部分，但解析時間是花的不多的，因此能夠判斷出，sql的解析沒有成爲性能的瓶頸，進一步推測，sql在獲取數據的過程當中遇到了瓶 頸

* 繼續看Top 5 Timed Events，從這裏能夠看出等待時間在前五位的是什麼事件，基本上就能夠判斷出性能瓶頸在什麼地方

 

1. buffer busy waits 說明在獲取數據的過程當中，頻繁的產生等待事件，頗有可能產生了熱點塊，也就是說，不少會話都去讀取一樣的數據塊，這一事件等待了5627394次，總共等待了5322924秒，平均等待時間爲946毫秒，並且頻率也是最高的，有95.9%，等待類別是併發
這裏有一個概念：oracle操做的最小單位是塊，當一個會話要修改這個塊中的一條記錄，會讀取整個塊，若是另外一個會話要修改的數據也正好在這個塊中，雖然這倆個
2. 會話修改的記錄不同，也會產生等待direct path write temp和direct path read temp 說明用到了臨時表空間，那咱們再看一下Tablespace IO Stats

 

各項指標都是很是高的，再根據上面的In-memory Sort是100%，沒有產生磁盤排序，也就在排序的時候沒有用到臨時表空間，進一步推測，多個session，每一個session執行的sql語句中多表關聯，產生了不少中間數據，pga內存中放不下，
用到了臨時表空間，也有多是用到了lob字段，在用lob字段的時候，也會用到臨時表

* 繼續看SQL Statistics
根據buffer busy waits等待次數，時間，頻率都是最高的，咱們重點看邏輯讀，物理讀，和執行時間最長的sql，把排在前幾位的拿出來優化
優化的原則爲下降物理讀，邏輯讀，sql語句中的子操做執行次數儘可能少，在看oracle估計出來的執行計劃是看不出子操做的執行次數的，要看運行時的執行計劃

* 有興趣的話還能夠看一下Segment Statistics
列出了用到的索引和表的使用狀況，從這裏也能看出索引和表的使用頻率

* 也能夠看一下Load Profile
裏面列出了每秒，每一個事務所產生的日誌，邏輯讀和物理讀等指標

 

轉自：http://www.cnblogs.com/liu-ke/p/4283509.html