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

Oracle中的AWR，全稱為Automatic Workload Repository，自動(dòng)負(fù)載信息庫。它收集關(guān)于特定數(shù)據(jù)庫的操作統(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ù)庫提供了非常好的便利條件(這方面MySQL就相差了太多)。曾經(jīng)有這樣的一個(gè)比喻——“一個(gè)系統(tǒng)，就像是一個(gè)黑暗的大房間，系統(tǒng)收集的統(tǒng)計(jì)信息，就如同放置在房間不同位置的蠟燭，用于照亮這個(gè)黑暗大房間。Oracle，恰到好處地放置了足夠的蠟燭(AWR)，房間中只有極少的燭光未覆蓋之處，性能瓶頸就容易定位。而對(duì)于蠟燭較少或是沒有蠟燭的系統(tǒng)，性能優(yōu)化就如同黑暗中的舞者?！?/p>

那如何解讀AWR的數(shù)據(jù)呢？Oracle本身提供了一些報(bào)告，方便進(jìn)行查看、分析。下面就針對(duì)最為常見的一種報(bào)告——《AWR數(shù)據(jù)庫報(bào)告》進(jìn)行說明。希望通過這篇文章，能方便大家更好地利用AWR，方便進(jìn)行分析工作。

一、MAIN

1、Database Information

2、Snapshot Information

(1)Sessions

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

(2)Cursors/session

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

(3)Elapsed

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

(4)DB Time

表示用戶操作花費(fèi)的時(shí)間，包括CPU時(shí)間和等待事件。通常同時(shí)這個(gè)數(shù)值判讀數(shù)據(jù)庫的負(fù)載情況。

具體含義

db time = cpu time + wait time(不包含空閑等待)(非后臺(tái)進(jìn)程)

*db time就是記錄的服務(wù)器花在數(shù)據(jù)庫運(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è)用戶等待了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ù)庫還會(huì)利用其它計(jì)算資源，如網(wǎng)絡(luò)、硬盤、內(nèi)存等等，這些對(duì)資源的利用同樣可以利用時(shí)間進(jìn)行度量。假設(shè)系統(tǒng)有M個(gè)session在運(yùn)行，同一時(shí)刻有的session可能在利用CPU，有的session可能在訪問硬盤，那么在一秒鐘內(nèi)，所有session的時(shí)間加起來就可以表征系統(tǒng)在這一秒內(nèi)的繁忙程度。一般的，這個(gè)和的最大值應(yīng)該為M。這其實(shí)就是Oracle提供的另一個(gè)重要指標(biāo)：DB time，它用以衡量前端進(jìn)程所消耗的總時(shí)間。

