星期六上午閑來(lái)無(wú)事，曬著太陽(yáng)，來(lái)分析一下awr報(bào)告，首先說(shuō)一下什么是awr報(bào)告，它能給我們帶來(lái)什么。

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

如何分析：

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

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

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

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

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

如何生成awr報(bào)告：

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

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

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

具體分析過(guò)程：?

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

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

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

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

?
??

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

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

?

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

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

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


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

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

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

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

?

awr報(bào)告分析