循序漸進(jìn)解讀Oracle AWR性能分析報(bào)告

1、循序漸進(jìn)解讀Oracle AWR性能分析報(bào)告DBAplus社群 Oracle中的AWR，全稱為Automatic Workload Repository，自動(dòng)負(fù)載信息庫(kù)。它收集關(guān)于特定數(shù)據(jù)庫(kù)的操作統(tǒng)計(jì)信息和其他統(tǒng)計(jì)信息，Oracle以固定的時(shí)間間隔(默認(rèn)為1個(gè)小時(shí))為其所有重要的統(tǒng)計(jì)信息和負(fù)載信息執(zhí)行一次快照，并將快照存放入AWR中。這些信息在AWR中保留指定的時(shí)間(默認(rèn)為1周)，然后執(zhí)行刪除。執(zhí)行快照的頻率和保持時(shí)間都是可以自定義的。AWR的引入，為我們分析數(shù)據(jù)庫(kù)提供了非常好的便利條件(這方面MySQL就相差了太多)。曾經(jīng)有這樣的一個(gè)比喻“一個(gè)系統(tǒng)，就像是一個(gè)黑暗的大房間，系統(tǒng)收集的統(tǒng)計(jì)信息

2、，就如同放置在房間不同位置的蠟燭，用于照亮這個(gè)黑暗大房間。Oracle，恰到好處地放置了足夠的蠟燭(AWR)，房間中只有極少的燭光未覆蓋之處，性能瓶頸就容易定位。而對(duì)于蠟燭較少或是沒(méi)有蠟燭的系統(tǒng)，性能優(yōu)化就如同黑暗中的舞者?！蹦侨绾谓庾xAWR的數(shù)據(jù)呢？Oracle本身提供了一些報(bào)告，方便進(jìn)行查看、分析。下面就針對(duì)最為常見(jiàn)的一種報(bào)告AWR數(shù)據(jù)庫(kù)報(bào)告進(jìn)行說(shuō)明。希望通過(guò)這篇文章，能方便大家更好地利用AWR，方便進(jìn)行分析工作。一、MAIN1Database Information 2Snapshot Information(1)Sessions表示采集實(shí)例連接的會(huì)話數(shù)。這個(gè)數(shù)可以幫助我們了解數(shù)據(jù)庫(kù)的并

3、發(fā)用戶數(shù)大概的情況。這個(gè)數(shù)值對(duì)于我們判斷數(shù)據(jù)庫(kù)的類(lèi)型有幫助。(2)Cursors/session每個(gè)會(huì)話平均打開(kāi)的游標(biāo)數(shù)。(3)Elapsed通過(guò)Elapsed/DB Time比較，反映出數(shù)據(jù)庫(kù)的繁忙程度。如果DB TimeElapsed，則說(shuō)明數(shù)據(jù)庫(kù)很忙。(4)DB Time表示用戶操作花費(fèi)的時(shí)間，包括CPU時(shí)間和等待事件。通常同時(shí)這個(gè)數(shù)值判讀數(shù)據(jù)庫(kù)的負(fù)載情況。具體含義db time = cpu time + wait time(不包含空閑等待)(非后臺(tái)進(jìn)程)*db time就是記錄的服務(wù)器花在數(shù)據(jù)庫(kù)運(yùn)算(非后臺(tái)進(jìn)程)和等待(非空閑等待)上的時(shí)間。對(duì)應(yīng)于V$SESSION的elapsed_t

4、ime字段累積。合集數(shù)據(jù)需要注意的是AWR是一個(gè)數(shù)據(jù)合集。比如在1分鐘之內(nèi)，1個(gè)用戶等待了30秒鐘，那么10個(gè)用戶等待事件就是300秒。CPU時(shí)間也是一樣，在1分鐘之內(nèi)，1個(gè)CPU處理30秒鐘，那么4個(gè)CPU就是120秒。這些時(shí)間都是以累積的方式記錄在AWR當(dāng)中的。示例DB CPU這是一個(gè)用于衡量CPU的使用率的重要指標(biāo)。假設(shè)系統(tǒng)有N個(gè)CPU，那么如果CPU全忙的話，一秒鐘內(nèi)的DB CPU就是N秒。除了利用CPU進(jìn)行計(jì)算外，數(shù)據(jù)庫(kù)還會(huì)利用其它計(jì)算資源，如網(wǎng)絡(luò)、硬盤(pán)、內(nèi)存等等，這些對(duì)資源的利用同樣可以利用時(shí)間進(jìn)行度量。假設(shè)系統(tǒng)有M個(gè)session在運(yùn)行，同一時(shí)刻有的session可能在利用CPU

