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

作者介紹

韓鋒，宜信技術(shù)研發(fā)中心數(shù)據(jù)庫(kù)架構(gòu)師。精通多種關(guān)系型數(shù)據(jù)庫(kù)，曾任職于當(dāng)當(dāng)網(wǎng)、TOM在線(xiàn)等公司，曾任多家公司首席DBA、數(shù)據(jù)庫(kù)架構(gòu)師等職，多年一線(xiàn)數(shù)據(jù)庫(kù)架構(gòu)、設(shè)計(jì)、開(kāi)發(fā)經(jīng)驗(yàn)。著有《SQL優(yōu)化最佳實(shí)踐》一書(shū)。

 

Oracle中的AWR，全稱(chēng)為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ì)信息，就如同放置在房間不同位置的蠟燭，用于照亮這個(gè)黑暗大房間。Oracle，恰到好處地放置了足夠的蠟燭(AWR)，房間中只有極少的燭光未覆蓋之處，性能瓶頸就容易定位。而對(duì)于蠟燭較少或是沒(méi)有蠟燭的系統(tǒng)，性能優(yōu)化就如同黑暗中的舞者?！?

 

那如何解讀AWR的數(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)行分析工作。

 

一、MAIN 

 

1 Database Information

                                            

 

2 Snapshot Information

 

 

(1)Sessions

表示采集實(shí)例連接的會(huì)話(huà)數(shù)。這個(gè)數(shù)可以幫助我們了解數(shù)據(jù)庫(kù)的并發(fā)用戶(hù)數(shù)大概的情況。這個(gè)數(shù)值對(duì)于我們判斷數(shù)據(jù)庫(kù)的類(lèi)型有幫助。

 

(2)Cursors/session

每個(gè)會(huì)話(huà)平均打開(kāi)的游標(biāo)數(shù)。

 

(3)Elapsed

通過(guò)Elapsed/DB Time比較，反映出數(shù)據(jù)庫(kù)的繁忙程度。如果DB Time>>Elapsed，則說(shuō)明數(shù)據(jù)庫(kù)很忙。

 

(4)DB Time

表示用戶(hù)操作花費(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_time字段累積。

 

"合集數(shù)據(jù)"

 

需要注意的是AWR是一個(gè)數(shù)據(jù)合集。比如在1分鐘之內(nèi)，1個(gè)用戶(hù)等待了30秒鐘，那么10個(gè)用戶(hù)等待事件就是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全忙的話(huà)，一秒鐘內(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，有的session可能在訪(fǎng)問(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ì)算資源的訪(fǎng)問(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$sys_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繁忙型的話(huà)，那么在這里應(yīng)該可以看到 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è)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)該是并行查詢(xún)，從外部表讀取數(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.65

DB TIME = 10711.2

FG Wait 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.5%就是一個(gè)信號(hào)，它提示著這個(gè)系統(tǒng)可能是一個(gè)CPU-Bound的系統(tǒng)。

 

二、Report Summary 

 

1 Cache Sizes

 

 

這部分列出AWR在性能采集開(kāi)始和結(jié)束的時(shí)候，數(shù)據(jù)緩沖池(buffer cache)和共享池(shared pool)的大小。通過(guò)對(duì)比前后的變化，可以了解系統(tǒng)內(nèi)存消耗的變化。

 

2 Load 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)大于transaction次數(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ù))用戶(hù)調(diào)用次數(shù)。User calls/Executes基本上代表了每個(gè)語(yǔ)句的請(qǐng)求次數(shù)，Executes越接近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ù)。包括了用戶(hù)執(zhí)行的SQL語(yǔ)句與系統(tǒng)執(zhí)行的SQL語(yǔ)句，表示一個(gè)系統(tǒng)SQL語(yǔ)句的繁忙程度。

 

• Transactions

 

每秒的事務(wù)數(shù)。表示一個(gè)系統(tǒng)的事務(wù)繁忙程度。目前已知的最繁忙的系統(tǒng)為淘寶的在線(xiàn)交易系統(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稱(chēng)為遞歸的SQL。

 

3 Instance Efficiency Percentages (Target 100%)

 

 

這個(gè)部分是內(nèi)存效率的統(tǒng)計(jì)信息。對(duì)于OLTP系統(tǒng)而言，這些值都應(yīng)該盡可能地接近100%。對(duì)于OLAP系統(tǒng)而言，意義不太大。因?yàn)樵贠LAP系統(tǒng)中，大查詢(xún)的速度才是對(duì)性能影響的最大因素。

 

