AWR分析報(bào)告解析

AWR分析報(bào)告解析定義：awr報(bào)告是oracle10g下提供的一種性能收集和分析工具，它能提供一個(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-cdd:回車4:cd

d:oracle\product\10.2.0\db_1\RDBMS\Admin回車5：sqlplus用戶名/密碼@服務(wù)連接名(例：sqlpluscarmot_esz_1/carmot@igrp)6：執(zhí)行@awrrpt.sql回車第一步輸入類型：html第二步輸入天數(shù)：天數(shù)自定義（如1，代表當(dāng)天，如果2，代表今天和昨天。。。）第三步輸入開(kāi)始值與結(jié)束值：（你可以看到上面列出的數(shù)據(jù)，snap值）這個(gè)值輸入開(kāi)始，與結(jié)束第四步輸入導(dǎo)出表的名稱：名稱自定義回車第五步，由程序自動(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)是不一樣的，比如，libraryhit和bufferhit，在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ú)意義。DBTime: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.BufferNowait說(shuō)明在從內(nèi)存取數(shù)據(jù)的時(shí)候，沒(méi)有經(jīng)歷等待的比例，期望值是100%。2.BufferHit說(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)中取，這種情況下，bufferhit是50%，結(jié)果呢，第二個(gè)執(zhí)行計(jì)劃性能才是最高的，所以說(shuō)100%并不代表性能最好。3.LibraryHit說(shuō)明sql在SharedPool的命中率，期望值是100%。4.ExecutetoParse說(shuō)明解析sql和執(zhí)行sql之間的比例，越高越好，說(shuō)明一次解析，到處執(zhí)行，如果parse多，execute少的話，還會(huì)出現(xiàn)負(fù)數(shù)，因?yàn)橛?jì)算公式是100*（1-parse/execute）。5.ParseCPUtoParseElapsd說(shuō)明在解析sql語(yǔ)句過(guò)程中，cpu占整個(gè)的解析時(shí)間比例，，期望值是100%，說(shuō)明沒(méi)有產(chǎn)生等待，需要說(shuō)明的是，即使有硬解析，只要cpu沒(méi)有出現(xiàn)性能問(wèn)題，也是可以容忍的，比較硬解析也有它的好處的

。6.RedoNoWait說(shuō)明在產(chǎn)生日志的時(shí)候，沒(méi)有產(chǎn)生等待，期望值是100%。7.SoftParse說(shuō)明軟解析的比例，期望值是100%，有一點(diǎn)要說(shuō)明的是，不要單方面的追求軟解析的高比例，而去綁定變量，要看性能的瓶頸在哪里。8.LatchHit說(shuō)明latch的命中率，期望值是100%，latch類似鎖，是一種內(nèi)存鎖，但只會(huì)產(chǎn)生等待，不會(huì)產(chǎn)生阻塞，和lock還是有區(qū)別的，latch是在并發(fā)的情況下產(chǎn)生的。9.Non-ParseCPU說(shuō)明非解析cpu的比例，越高越好，用100減去這個(gè)比例，可以看出解析sql所花費(fèi)的cpu，100-99.30=0.7，說(shuō)明花費(fèi)在解析sql上的cpu很少。結(jié)合TimeModelStatistics：

可以看出，在整個(gè)sql執(zhí)行時(shí)間（sqlexecuteelapsedtime）時(shí)間為5552019秒中，解析時(shí)間（parsetimeelapsed）用了36秒，硬解析時(shí)間（hardparseelapsedtime）用了34秒雖然硬解析時(shí)間占了整個(gè)解析時(shí)間的絕大部分，但解析時(shí)間是花的很少的，所以可以判斷出，sql的解析沒(méi)有成為性能的瓶頸，進(jìn)一步推測(cè)，sql在獲取數(shù)據(jù)的過(guò)程中遇到了瓶頸。繼續(xù)看Top5TimedEvents，從這里可以看出等待時(shí)間在前五位的是什么事件，基本上就可以判斷出性能瓶頸在什么地方。1.bufferbusywaits說(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)生等待directpathwritetemp和directpathreadtemp說(shuō)明用到了臨時(shí)表空間，那我們?cè)倏匆幌耇ablespaceIOStats。

各項(xiàng)指標(biāo)都是非常高的，再根據(jù)上面的In-memorySort是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ù)看SQLStatistics，根據(jù)bufferbusywaits等待次數(shù)，時(shí)間，頻率都是最高的，我們重點(diǎn)看邏輯讀，物理讀，和執(zhí)行時(shí)間最長(zhǎng)的sql，把排在前幾位的拿出