5、，有的session可能在訪問(wèn)硬盤(pán)，那么在一秒鐘內(nèi)，所有session的時(shí)間加起來(lái)就可以表征系統(tǒng)在這一秒內(nèi)的繁忙程度。一般的，這個(gè)和的最大值應(yīng)該為M。這其實(shí)就是Oracle提供的另一個(gè)重要指標(biāo):DB time，它用以衡量前端進(jìn)程所消耗的總時(shí)間。對(duì)除CPU以后的計(jì)算資源的訪問(wèn)，Oracle用等待事件進(jìn)行描述。同樣地，和CPU可分為前臺(tái)消耗CPU和后臺(tái)消耗CPU一樣，等待事件也可以分為前臺(tái)等待事件和后臺(tái)等待事件。DB Time一般的應(yīng)該等于DB CPU + 前臺(tái)等待事件所消耗時(shí)間的總和。等待時(shí)間通過(guò)v$system_event視圖進(jìn)行統(tǒng)計(jì)，DB Time和DB CPU則是通過(guò)同一個(gè)視圖，即v$sy

6、s_time_model進(jìn)行統(tǒng)計(jì)。-Load Profile中關(guān)于DB Time的描述*這個(gè)系統(tǒng)的CPU個(gè)數(shù)是8，因此我們可以知道前臺(tái)進(jìn)程用了系統(tǒng)CPU的7.1/8=88.75%。DB Time/s為11.7，可以看出這個(gè)系統(tǒng)是CPU非常繁忙的。里面CPU占了7.1，則其它前臺(tái)等待事件占了11.7 7.1 = 4.6 Wait Time/s。DB Time 占 DB CPU的比重: 7.1/11.7= 60.68%-Top 5 Timed Events中關(guān)于DB CPU的描述按照CPU/等待事件占DB Time的比例大小，這里列出了Top 5。如果一個(gè)工作負(fù)載是CPU繁忙型的話，那么在這里應(yīng)該

7、可以看到 DB CPU的影子。*注意到，我們剛剛已經(jīng)算出了DB CPU 的%DB time，60%。其它的external table read、direct path write、PX Deq: read credit、PX Deq: Slave Session Stats這些就是占比重40的等待事件里的Top 4了。-Top 5 Timed Foreground Events的局限性再研究下這個(gè)Top 5 Timed Foreground Events，如果先不看Load Profile，是不能計(jì)算出一個(gè)CPU-Bound的工作負(fù)載。要知道系統(tǒng)CPU的繁忙程序，還要知道這個(gè)AWR所基于兩個(gè)

8、snapshot的時(shí)間間隔，還要知道系統(tǒng)CPU的個(gè)數(shù)。要不系統(tǒng)可以是一個(gè)很IDLE的系統(tǒng)呢。記住CPU利用率 = DB CPU/(CPU_COUNT*Elapsed TIME)。這個(gè)Top 5 給我們的信息只是這個(gè)工作負(fù)載應(yīng)該是并行查詢，從外部表讀取數(shù)據(jù)，并用insert append的方式寫(xiě)入磁盤(pán)，同時(shí)，主要時(shí)間耗費(fèi)在CPU的運(yùn)算上。-解讀DB Time DB CPU + 前臺(tái)等待事件所消耗時(shí)間 進(jìn)程排隊(duì)時(shí)間上面提到，DB Time一般的應(yīng)該等于DB CPU + 前臺(tái)等待事件所消耗時(shí)間的總和。在下面有對(duì)這三個(gè)值的統(tǒng)計(jì)：DB CPU = 6474.65DB TIME = 10711.2FG W

9、ait Time = 1182.63明顯的，DB CPU + FG Wait Time DB Time，只占了71.5%*其它的28.5%被消耗到哪里去了呢?這里其實(shí)又隱含著一個(gè)Oracle如何計(jì)算DB CPU和DB Time的問(wèn)題。當(dāng)CPU很忙時(shí)，如果系統(tǒng)里存在著很多進(jìn)程，就會(huì)發(fā)生進(jìn)程排隊(duì)等待CPU的現(xiàn)象。在這樣，DB TIME是把進(jìn)程排隊(duì)等待CPU的時(shí)間算在內(nèi)的，而DB CPU是不包括這一部分時(shí)間。這是造成 DB CPU + FG Wait Time DB Time的一個(gè)重要原因。如果一個(gè)系統(tǒng)CPU不忙，這這兩者應(yīng)該就比較接近了。不要忘了在這個(gè)例子中，這是一個(gè)CPU非常繁忙的系統(tǒng)，而71.