• Buffer Nowait %

 

非等待方式獲取數(shù)據(jù)塊的百分比。

 

這個(gè)值偏小，說(shuō)明發(fā)生SQL訪(fǎng)問(wèn)數(shù)據(jù)塊時(shí)數(shù)據(jù)塊正在被別的會(huì)話(huà)讀入內(nèi)存，需要等待這個(gè)操作完成。發(fā)生這樣的事情通常就是某些數(shù)據(jù)塊變成了熱塊。

 

Buffer Nowait<99%說(shuō)明，有可能是有熱塊(查找x$bh的 tch和v$latch_children的cache buffers chains)。

 

• Redo NoWait %

 

非等待方式獲取redo數(shù)據(jù)百分比。

 

• Buffer Hit %

 

數(shù)據(jù)緩沖命中率，表示了數(shù)據(jù)塊在數(shù)據(jù)緩沖區(qū)中的命中率。

Buffer Hit<95%，可能是要加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ū)偱判虻陌俜直取?/span>

 

過(guò)低說(shuō)明有大量排序在臨時(shí)表空間進(jìn)行。在oltp環(huán)境下，最好是100%。如果太小，可以調(diào)整PGA參數(shù)。

 

• Library Hit %

 

共享池中SQL解析的命中率。

 

Library Hit<95%，要考慮加大共享池，綁定變量，修改cursor_sharing等。

 

• Soft Parse %

 

軟解析占總解析數(shù)的百分比?？梢越飘?dāng)作sql在共享區(qū)的命中率。

 

這個(gè)數(shù)值偏低，說(shuō)明系統(tǒng)中有些SQL沒(méi)有重用，最優(yōu)可能的原因就是沒(méi)有使用綁定變量。

 

<95%：需要考慮到綁定

<80%：那么就可能sql基本沒(méi)有被重用

 

• Execute to Parse %

 

執(zhí)行次數(shù)對(duì)分析次數(shù)的百分比。

 

如果該值偏小，說(shuō)明解析(硬解析和軟解析)的比例過(guò)大，快速軟解析比例小。根據(jù)實(shí)際情況，可以適當(dāng)調(diào)整參數(shù)session_cursor_cache，以提高會(huì)話(huà)中sql執(zhí)行的命中率。

 

round(100*(1-:prse/:exe),2)  即(Execute次數(shù) - Parse次數(shù))/Execute次數(shù) x 100%

prse = select value from v$sysstat where name = 'parse count (total)';

exe = select value from v$sysstat where name = 'execute count';

 

沒(méi)綁定的話(huà)導(dǎo)致不能重用也是一個(gè)原因，當(dāng)然sharedpool太小也有可能，單純的加session_cached_cursors也不是根治的辦法，不同的sql還是不能重用，還要解析。即使是soft parse 也會(huì)被統(tǒng)計(jì)入 parse count,所以這個(gè)指標(biāo)并不能反應(yīng)出fast soft(pga 中)/soft (shared pool中)/hard (shared pool 中新解析) 幾種解析的比例。只有在pl/sql的類(lèi)似循環(huán)這種程序中使用使用變量才能避免大量parse，所以這個(gè)指標(biāo)跟是否使用bind并沒(méi)有必然聯(lián)系增加session_cached_cursors 是為了在大量parse的情況下把soft轉(zhuǎn)化為fast soft而節(jié)約資源。

 

• Latch Hit %

 

latch的命中率。

 

其值低是因?yàn)閟hared_pool_size過(guò)大或沒(méi)有使用綁定變量導(dǎo)致硬解析過(guò)多。要確保>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 CPU

 

CPU非分析時(shí)間在整個(gè)CPU時(shí)間的百分比。

 

100*(parse time cpu / parse time elapsed)= Parse CPU to Parse Elapsd %

 

查詢(xún)實(shí)際運(yùn)行時(shí)間/(查詢(xún)實(shí)際運(yùn)行時(shí)間+sql解析時(shí)間)，太低表示解析消耗時(shí)間過(guò)多。

 

4 Shared Pool Statistics

 

 

• Memory Usage %

 

共享池內(nèi)存使用率。

應(yīng)該穩(wěn)定在70%-90%間，太小浪費(fèi)內(nèi)存，太大則內(nèi)存不足。

 

• % SQL with executions>1

 

執(zhí)行次數(shù)大于1的SQL比率。

若太小可能是沒(méi)有使用綁定變量。

 

