星期六上午閑來無事，曬著太陽，來分析一下awr報告，首先說一下什么是awr報告，它能給我們帶來什么。

??? * 定義：awr報告是oracle 10g下提供的一種性能收集和分析工具，它能提供一個時間段內(nèi)整個系統(tǒng)資源使用情況的報告，通過這個報告，我們就可以了解一個系統(tǒng)的整個運行情況，這就像一個人全面的體檢報告。

如何分析：

??? * 在看awr報告的時候，我們并不需要知道所有性能指標(biāo)的含義，就可以判斷出問題的所在，這些性能指標(biāo)其實代表了oracle內(nèi)部實現(xiàn)，對oracle理解的越深，在看awr報告的時候，對數(shù)據(jù)庫性能的判斷也會越準(zhǔn)確

??? * 在看性能指標(biāo)的時候，心里先要明白，數(shù)據(jù)庫出現(xiàn)性能問題，一般都在三個地方，io，內(nèi)存，cpu，這三個又是息息相關(guān)的（ps：我們先假設(shè)這個三個地方都沒有物理上的故障），當(dāng)io負(fù)載增大時，肯定需要更多的內(nèi)存來存放，同時也需要cpu花費更多的時間來過濾這些數(shù)據(jù)，相反，cpu時間花費多的話，有可能是解析sql語句，也可能是過濾太多的數(shù)據(jù)，到不一定是和io或內(nèi)存有關(guān)系了

??? * 當(dāng)我們把一條sql送到數(shù)據(jù)庫去執(zhí)行的時候，我們要知道，什么時候用到cpu，什么時候用到內(nèi)存，什么時候用到io

?? 1. cpu：解析sql語句，嘗試多個執(zhí)行計劃，最后生成一個數(shù)據(jù)庫認(rèn)為是比較好的執(zhí)行計劃，不一定是最優(yōu)的，因為關(guān)聯(lián)表太多的時候，數(shù)據(jù)庫并不會窮舉所有的執(zhí)行計劃，這會消耗太多的時間，oracle怎么就知道這條數(shù)據(jù)時你要，另一個就不是你要的呢，這是需要cpu來過濾的
?? 2. 內(nèi)存：sql語句和執(zhí)行計劃都需要在內(nèi)存保留一段時間，還有取到的數(shù)據(jù)，根據(jù)lru算法也會盡量在內(nèi)存中保留，在執(zhí)行sql語句過程中，各種表之間的連接，排序等操作也要占用內(nèi)存
?? 3. io：如果需要的數(shù)據(jù)在內(nèi)存中沒有，則需要到磁盤中去取，就會用到物理io了，還有表之間的連接數(shù)據(jù)太多，以及排序等操作內(nèi)存放不下的時候，也需要用到臨時表空間，也就用到物理io了

這里有一點說明的是，雖然oracle占用了8G的內(nèi)存，但pga一般只占8G的20%，對于專用服務(wù)器模式，每次執(zhí)行sql語句，表數(shù)據(jù)的運算等操作，都在pga中進(jìn)行的，也就是說只能用1.6G左右的內(nèi)存，如果多個用戶都執(zhí)行
多表關(guān)聯(lián)，而且表數(shù)據(jù)又多，再加上關(guān)聯(lián)不當(dāng)?shù)脑挘瑑?nèi)存就成為瓶頸了，所有優(yōu)化sql很重要的一點就是，減少邏輯讀和物理讀

如何生成awr報告：

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

第一步輸入類型： html
第二步輸入天數(shù)： 天數(shù)自定義（如1，代表當(dāng)天，如果2，代表今天和昨天。。。）
第三步輸入開始值與結(jié)束值：（你可以看到上面列出的數(shù)據(jù)，snap值）
????? 這個值輸入開始，與結(jié)束
第四步輸入導(dǎo)出表的名稱：名稱自定義 回車
第五步，由程序自動導(dǎo)完。

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

具體分析過程：?

??? * 在分析awr報告之前，首先要確定我們的系統(tǒng)是屬于oltp，還是olap（數(shù)據(jù)庫在安裝的時候，選擇的時候，會有一個選項，是選擇oltp，還是olap）
????? 對于不同的系統(tǒng)，性能指標(biāo)的側(cè)重點是不一樣的，比如，library hit和buffer hit，在olap系統(tǒng)中幾乎可以忽略這倆個性能指標(biāo)，而在oltp系統(tǒng)中，這倆個指標(biāo)就非常關(guān)鍵了

??? * 首先要看倆個時間
????? Elapsed: 240.00 (mins) 表明采樣時間是240分鐘，任何數(shù)據(jù)都要通過這個時間來衡量，離開了這個采樣時間，任何數(shù)據(jù)都毫無疑義
????? DB Time: 92,537.95 (mins) 表明用戶操作花費的時候，包括cpu時間喝等待時間，也許有人會覺得奇怪，為什么在采樣的240分鐘過程中，用戶操作時間竟然有92537分鐘呢，遠(yuǎn)遠(yuǎn)超過了
????? 采樣時間，原因是awr報告是一個數(shù)據(jù)的集合，比如在一分鐘之內(nèi)，一個用戶等待了30秒，那么10個用戶就等待了300秒，對于cpu的話，一個cpu處理了30秒，16個cpu就是4800秒，這些時間都是以累積的方式記錄在awr報告中的。

????????? 再看sessions，可以看出連接數(shù)非常多

??? * 為了對數(shù)據(jù)庫有個整體的認(rèn)識，先看下面的性能指標(biāo)