10、5%就是一個(gè)信號(hào)，它提示著這個(gè)系統(tǒng)可能是一個(gè)CPU-Bound的系統(tǒng)。二、Report Summary1Cache Sizes這部分列出AWR在性能采集開(kāi)始和結(jié)束的時(shí)候，數(shù)據(jù)緩沖池(buffer cache)和共享池(shared pool)的大小。通過(guò)對(duì)比前后的變化，可以了解系統(tǒng)內(nèi)存消耗的變化。2Load Profile這兩部分是數(shù)據(jù)庫(kù)資源負(fù)載的一個(gè)明細(xì)列表，分隔成每秒鐘的資源負(fù)載和每個(gè)事務(wù)的資源負(fù)載。Redo size每秒(每個(gè)事務(wù))產(chǎn)生的日志大小(單位字節(jié))Logical reads每秒(每個(gè)事務(wù))產(chǎn)生的邏輯讀(單位是block)。在很多系統(tǒng)里select執(zhí)行次數(shù)要遠(yuǎn)遠(yuǎn)大于transac

11、tion次數(shù)。這種情況下，可以參考Logical reads/Executes。在良好的oltp環(huán)境下，這個(gè)應(yīng)該不會(huì)超過(guò)50，一般只有10左右。如果這個(gè)值很大，說(shuō)明有些語(yǔ)句需要優(yōu)化。Block Changes每秒(每個(gè)事務(wù))改變的數(shù)據(jù)塊數(shù)。Physical reads每秒(每個(gè)事務(wù))產(chǎn)生的物理讀(單位是block)。一般物理讀都會(huì)伴隨邏輯讀，除非直接讀取這種方式，不經(jīng)過(guò)cache。Physical writes每秒(每個(gè)事務(wù))產(chǎn)生的物理寫(xiě)(單位是block)。User calls每秒(每個(gè)事務(wù))用戶調(diào)用次數(shù)。User calls/Executes基本上代表了每個(gè)語(yǔ)句的請(qǐng)求次數(shù)，Executes

12、越接近User calls越好。Parses每秒(每個(gè)事務(wù))產(chǎn)生的解析(或分析)的次數(shù)，包括軟解析和硬解析，但是不包括快速軟解析。軟解析每秒超過(guò)300次意味著你的應(yīng)用程序效率不高，沒(méi)有使用soft soft parse，調(diào)整session_cursor_cache。Hard parses每秒(每個(gè)事務(wù))產(chǎn)生的硬解析次數(shù)。每秒超過(guò)100次，就可能說(shuō)明你綁定使用的不好。Sorts每秒(每個(gè)事務(wù))排序次數(shù)。Logons每秒(每個(gè)事務(wù))登錄數(shù)據(jù)庫(kù)次數(shù)。Executes每秒(每個(gè)事務(wù))SQL語(yǔ)句執(zhí)行次數(shù)。包括了用戶執(zhí)行的SQL語(yǔ)句與系統(tǒng)執(zhí)行的SQL語(yǔ)句，表示一個(gè)系統(tǒng)SQL語(yǔ)句的繁忙程度。Transact

13、ions每秒的事務(wù)數(shù)。表示一個(gè)系統(tǒng)的事務(wù)繁忙程度。目前已知的最繁忙的系統(tǒng)為淘寶的在線交易系統(tǒng)，這個(gè)值達(dá)到了1000。% Blocks changed per Read表示邏輯讀用于只讀而不是修改的塊的比例。如果有很多PLSQL，那么就會(huì)比較高。Rollback per transaction %看回滾率是不是很高，因?yàn)榛貪L很耗資源。Recursive Call %遞歸調(diào)用SQL的比例，在PL/SQL上執(zhí)行的SQL稱為遞歸的SQL。3Instance Efficiency Percentages (Target 100%)這個(gè)部分是內(nèi)存效率的統(tǒng)計(jì)信息。對(duì)于OLTP系統(tǒng)而言，這些值都應(yīng)該盡可能地接

14、近100%。對(duì)于OLAP系統(tǒng)而言，意義不太大。因?yàn)樵贠LAP系統(tǒng)中，大查詢的速度才是對(duì)性能影響的最大因素。Buffer Nowait %非等待方式獲取數(shù)據(jù)塊的百分比。這個(gè)值偏小，說(shuō)明發(fā)生SQL訪問(wèn)數(shù)據(jù)塊時(shí)數(shù)據(jù)塊正在被別的會(huì)話讀入內(nèi)存，需要等待這個(gè)操作完成。發(fā)生這樣的事情通常就是某些數(shù)據(jù)塊變成了熱塊。Buffer Nowait99%說(shuō)明，有可能是有熱塊(查找x$bh的 tch和v$latch_children的cache buffers chains)。Redo NoWait %非等待方式獲取redo數(shù)據(jù)百分比。Buffer Hit %數(shù)據(jù)緩沖命中率，表示了數(shù)據(jù)塊在數(shù)據(jù)緩沖區(qū)中的命中率。Buff