• % Memory for SQL w/exec>1

 

執(zhí)行次數(shù)大于1的SQL消耗內(nèi)存/所有SQL消耗的內(nèi)存(即memory for sql with execution > 1)。

 

5 Top 5 Timed Events

 

 

三、RAC Statistics 

 

這一部分只在有RAC環(huán)境下才會(huì)出現(xiàn)，是一些全局內(nèi)存中數(shù)據(jù)發(fā)送、接收方面的性能指標(biāo)，還有一些全局鎖的信息。除非這個(gè)數(shù)據(jù)庫(kù)在運(yùn)行正常是設(shè)定了一個(gè)基線(xiàn)作為參照，否則很難從這部分?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)題。

 

1 Global Cache Load Profile

 

 

2 Global Cache Efficiency Percentages (Target local+remote 100%)

 

 

3 Global Cache and Enqueue Services - Workload Characteristics

 

 

4 Global Cache and Enqueue Services - Messaging Statistics

 

 

5 Global Cache Transfer Stats

 

 

*如果CR的%Busy很大，說(shuō)明節(jié)點(diǎn)間存在大量的塊爭(zhēng)用。

 

四、Wait Events Statistics 

 

1 Time Model Statistics

 

 

這部分信息列出了各種操作占用的數(shù)據(jù)庫(kù)時(shí)間比例。

 

• parse time elapsed/hard parse 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%，這剛好與上面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。

 

2 Wait Class

 

 

這一部分是等待的類(lèi)型?？梢钥闯瞿穷?lèi)等待占用的時(shí)間最長(zhǎng)。

 

3 Wait Events

 

 

這一部分是整個(gè)實(shí)例等待事件的明細(xì)，它包含了TOP 5等待事件的信息。

 

%Time-outs: 超時(shí)百分比（超時(shí)依據(jù)不太清楚?）

 

4 Background Wait Events

 

 

這一部分是實(shí)例后臺(tái)進(jìn)程的等待事件。如果我們懷疑那個(gè)后臺(tái)進(jìn)程(比如DBWR)無(wú)法及時(shí)響應(yīng)，可以在這里確認(rèn)一下是否有后臺(tái)進(jìn)程等待時(shí)間過(guò)長(zhǎng)的事件存在。

 

5 Operating 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，%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_TIME)*100 = 146355/(152946+41230)*100 = 75.37

%Sys  = SYS_TIME/(BUSY_TIME+IDLE_TIME)*100

%Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100

 

ELAPSED_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+41230)/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 elapsed 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 execution 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 Statistics 

 

1 SQL ordered by Elapsed Time

 

 

這一部分是按照SQL執(zhí)行時(shí)間從長(zhǎng)到短的排序。

 

• Elapsed Time(S)

 

SQL語(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 Time

 

• CPU Time(s)

 

為SQL語(yǔ)句執(zhí)行時(shí)CPU占用時(shí)間總時(shí)長(zhǎng)，此時(shí)間會(huì)小于等于Elapsed Time時(shí)間。單位時(shí)間為秒。

 

• Executions

 

SQL語(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í)間占數(shù)據(jù)庫(kù)總時(shí)間的百分比。

 

• SQL ID

 

SQL語(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)題。當(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ú)用功。

 

2 SQL 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í)間。

• Executions

  SQL執(zhí)行次數(shù)。

• CPU per Exec (s)

  每次執(zhí)行消耗CPU時(shí)間。

• % Total DB Time

  SQL執(zhí)行時(shí)間占總共DB time的百分比。

 

3 SQL 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總和，而不是單次SQL執(zhí)行所占的Gets)。

 

• Buffer Gets

  SQL執(zhí)行獲得的內(nèi)存數(shù)據(jù)塊數(shù)量。

• Executions

  SQL執(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è)列表中。

 

• 大于閥值buffer_gets_th的數(shù)值，這是sql執(zhí)行緩沖區(qū)獲取的數(shù)量(默認(rèn)10000)。

• 小于define top_n_sql=65的數(shù)值。

 

4 SQL 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 Reads

  SQL物理讀的次數(shù)。

• Executions

  SQL執(zhí)行次數(shù)。

• Reads per Exec

  SQL每次執(zhí)行產(chǎn)生的物理讀。

• %Total

  占整個(gè)物理讀的百分比。

• CPU Time (s)

  SQL執(zhí)行消耗的CPU時(shí)間。

• Elapsed Time (s)

  SQL的執(zhí)行時(shí)間。

 