對(duì)除CPU以后的計(jì)算資源的訪問，Oracle用等待事件進(jìn)行描述。同樣地，和CPU可分為前臺(tái)消耗CPU和后臺(tái)消耗CPU一樣，等待事件也可以分為前臺(tái)等待事件和后臺(tái)等待事件。DB Time一般的應(yīng)該等于"DB CPU + 前臺(tái)等待事件所消耗時(shí)間"的總和。等待時(shí)間通過v$system_event視圖進(jìn)行統(tǒng)計(jì)，DB Time和DB CPU則是通過同一個(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繁忙型的話，那么在這里應(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)該是并行查詢，從外部表讀取數(shù)據(jù)，并用insert append的方式寫入磁盤，同時(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的問題。當(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在性能采集開始和結(jié)束的時(shí)候，數(shù)據(jù)緩沖池(buffer cache)和共享池(shared pool)的大小。通過對(duì)比前后的變化，可以了解系統(tǒng)內(nèi)存消耗的變化。

2、Load Profile

這兩部分是數(shù)據(jù)庫資源負(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ì)超過50，一般只有10左右。如果這個(gè)值很大，說明有些語句需要優(yōu)化。

• Block Changes

每秒(每個(gè)事務(wù))改變的數(shù)據(jù)塊數(shù)。

• Physical reads

每秒(每個(gè)事務(wù))產(chǎn)生的物理讀(單位是block)。一般物理讀都會(huì)伴隨邏輯讀，除非直接讀取這種方式，不經(jīng)過cache。

• Physical writes

每秒(每個(gè)事務(wù))產(chǎn)生的物理寫(單位是block)。

• User calls

每秒(每個(gè)事務(wù))用戶調(diào)用次數(shù)。User calls/Executes基本上代表了每個(gè)語句的請(qǐng)求次數(shù)，Executes越接近User calls越好。

• Parses

每秒(每個(gè)事務(wù))產(chǎn)生的解析(或分析)的次數(shù)，包括軟解析和硬解析，但是不包括快速軟解析。軟解析每秒超過300次意味著你的"應(yīng)用程序"效率不高，沒有使用soft soft parse，調(diào)整session_cursor_cache。

• Hard parses

每秒(每個(gè)事務(wù))產(chǎn)生的硬解析次數(shù)。每秒超過100次，就可能說明你綁定使用的不好。

• Sorts

每秒(每個(gè)事務(wù))排序次數(shù)。

• Logons

每秒(每個(gè)事務(wù))登錄數(shù)據(jù)庫次數(shù)。

• Executes

每秒(每個(gè)事務(wù))SQL語句執(zhí)行次數(shù)。包括了用戶執(zhí)行的SQL語句與系統(tǒng)執(zhí)行的SQL語句，表示一個(gè)系統(tǒng)SQL語句的繁忙程度。

• Transactions

每秒的事務(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。

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)中，大查詢的速度才是對(duì)性能影響的最大因素。

• Buffer Nowait %

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

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

Buffer Nowait<99%說明，有可能是有熱塊(查找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)存排序和磁盤排序。當(dāng)內(nèi)存中排序空間不足時(shí)，使用臨時(shí)表空間進(jìn)行排序，這個(gè)是內(nèi)存排序?qū)偱判虻陌俜直取?/p>

過低說明有大量排序在臨時(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ù)值偏低，說明系統(tǒng)中有些SQL沒有重用，最優(yōu)可能的原因就是沒有使用綁定變量。

<95%：需要考慮到綁定

<80%：那么就可能sql基本沒有被重用

• Execute to Parse %

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

如果該值偏小，說明解析(硬解析和軟解析)的比例過大，快速軟解析比例小。根據(jù)實(shí)際情況，可以適當(dāng)調(diào)整參數(shù)session_cursor_cache，以提高會(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';

沒綁定的話導(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的類似循環(huán)這種程序中使用使用變量才能避免大量parse，所以這個(gè)指標(biāo)跟是否使用bind并沒有必然聯(lián)系增加session_cached_cursors 是為了在大量parse的情況下把soft轉(zhuǎn)化為fast soft而節(jié)約資源。

• Latch Hit %

latch的命中率。

其值低是因?yàn)閟hared_pool_size過大或沒有使用綁定變量導(dǎo)致硬解析過多。要確保>99%，否則存在嚴(yá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 %

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

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比率。

若太小可能是沒有使用綁定變量。

• % 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ù)庫在運(yùn)行正常是設(shè)定了一個(gè)基線作為參照，否則很難從這部分?jǐn)?shù)據(jù)中直接看出性能問題。

經(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部署中沒有問題。

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很大，說明節(jié)點(diǎn)間存在大量的塊爭(zhēng)用。

四、Wait Events Statistics

1、Time Model Statistics

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

• parse time elapsed/hard parse elapsed time

通過這兩個(gè)指標(biāo)的對(duì)比，可以看出硬解析占整個(gè)的比例。如果很高，就說明存在大量硬解析。

• % Not-Parse CPU

花費(fèi)在非解析上CPU消耗占整個(gè)CPU消耗的比例。反之，則可以看出解析占用情況。如果很高，也可以反映出解析過多(進(jìn)一步可以看看是否是硬解析過多)。

示例 - 計(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%稍小，說明DB在后臺(tái)也消耗了大約3%的CPU。

2、Wait Class

這一部分是等待的類型。可以看出那類等待占用的時(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)無法及時(shí)響應(yīng)，可以在這里確認(rèn)一下是否有后臺(tái)進(jìn)程等待時(shí)間過長(zhǎng)的事件存在。

5、Operating System Statistics

(1)背景知識(shí)

如果關(guān)注數(shù)據(jù)庫的性能，那么當(dāng)拿到一份AWR報(bào)告的時(shí)候，最想知道的第一件事情可能就是系統(tǒng)資源的利用情況了，而首當(dāng)其沖的，就是CPU。而細(xì)分起來，CPU可能指的是：

• OS級(jí)的User%, Sys%, Idle%

• DB所占OS CPU資源的Busy%

• DB CPU又可以分為前臺(tái)所消耗的CPU和后臺(tái)所消耗的CPU

(2)11g

如果數(shù)據(jù)庫的版本是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則可以通過上面的數(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é)果來源于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語句執(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語句執(zhí)行時(shí)CPU占用時(shí)間總時(shí)長(zhǎng)，此時(shí)間會(huì)小于等于Elapsed Time時(shí)間。單位時(shí)間為秒。

• Executions

SQL語句在監(jiān)控范圍內(nèi)的執(zhí)行次數(shù)總計(jì)。如果Executions=0，則說明語句沒有正常完成，被中間停止，需要關(guān)注。

• Elap per Exec(s)

執(zhí)行一次SQL的平均時(shí)間。單位時(shí)間為秒。

• % Total DB Time

為SQL的Elapsed Time時(shí)間占數(shù)據(jù)庫總時(shí)間的百分比。

• SQL ID

SQL語句的ID編號(hào)，點(diǎn)擊之后就能導(dǎo)航到下邊的SQL詳細(xì)列表中，點(diǎn)擊IE的返回可以回到當(dāng)前SQL ID的地方。

• SQL Module

顯示該SQL是用什么方式連接到數(shù)據(jù)庫執(zhí)行的，如果是用SQL*Plus或者PL/SQL鏈接上來的那基本上都是有人在調(diào)試程序。一般用前臺(tái)應(yīng)用鏈接過來執(zhí)行的sql該位置為空。

• SQL Text

簡(jiǎn)單的SQL提示，詳細(xì)的需要點(diǎn)擊SQL ID。

分析說明

如果看到SQL語句執(zhí)行時(shí)間很長(zhǎng)，而CPU時(shí)間很少，則說明SQL在I/O操作時(shí)(包括邏輯I/O和物理I/O)消耗較多?？梢越Y(jié)合前面I/O方面的報(bào)告以及相關(guān)等待事件，進(jìn)一步分析是否是I/O存在問題。當(dāng)然SQL的等待時(shí)間主要發(fā)生在I/O操作方面，不能說明系統(tǒng)就存在I/O瓶頸，只能說SQL有大量的I/O操作。

如果SQL語句執(zhí)行次數(shù)很多，需要關(guān)注一些對(duì)應(yīng)表的記錄變化。如果變化不大，需要從前面考慮是否大多數(shù)操作都進(jìn)行了Rollback，導(dǎo)致大量的無用功。

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è)語句在執(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í)行一次的語句上。為了防止過大，采用了以下原則。如果有sql沒有使用綁定變量，執(zhí)行非常差但是由于沒有綁定，因此系統(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í)行占總磁盤物理讀(物理IO)的TOP SQL(請(qǐng)注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占磁盤物理讀總和，而不是單次SQL執(zhí)行所占的磁盤物理讀)。

• 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)的話，這部分比較有用。因此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ù)并沒有區(qū)分是硬分析還是軟分析。但是即使是軟分析，次數(shù)多了，也是需要關(guān)注的。這樣會(huì)消耗很多內(nèi)存資源，引起latch的等待，降低系統(tǒng)的性能。軟分析過多需要檢查應(yīng)用上是否有頻繁的游標(biāo)打開、關(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的打開子游標(biāo)的TOP SQL。一個(gè)SQL產(chǎ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ī)制來保證數(shù)據(jù)塊版本的一致性，這就出現(xiàn)了一類新的等待事件，發(fā)生在RAC實(shí)例之間的數(shù)據(jù)訪問等待。對(duì)于RAC結(jié)構(gòu)，還是采用業(yè)務(wù)分隔方式較好。這樣某個(gè)業(yè)務(wù)固定使用某個(gè)實(shí)例，它訪問的內(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)的百分比。

• 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ù)庫，需要分析每個(gè)實(shí)例的AWR報(bào)告，才能對(duì)整體性能做出客觀的評(píng)價(jià)。

• CPU used by this session

這個(gè)指標(biāo)用來上面在當(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è)過程消耗了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秒。

*總體來看，當(dāng)前數(shù)據(jù)庫每秒鐘每個(gè)CPU處理時(shí)間才0.026秒，遠(yuǎn)遠(yuǎn)算不上高負(fù)荷。數(shù)據(jù)庫CPU資源很豐富，遠(yuǎn)沒有出現(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)的磁盤的響應(yīng)時(shí)間應(yīng)當(dāng)在10ms以內(nèi)，最好不要超過20ms；如果達(dá)到了100ms，應(yīng)用基本就開始出現(xiàn)嚴(yán)重問題甚至不能正常運(yùn)行。

• Av Blks/Rd

每次讀多少個(gè)數(shù)據(jù)塊。

• Writes

發(fā)生了多少次寫。

• Av Writes/s

每秒鐘寫的次數(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

顧問信息。這塊提供了多種顧問程序，提出在不同情況下的模擬情況。包括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ù)中需要物理讀寫的數(shù)據(jù)量。

• Estd PGA Cache Hit %

估算的PGA命中率。

• Estd PGA Overalloc Count

需要在估算的PGA大小下額外分配內(nèi)存的個(gè)數(shù)。

3、Shared Pool Advisory

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

• Shared Pool Size(M)

估算的共享池大小。

• SP Size Factr

共享池大小的影響因子。

• Est LC Size (M)

估算的庫高速緩存占用的大小。

• 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

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

• NoWait Requests/Pct NoWait Miss

表示不愿意等待類型的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ì)象訪問頻繁。Buffer Busy Waits事件通常由于某些數(shù)據(jù)塊太過頻繁的訪問，導(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中沒有統(tǒng)計(jì)段級(jí)別的索引分裂計(jì)數(shù)，原來ORACLE已經(jīng)實(shí)現(xiàn)了。但是統(tǒng)計(jì)進(jìn)這個(gè)指標(biāo)中，你覺得合適嗎？

十一、其他問題

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

對(duì)SQL語句來講，只有當(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)告反映出來。盡管它在采樣周期里面的運(yùn)行，也消耗了很多資源。

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

作者：韓鋒

來源：宜信技術(shù)學(xué)院