15、er Hit95%，可能是要加db_cache_size，但是大量的非選擇的索引也會(huì)造成該值很高(大量的db file sequential read)。In-memory Sort %數(shù)據(jù)塊在內(nèi)存中排序的百分比。總排序中包括內(nèi)存排序和磁盤(pán)排序。當(dāng)內(nèi)存中排序空間不足時(shí)，使用臨時(shí)表空間進(jìn)行排序，這個(gè)是內(nèi)存排序?qū)偱判虻陌俜直?。過(guò)低說(shuō)明有大量排序在臨時(shí)表空間進(jìn)行。在oltp環(huán)境下，最好是100%。如果太小，可以調(diào)整PGA參數(shù)。Library Hit %共享池中SQL解析的命中率。Library Hit95%，要考慮加大共享池，綁定變量，修改cursor_sharing等。Soft Parse %軟

16、解析占總解析數(shù)的百分比?？梢越飘?dāng)作sql在共享區(qū)的命中率。這個(gè)數(shù)值偏低，說(shuō)明系統(tǒng)中有些SQL沒(méi)有重用，最優(yōu)可能的原因就是沒(méi)有使用綁定變量。95%：需要考慮到綁定99%，否則存在嚴(yán)重的性能問(wèn)題，比如綁定等會(huì)影響該參數(shù)。Parse CPU to Parse Elapsd %解析總時(shí)間中消耗CPU的時(shí)間百分比。即:100*(parse time cpu / parse time elapsed)解析實(shí)際運(yùn)行事件/(解析實(shí)際運(yùn)行時(shí)間+解析中等待資源時(shí)間)，越高越好。% Non-Parse CPUCPU非分析時(shí)間在整個(gè)CPU時(shí)間的百分比。100*(parse time cpu / parse time

17、 elapsed)= Parse CPU to Parse Elapsd % 查詢實(shí)際運(yùn)行時(shí)間/(查詢實(shí)際運(yùn)行時(shí)間+sql解析時(shí)間)，太低表示解析消耗時(shí)間過(guò)多。4Shared Pool StatisticsMemory Usage %共享池內(nèi)存使用率。應(yīng)該穩(wěn)定在70%-90%間，太小浪費(fèi)內(nèi)存，太大則內(nèi)存不足。% SQL with executions1執(zhí)行次數(shù)大于1的SQL比率。若太小可能是沒(méi)有使用綁定變量。% Memory for SQL w/exec1執(zhí)行次數(shù)大于1的SQL消耗內(nèi)存/所有SQL消耗的內(nèi)存(即memory for sql with execution 1)。5Top 5 Ti

18、med Events三、RAC Statistics這一部分只在有RAC環(huán)境下才會(huì)出現(xiàn)，是一些全局內(nèi)存中數(shù)據(jù)發(fā)送、接收方面的性能指標(biāo)，還有一些全局鎖的信息。除非這個(gè)數(shù)據(jù)庫(kù)在運(yùn)行正常是設(shè)定了一個(gè)基線作為參照，否則很難從這部分?jǐn)?shù)據(jù)中直接看出性能問(wèn)題。經(jīng)驗(yàn)Oracle公司經(jīng)驗(yàn)，下面GCS和GES各項(xiàng)指標(biāo)中，凡是與時(shí)間相關(guān)的指標(biāo)，只要GCS指標(biāo)低于10ms，GES指標(biāo)低于15ms，則一般表示節(jié)點(diǎn)間通訊效率正常。但是，即便時(shí)間指標(biāo)正常，也不表示應(yīng)用本身或應(yīng)用在RAC部署中沒(méi)有問(wèn)題。1Global Cache Load Profile2Global Cache Efficiency Percentages

19、 (Target local+remote 100%)3Global Cache and Enqueue Services - Workload Characteristics4Global Cache and Enqueue Services - Messaging Statistics5Global Cache Transfer Stats*如果CR的%Busy很大，說(shuō)明節(jié)點(diǎn)間存在大量的塊爭(zhēng)用。四、Wait Events Statistics1Time Model Statistics這部分信息列出了各種操作占用的數(shù)據(jù)庫(kù)時(shí)間比例。parse time elapsed/hard parse

20、elapsed time通過(guò)這兩個(gè)指標(biāo)的對(duì)比，可以看出硬解析占整個(gè)的比例。如果很高，就說(shuō)明存在大量硬解析。% Not-Parse CPU花費(fèi)在非解析上CPU消耗占整個(gè)CPU消耗的比例。反之，則可以看出解析占用情況。如果很高，也可以反映出解析過(guò)多(進(jìn)一步可以看看是否是硬解析過(guò)多)。示例 - 計(jì)算CPU消耗Total DB CPU = DB CPU + background cpu time = 1305.89 + 35.91 = 1341.8 seconds再除以總的 BUSY_TIME + IDLE_TIME% Total CPU = 1341.8/1941.76 = 69.1%，這剛好與上面