5 SQL ordered by Executions

 

 

這部分列出了SQL執(zhí)行次數(shù)的信息，按照從大到小的順序排列。如果是OLTP系統(tǒng)的話(huà)，這部分比較有用。因此SQL執(zhí)行頻率非常大，SQL的執(zhí)行次數(shù)會(huì)對(duì)性能有比較大的影響。OLAP系統(tǒng)因?yàn)镾QL重復(fù)執(zhí)行的頻率很低，因此意義不大。

 

• Executions

  SQL的執(zhí)行次數(shù)。

• Rows Processed

  SQL處理的記錄數(shù)。

• Rows per Exec

  SQL每次執(zhí)行處理的記錄數(shù)。

• CPU per Exec (s)

  每次執(zhí)行消耗的CPU時(shí)間。

• Elap per Exec (s)

  每次執(zhí)行的時(shí)長(zhǎng)。

 

6 SQL ordered 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 Calls

  SQL分析的次數(shù)。

• Executions

  SQL執(zhí)行的次數(shù)。

• % Total Parses

  占整個(gè)分析次數(shù)的百分比。

 

7 SQL ordered by Sharable Memory

 

記錄了SQL占用library cache的大小的TOP SQL。

 

• Sharable Mem (b)

  占用library cache的大小。單位是byte。

 

8 SQL ordered by Version Count

 

 

這部分列出了SQL多版本的信息。記錄了SQL的打開(kāi)子游標(biāo)的TOP SQL。一個(gè)SQL產(chǎn)生多版本的原因有很多，可以查詢(xún)視圖v$sql_sahred_cursor視圖了解具體原因。對(duì)于OLTP系統(tǒng)，這部分值得關(guān)注，了解SQL被重用的情況。

 

• Version Count

  SQL的版本數(shù)。

• Executions

  SQL的執(zhí)行次數(shù)。

 

9 SQL ordered by Cluster Wait Time

 

 

記錄了集群的等待時(shí)間的TOP SQL。這部分只在RAC環(huán)境中存在，列出了實(shí)例之間共享內(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ù)訪(fǎng)問(wèn)等待。對(duì)于RAC結(jié)構(gòu)，還是采用業(yè)務(wù)分隔方式較好。這樣某個(gè)業(yè)務(wù)固定使用某個(gè)實(shí)例，它訪(fǎng)問(wèn)的內(nèi)存塊就會(huì)固定地存在某個(gè)實(shí)例的內(nèi)存中，這樣降低了實(shí)例之間的GC等待事件。此外，如果RAC結(jié)構(gòu)采用負(fù)載均衡模式，這樣每個(gè)實(shí)例都會(huì)被各種應(yīng)用的會(huì)話(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)的百分比。

• Elapsed Time(s)

  SQL執(zhí)行總時(shí)長(zhǎng)。

 

10 Complete List of SQL Text

 

 

這部分是上面各部分涉及的SQL的完整文本。

 

六、Instance Activity Statistics 

 

1 Instance 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等待事件里，找到"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 Stats 

 

1 Tablespace IO Stats

 

 

表空間的I/O性能統(tǒng)計(jì)。

 

• Reads

  發(fā)生了多少次物理讀。

• Av Reads/s

  每秒鐘物理讀的次數(shù)。

• Av Rd(ms)

  平均一次物理讀的時(shí)間(毫秒)。一個(gè)高相應(yīng)的磁盤(pán)的響應(yīng)時(shí)間應(yīng)當(dāng)在10ms以?xún)?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í)間。

 

2 File IO Stats

 

 

文件級(jí)別的I/O統(tǒng)計(jì)。

 

八、Advisory Statistics 

 

顧問(wèn)信息。這塊提供了多種顧問(wèn)程序，提出在不同情況下的模擬情況。包括databuffer、pga、shared pool、sga、stream pool、java pool等的情況。

 

1 Buffer Pool Advisory

 

 

Buffer 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í)際的物理讀。

• Estimated Physical Reads

  估計(jì)的物理讀次數(shù)。

 

2 PGA Memory Advisory

 

 

PGA的大小建議。

 

• PGA Target Est (MB)

  PGA的估算大小。

• Size Factr

  影響因子，作用和buffer pool advisory中相同。

• W/A MB Processed

  Oracle為了產(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ù)。

 

3 Shared Pool Advisory

 

 

建議器通過(guò)設(shè)置不同的共享池大小，來(lái)獲取相應(yīng)的性能指標(biāo)值。

 