?
??

?
?? 1. Buffer Nowait 說明 在從內(nèi)存取數(shù)據(jù)的時候，沒有經(jīng)歷等待的比例，期望值是100%
?? 2. Buffer Hit 說明從內(nèi)存取數(shù)據(jù)的時候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因為這只是一個比例而已，舉個例子，執(zhí)行一條 sql語句，# 執(zhí)行計劃是需要取10000個數(shù)據(jù)塊，結(jié)果內(nèi)存中還真有這10000個數(shù)據(jù)塊，那么比例是100%，表面上看是性能最高的，還有一個執(zhí)行計劃是需要500 個數(shù)據(jù)塊，內(nèi)存中有250個，另外250個需要在物理磁盤中取，
????? 這種情況下，buffer hit是50%，結(jié)果呢，第二個執(zhí)行計劃性能才是最高的，所以說100%并不代表性能最好
?? 3. Library Hit 說明sql在Shared Pool的命中率，期望值是100%
?? 4. Execute to Parse 說明解析sql和執(zhí)行sql之間的比例，越高越好，說明一次解析，到處執(zhí)行，如果parse多，execute少的話，還會出現(xiàn)負(fù)數(shù)，因為計算公式是100*（1-parse/execute）
?? 5. Parse CPU to Parse Elapsd 說明在解析sql語句過程中，cpu占整個的解析時間比例，，期望值是100%，說明沒有產(chǎn)生等待，需要說明的是，即使有硬解析，只要cpu沒有出現(xiàn)性能問題，也是可以容忍的，比較硬解析也有它的好處的
?? 6. Redo NoWait 說明在產(chǎn)生日志的時候，沒有產(chǎn)生等待，期望值是100%
?? 7. Soft Parse 說明軟解析的比例，期望值是100%，有一點要說明的是，不要單方面的追求軟解析的高比例，而去綁定變量，要看性能的瓶頸在哪里
?? 8. Latch Hit 說明latch的命中率，期望值是100%，latch類似鎖，是一種內(nèi)存鎖，但只會產(chǎn)生等待，不會產(chǎn)生阻塞，和lock還是有區(qū)別的，latch是在并發(fā)的情況下產(chǎn)生的
?? 9. Non-Parse CPU 說明非解析cpu的比例，越高越好，用100減去這個比例，可以看出解析sql所花費的cpu，100-99.30=0.7，說明花費在解析sql上的cpu很少

??? * 結(jié)合Time Model Statistics

?

???????? 可以看出，在整個sql執(zhí)行時間（sql execute elapsed time）時間為5552019秒中，解析時間（parse time elapsed）用了36秒，硬解析時間（hard parse elapsed time）用了34秒雖然硬解析時間占了整個解析時間的絕大部分，但解析時間是花的很少的，所以可以判斷出，sql的解析沒有成為性能的瓶 頸，進(jìn)一步推測，sql在獲取數(shù)據(jù)的過程中遇到了瓶??????????? 頸

??? * 繼續(xù)看Top 5 Timed Events，從這里可以看出等待時間在前五位的是什么事件，基本上就可以判斷出性能瓶頸在什么地方

?
?? 1. buffer busy waits 說明在獲取數(shù)據(jù)的過程中，頻繁的產(chǎn)生等待事件，很有可能產(chǎn)生了熱點塊，也就是說，很多會話都去讀取同樣的數(shù)據(jù)塊，這一事件等待了5627394次，總共等待了5322924秒，平均等待時間為946毫秒，而且頻率也是最高的，有95.9%，等待類別是并發(fā)
????? 這里有一個概念：oracle操作的最小單位是塊，當(dāng)一個會話要修改這個塊中的一條記錄，會讀取整個塊，如果另一個會話要修改的數(shù)據(jù)也正好在這個塊中，雖然這倆個
?? 2. 會話修改的記錄不一樣，也會產(chǎn)生等待direct path write temp和direct path read temp 說明用到了臨時表空間，那我們再看一下Tablespace IO Stats


?
????????? 各項指標(biāo)都是非常高的，再根據(jù)上面的In-memory Sort是100%，沒有產(chǎn)生磁盤排序，也就在排序的時候沒有用到臨時表空間，進(jìn)一步推測，多個session，每個session執(zhí)行的sql語句中多表關(guān)聯(lián)，產(chǎn)生了很多中間數(shù)據(jù)，pga內(nèi)存中放不下，
????????? 用到了臨時表空間，也有可能是用到了lob字段，在用lob字段的時候，也會用到臨時表

??? * 繼續(xù)看SQL Statistics
????? 根據(jù)buffer busy waits等待次數(shù)，時間，頻率都是最高的，我們重點看邏輯讀，物理讀，和執(zhí)行時間最長的sql，把排在前幾位的拿出來優(yōu)化
????? 優(yōu)化的原則為降低物理讀，邏輯讀，sql語句中的子操作執(zhí)行次數(shù)盡量少，在看oracle估計出來的執(zhí)行計劃是看不出子操作的執(zhí)行次數(shù)的，要看運行時的執(zhí)行計劃

??? * 有興趣的話還可以看一下Segment Statistics
????? 列出了用到的索引和表的使用情況，從這里也能看出索引和表的使用頻率

??? * 也可以看一下Load Profile
????? 里面列出了每秒，每個事務(wù)所產(chǎn)生的日志，邏輯讀和物理讀等指標(biāo)

?

awr報告分析