21、Report的值相吻合。其實(shí)，在Load Profile部分，我們也可以看出DB對(duì)系統(tǒng)CPU的資源利用情況。用DB CPU per Second除以CPU Count就可以得到DB在前臺(tái)所消耗的CPU%了。這里 5.3/8 = 66.25 %比69.1%稍小，說(shuō)明DB在后臺(tái)也消耗了大約3%的CPU。2Wait Class這一部分是等待的類(lèi)型?？梢钥闯瞿穷?lèi)等待占用的時(shí)間最長(zhǎng)。3Wait Events這一部分是整個(gè)實(shí)例等待事件的明細(xì)，它包含了TOP 5等待事件的信息。%Time-outs: 超時(shí)百分比（超時(shí)依據(jù)不太清楚?）4Background Wait Events這一部分是實(shí)例后臺(tái)進(jìn)程的等待事

22、件。如果我們懷疑那個(gè)后臺(tái)進(jìn)程(比如DBWR)無(wú)法及時(shí)響應(yīng)，可以在這里確認(rèn)一下是否有后臺(tái)進(jìn)程等待時(shí)間過(guò)長(zhǎng)的事件存在。5Operating System Statistics(1)背景知識(shí)如果關(guān)注數(shù)據(jù)庫(kù)的性能，那么當(dāng)拿到一份AWR報(bào)告的時(shí)候，最想知道的第一件事情可能就是系統(tǒng)資源的利用情況了，而首當(dāng)其沖的，就是CPU。而細(xì)分起來(lái)，CPU可能指的是：OS級(jí)的User%, Sys%, Idle%DB所占OS CPU資源的Busy%DB CPU又可以分為前臺(tái)所消耗的CPU和后臺(tái)所消耗的CPU(2)11g如果數(shù)據(jù)庫(kù)的版本是11g，那么很幸運(yùn)的，這些信息在AWR報(bào)告中一目了然：OS級(jí)的%User為75.4，%

23、Sys為2.8，%Idle為21.2，所以%Busy應(yīng)該是78.8。DB占了OS CPU資源的69.1，%Busy CPU則可以通過(guò)上面的數(shù)據(jù)得到:%Busy CPU = %Total CPU/(%Busy) * 100 = 69.1/78.8 * 100 = 87.69，和報(bào)告的87.7相吻合。(3)10g如果是10g，則需要手工對(duì)Report里的一些數(shù)據(jù)進(jìn)行計(jì)算了。Host CPU的結(jié)果來(lái)源于DBA_HIST_OSSTAT，AWR報(bào)告里已經(jīng)幫忙整出了這段時(shí)間內(nèi)的絕對(duì)數(shù)據(jù)(這里的時(shí)間單位是厘秒-也就是1/100秒)。解讀輸出%User = USER_TIME/(BUSY_TIME+IDLE_

24、TIME)*100 = 146355/(152946+41230)*100 = 75.37%Sys = SYS_TIME/(BUSY_TIME+IDLE_TIME)*100%Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100ELAPSED_TIME這里已經(jīng)隱含著這個(gè)AWR報(bào)告所捕捉的兩個(gè)snapshot之間的時(shí)間長(zhǎng)短了。有下面的公式。正確的理解這個(gè)公式可以對(duì)系統(tǒng)CPU資源的使用及其度量的方式有更深一步的理解。BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT推算出：ELAPSED_TIME = (152946+41

25、230)/8/100 = 242.72 seconds /這是正確的。時(shí)間統(tǒng)計(jì)視圖v$sys_time_model至于DB對(duì)CPU的利用情況，這就涉及到10g新引入的一個(gè)關(guān)于時(shí)間統(tǒng)計(jì)的視圖 - v$sys_time_model。簡(jiǎn)單而言，Oracle采用了一個(gè)統(tǒng)一的時(shí)間模型對(duì)一些重要的時(shí)間指標(biāo)進(jìn)行了記錄，具體而言，這些指標(biāo)包括：1) background elapsed time 2) background cpu time 3) RMAN cpu time (backup/restore)1) DB time 2) DB CPU 2) connection management call e

26、lapsed time 2) sequence load elapsed time 2) sql execute elapsed time 2) parse time elapsed 3) hard parse elapsed time 4) hard parse (sharing criteria) elapsed time 5) hard parse (bind mismatch) elapsed time 3) failed parse elapsed time 4) failed parse (out of shared memory) elapsed time 2) PL/SQL e

27、xecution elapsed time 2) inbound PL/SQL rpc elapsed time 2) PL/SQL compilation elapsed time 2) Java execution elapsed time 2) repeated bind elapsed time我們這里關(guān)注的只有和CPU相關(guān)的兩個(gè): background cpu time 和 DB CPU。這兩個(gè)值在AWR里面也有記錄。五、SQL Statistics1SQL ordered by Elapsed Time這一部分是按照SQL執(zhí)行時(shí)間從長(zhǎng)到短的排序。Elapsed Time(S)SQL