• Shared Pool Size(M)

  估算的共享池大小。

• SP Size Factr

  共享池大小的影響因子。

• Est LC Size (M)

  估算的庫(kù)高速緩存占用的大小。

• Est LC Mem Obj

  高速緩存中的對(duì)象數(shù)。

• Est LC Time Saved (s)

  需要額外將對(duì)象讀入共享池的時(shí)間。

• Est LC Time Saved Factr

  對(duì)象讀入共享池時(shí)間的影響因子。

  表示每一個(gè)模擬的shared pool大小對(duì)重新將對(duì)象讀入共享池的影響情況。當(dāng)這個(gè)值的變化很小或不變的時(shí)候，增加shared pool的大小就意義不大。

• Est LC Load Time (s)

  分析所花費(fèi)的時(shí)間。

• Est LC Load Time Factr

  分析花費(fèi)時(shí)間的影響因子。

• Est LC Mem Obj Hits

  內(nèi)存中對(duì)象被發(fā)現(xiàn)的次數(shù)。

 

4 SGA Target Advisory

 

 

建議器對(duì)SGA整體的性能的一個(gè)建議。

 

• SGA Target Size (M)

  估算的SGA大小。

• SGA Size Factor

  SGA大小的影響因子。

• Est DB Time (s)

  估算的SGA大小計(jì)算出的DB Time。

• Est Physical Reads

  物理讀的次數(shù)。

 

九、Latch Statistics 

 

1 Latch Activity

 

 

• Get Requests/Pct Get Miss/Avg Slps /Miss

  表示愿意等待類(lèi)型的latch的統(tǒng)計(jì)信息。

• NoWait Requests/Pct NoWait Miss

  表示不愿意等待類(lèi)型的latch的統(tǒng)計(jì)信息。

• Pct Misses

  比例最好接近0。

 

十、Segment Statistics 

 

1 Segments by Logical Reads

 

 

段的邏輯讀情況。

 

2 Segments by Physical Reads

 

 

段的物理讀情況。

 

3 Segments by Buffer Busy Waits

 

 

從這部分可以發(fā)現(xiàn)那些對(duì)象訪(fǎng)問(wèn)頻繁。Buffer Busy Waits事件通常由于某些數(shù)據(jù)塊太過(guò)頻繁的訪(fǎng)問(wèn)，導(dǎo)致熱點(diǎn)塊的產(chǎn)生。

 

4 Segments by Row Lock Waits

 

AWR報(bào)告Segment Statistics部分的Segments by Row Lock Waits，非常容易引起誤解，它包含的不僅僅是事務(wù)的行級(jí)鎖等待，還包括了索引分裂的等待。之前我一直抱怨為什么v$segment_statistics中沒(méi)有統(tǒng)計(jì)段級(jí)別的索引分裂計(jì)數(shù)，原來(lái)ORACLE已經(jīng)實(shí)現(xiàn)了。但是統(tǒng)計(jì)進(jìn)這個(gè)指標(biāo)中，你覺(jué)得合適嗎？

 

十一、其他問(wèn)題 

 

SQL運(yùn)行周期對(duì)報(bào)告的影響

 

 

對(duì)SQL語(yǔ)句來(lái)講，只有當(dāng)它執(zhí)行完畢之后，它的相關(guān)信息才會(huì)被Oracle所記錄(比如：CPU時(shí)間、SQL執(zhí)行時(shí)長(zhǎng)等)。當(dāng)時(shí)當(dāng)某個(gè)SQL終止于做AWR報(bào)告選取的2個(gè)快照間隔時(shí)間之后，那么它的信息就不能被這個(gè)AWR報(bào)告反映出來(lái)。盡管它在采樣周期里面的運(yùn)行，也消耗了很多資源。

 

也就是說(shuō)某個(gè)區(qū)間的性能報(bào)告并不能精確地反映出在這個(gè)采樣周期中資源的消耗情況。因?yàn)橛行┰谶@個(gè)區(qū)間運(yùn)行的SQL可能結(jié)束于這個(gè)時(shí)間周期之后，也可能有一些SQL在這個(gè)周期開(kāi)始之前就已經(jīng)運(yùn)行了很久，恰好結(jié)束于這個(gè)采樣周期。這些因素都導(dǎo)致了采樣周期里面的數(shù)據(jù)并不絕對(duì)是這個(gè)時(shí)間段發(fā)生的所有數(shù)據(jù)庫(kù)操作的資源使用的數(shù)據(jù)。