28、語(yǔ)句執(zhí)行用總時(shí)長(zhǎng)，此排序就是按照這個(gè)字段進(jìn)行的。注意該時(shí)間不是單個(gè)SQL跑的時(shí)間，而是監(jiān)控范圍內(nèi)SQL執(zhí)行次數(shù)的總和時(shí)間。單位時(shí)間為秒。Elapsed Time = CPU Time + Wait TimeCPU Time(s)為SQL語(yǔ)句執(zhí)行時(shí)CPU占用時(shí)間總時(shí)長(zhǎng)，此時(shí)間會(huì)小于等于Elapsed Time時(shí)間。單位時(shí)間為秒。ExecutionsSQL語(yǔ)句在監(jiān)控范圍內(nèi)的執(zhí)行次數(shù)總計(jì)。如果Executions=0，則說(shuō)明語(yǔ)句沒(méi)有正常完成，被中間停止，需要關(guān)注。Elap per Exec(s)執(zhí)行一次SQL的平均時(shí)間。單位時(shí)間為秒。% Total DB Time為SQL的Elapsed Time時(shí)

29、間占數(shù)據(jù)庫(kù)總時(shí)間的百分比。SQL IDSQL語(yǔ)句的ID編號(hào)，點(diǎn)擊之后就能導(dǎo)航到下邊的SQL詳細(xì)列表中，點(diǎn)擊IE的返回可以回到當(dāng)前SQL ID的地方。SQL Module顯示該SQL是用什么方式連接到數(shù)據(jù)庫(kù)執(zhí)行的，如果是用SQL*Plus或者PL/SQL鏈接上來(lái)的那基本上都是有人在調(diào)試程序。一般用前臺(tái)應(yīng)用鏈接過(guò)來(lái)執(zhí)行的sql該位置為空。SQL Text簡(jiǎn)單的SQL提示，詳細(xì)的需要點(diǎn)擊SQL ID。分析說(shuō)明如果看到SQL語(yǔ)句執(zhí)行時(shí)間很長(zhǎng)，而CPU時(shí)間很少，則說(shuō)明SQL在I/O操作時(shí)(包括邏輯I/O和物理I/O)消耗較多?？梢越Y(jié)合前面I/O方面的報(bào)告以及相關(guān)等待事件，進(jìn)一步分析是否是I/O存在問(wèn)題。

30、當(dāng)然SQL的等待時(shí)間主要發(fā)生在I/O操作方面，不能說(shuō)明系統(tǒng)就存在I/O瓶頸，只能說(shuō)SQL有大量的I/O操作。如果SQL語(yǔ)句執(zhí)行次數(shù)很多，需要關(guān)注一些對(duì)應(yīng)表的記錄變化。如果變化不大，需要從前面考慮是否大多數(shù)操作都進(jìn)行了Rollback，導(dǎo)致大量的無(wú)用功。2SQL ordered by CPU Time記錄了執(zhí)行占CPU時(shí)間總和時(shí)間最長(zhǎng)的TOP SQL(請(qǐng)注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占CPU時(shí)間總和，而不是單次SQL執(zhí)行時(shí)間)。這部分是SQL消耗的CPU時(shí)間從高到底的排序。CPU Time (s)SQL消耗的CPU時(shí)間。Elapsed Time (s)SQL執(zhí)行時(shí)間。ExecutionsSQL執(zhí)

31、行次數(shù)。CPU per Exec (s)每次執(zhí)行消耗CPU時(shí)間。% Total DB TimeSQL執(zhí)行時(shí)間占總共DB time的百分比。3SQL ordered by Gets這部分列出SQL獲取的內(nèi)存數(shù)據(jù)塊的數(shù)量，按照由大到小的順序排序。buffer get其實(shí)就是邏輯讀或一致性讀。在sql 10046里面，也叫query read。表示一個(gè)語(yǔ)句在執(zhí)行期間的邏輯IO，單位是塊。在報(bào)告中，該數(shù)值是一個(gè)累計(jì)值。Buffer Get=執(zhí)行次數(shù) * 每次的buffer get。記錄了執(zhí)行占總buffer gets(邏輯IO)的TOP SQL(請(qǐng)注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占Gets總和，而不是單

32、次SQL執(zhí)行所占的Gets)。Buffer GetsSQL執(zhí)行獲得的內(nèi)存數(shù)據(jù)塊數(shù)量。ExecutionsSQL執(zhí)行次數(shù)。Gets per Exec每次執(zhí)行獲得的內(nèi)存數(shù)據(jù)塊數(shù)量。%Total占總數(shù)的百分比。CPU Time (s)消耗的CPU時(shí)間。Elapsed Time (s)SQL執(zhí)行時(shí)間。篩選SQL的標(biāo)準(zhǔn)因?yàn)閟tatspack/awr列出的是總體的top buffer，它們關(guān)心的是總體的性能指標(biāo)，而不是把重心放在只執(zhí)行一次的語(yǔ)句上。為了防止過(guò)大，采用了以下原則。如果有sql沒(méi)有使用綁定變量，執(zhí)行非常差但是由于沒(méi)有綁定，因此系統(tǒng)人為是不同的sql。有可能不會(huì)被列入到這個(gè)列表中。大于閥值buf

33、fer_gets_th的數(shù)值，這是sql執(zhí)行緩沖區(qū)獲取的數(shù)量(默認(rèn)10000)。小于define top_n_sql=65的數(shù)值。4SQL ordered by Reads這部分列出了SQL執(zhí)行物理讀的信息，按照從高到低的順序排序。記錄了執(zhí)行占總磁盤(pán)物理讀(物理IO)的TOP SQL(請(qǐng)注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占磁盤(pán)物理讀總和，而不是單次SQL執(zhí)行所占的磁盤(pán)物理讀)。Physical ReadsSQL物理讀的次數(shù)。ExecutionsSQL執(zhí)行次數(shù)。Reads per ExecSQL每次執(zhí)行產(chǎn)生的物理讀。 %Total占整個(gè)物理讀的百分比。CPU Time (s)SQL執(zhí)行消耗的CPU時(shí)

34、間。Elapsed Time (s)SQL的執(zhí)行時(shí)間。5SQL ordered by Executions這部分列出了SQL執(zhí)行次數(shù)的信息，按照從大到小的順序排列。如果是OLTP系統(tǒng)的話，這部分比較有用。因此SQL執(zhí)行頻率非常大，SQL的執(zhí)行次數(shù)會(huì)對(duì)性能有比較大的影響。OLAP系統(tǒng)因?yàn)镾QL重復(fù)執(zhí)行的頻率很低，因此意義不大。ExecutionsSQL的執(zhí)行次數(shù)。Rows ProcessedSQL處理的記錄數(shù)。Rows per ExecSQL每次執(zhí)行處理的記錄數(shù)。CPU per Exec (s)每次執(zhí)行消耗的CPU時(shí)間。Elap per Exec (s)每次執(zhí)行的時(shí)長(zhǎng)。6SQL ordered

35、by Parse Calls這部分列出了SQL按分析次(軟解析)數(shù)的信息，按照從高到底的順序排列。這部分對(duì)OLTP系統(tǒng)比較重要，這里列出的總分析次數(shù)并沒(méi)有區(qū)分是硬分析還是軟分析。但是即使是軟分析，次數(shù)多了，也是需要關(guān)注的。這樣會(huì)消耗很多內(nèi)存資源，引起latch的等待，降低系統(tǒng)的性能。軟分析過(guò)多需要檢查應(yīng)用上是否有頻繁的游標(biāo)打開(kāi)、關(guān)閉操作。Parse CallsSQL分析的次數(shù)。ExecutionsSQL執(zhí)行的次數(shù)。% Total Parses占整個(gè)分析次數(shù)的百分比。7SQL ordered by Sharable Memory記錄了SQL占用library cache的大小的TOP SQL。S

36、harable Mem (b)占用library cache的大小。單位是byte。8SQL ordered by Version Count這部分列出了SQL多版本的信息。記錄了SQL的打開(kāi)子游標(biāo)的TOP SQL。一個(gè)SQL產(chǎn)生多版本的原因有很多，可以查詢視圖v$sql_sahred_cursor視圖了解具體原因。對(duì)于OLTP系統(tǒng)，這部分值得關(guān)注，了解SQL被重用的情況。Version CountSQL的版本數(shù)。ExecutionsSQL的執(zhí)行次數(shù)。9SQL ordered by Cluster Wait Time記錄了集群的等待時(shí)間的TOP SQL。這部分只在RAC環(huán)境中存在，列出了實(shí)例之

37、間共享內(nèi)存數(shù)據(jù)時(shí)發(fā)生的等待。在RAC環(huán)境下，幾個(gè)實(shí)例之間需要有一種鎖的機(jī)制來(lái)保證數(shù)據(jù)塊版本的一致性，這就出現(xiàn)了一類(lèi)新的等待事件，發(fā)生在RAC實(shí)例之間的數(shù)據(jù)訪問(wèn)等待。對(duì)于RAC結(jié)構(gòu)，還是采用業(yè)務(wù)分隔方式較好。這樣某個(gè)業(yè)務(wù)固定使用某個(gè)實(shí)例，它訪問(wèn)的內(nèi)存塊就會(huì)固定地存在某個(gè)實(shí)例的內(nèi)存中，這樣降低了實(shí)例之間的GC等待事件。此外，如果RAC結(jié)構(gòu)采用負(fù)載均衡模式，這樣每個(gè)實(shí)例都會(huì)被各種應(yīng)用的會(huì)話連接，大量的數(shù)據(jù)塊需要在各個(gè)實(shí)例的內(nèi)存中被拷貝和鎖定，會(huì)加劇GC等待事件。Cluster Wait Time (s)集群等待時(shí)長(zhǎng)。CWT % of Elapsd Time集群操作等待時(shí)長(zhǎng)占總時(shí)長(zhǎng)的百分比。Elaps

38、ed Time(s)SQL執(zhí)行總時(shí)長(zhǎng)。10Complete List of SQL Text這部分是上面各部分涉及的SQL的完整文本。六、Instance Activity Statistics1Instance Activity Stats這部分是實(shí)例的信息統(tǒng)計(jì)，項(xiàng)目非常多。對(duì)于RAC架構(gòu)的數(shù)據(jù)庫(kù)，需要分析每個(gè)實(shí)例的AWR報(bào)告，才能對(duì)整體性能做出客觀的評(píng)價(jià)。CPU used by this session這個(gè)指標(biāo)用來(lái)上面在當(dāng)前的性能采集區(qū)間里面，Oracle消耗的CPU單位。一個(gè)CPU單位是1/100秒。從這個(gè)指標(biāo)可以看出CPU的負(fù)載情況。案例 - 分析系統(tǒng)CPU繁忙程度在TOP5等待事件里

39、，找到CPU time，可以看到系統(tǒng)消耗CPU的時(shí)間為26469秒。在實(shí)例統(tǒng)計(jì)部分，可以看到整個(gè)過(guò)程消耗了1813626個(gè)CPU單位。每秒鐘消耗21個(gè)CPU單位，對(duì)應(yīng)實(shí)際的時(shí)間就是0.21秒。也就是每秒鐘CPU的處理時(shí)間為0.21秒。系統(tǒng)內(nèi)CPU個(gè)數(shù)為8。每秒鐘每個(gè)CPU消耗是21/8=2.6(個(gè)CPU單位)。在一秒鐘內(nèi)，每個(gè)CPU處理時(shí)間就是2.6/100=0.026秒。*總體來(lái)看，當(dāng)前數(shù)據(jù)庫(kù)每秒鐘每個(gè)CPU處理時(shí)間才0.026秒，遠(yuǎn)遠(yuǎn)算不上高負(fù)荷。數(shù)據(jù)庫(kù)CPU資源很豐富，遠(yuǎn)沒(méi)有出現(xiàn)瓶頸。七、IO Stats1Tablespace IO Stats表空間的I/O性能統(tǒng)計(jì)。Reads發(fā)生了多少

40、次物理讀。Av Reads/s每秒鐘物理讀的次數(shù)。Av Rd(ms)平均一次物理讀的時(shí)間(毫秒)。一個(gè)高相應(yīng)的磁盤(pán)的響應(yīng)時(shí)間應(yīng)當(dāng)在10ms以內(nèi)，最好不要超過(guò)20ms；如果達(dá)到了100ms，應(yīng)用基本就開(kāi)始出現(xiàn)嚴(yán)重問(wèn)題甚至不能正常運(yùn)行。Av Blks/Rd每次讀多少個(gè)數(shù)據(jù)塊。 Writes發(fā)生了多少次寫(xiě)。Av Writes/s每秒鐘寫(xiě)的次數(shù)。 Buffer Waits獲取內(nèi)存數(shù)據(jù)塊等待的次數(shù)。Av Buf Wt(ms) 獲取內(nèi)存數(shù)據(jù)塊平均等待時(shí)間。2File IO Stats文件級(jí)別的I/O統(tǒng)計(jì)。八、Advisory Statistics顧問(wèn)信息。這塊提供了多種顧問(wèn)程序，提出在不同情況下的模擬情況

41、。包括databuffer、pga、shared pool、sga、stream pool、java pool等的情況。1Buffer Pool AdvisoryBuffer pool的大小建議。Size for Est (M)Oracle估算Buffer pool的大小。Size Factor 估算值與實(shí)際值的比例。如果0.9就表示估算值是實(shí)際值的0.9倍。1.0表示buffer pool的實(shí)際大小。Buffers for Estimate 估算的Buffer的大小(數(shù)量)。Est Phys Read Factor 估算的物理讀的影響因子，是估算物理讀和實(shí)際物理讀的一個(gè)比例。1.0表示實(shí)際的

42、物理讀。Estimated Physical Reads 估計(jì)的物理讀次數(shù)。2PGA Memory AdvisoryPGA的大小建議。PGA Target Est (MB)PGA的估算大小。Size Factr影響因子，作用和buffer pool advisory中相同。W/A MB ProcessedOracle為了產(chǎn)生影響估算處理的數(shù)據(jù)量。Estd Extra W/A MB Read/ Written to Disk處理數(shù)據(jù)中需要物理讀寫(xiě)的數(shù)據(jù)量。Estd PGA Cache Hit %估算的PGA命中率。Estd PGA Overalloc Count需要在估算的PGA大小下額外分配內(nèi)存的個(gè)數(shù)。3Sh