摘要：表示用戶操作花費的時間，包括時間和等待事件。當(dāng)內(nèi)存中排序空間不足時，使用臨時表空間進行排序，這個是內(nèi)存排序?qū)偱判虻陌俜直取＿^低說明有大量排序在臨時表空間進行。要確保，否則存在嚴(yán)重的性能問題，比如綁定等會影響該參數(shù)。

Oracle中的AWR，全稱為Automatic Workload Repository，自動負載信息庫。它收集關(guān)于特定數(shù)據(jù)庫的操作統(tǒng)計信息和其他統(tǒng)計信息，Oracle以固定的時間間隔(默認(rèn)為1個小時)為其所有重要的統(tǒng)計信息和負載信息執(zhí)行一次快照，并將快照存放入AWR中。這些信息在AWR中保留指定的時間(默認(rèn)為1周)，然后執(zhí)行刪除。執(zhí)行快照的頻率和保持時間都是可以自定義的。

AWR的引入，為我們分析數(shù)據(jù)庫提供了非常好的便利條件(這方面MySQL就相差了太多)。曾經(jīng)有這樣的一個比喻——“一個系統(tǒng)，就像是一個黑暗的大房間，系統(tǒng)收集的統(tǒng)計信息，就如同放置在房間不同位置的蠟燭，用于照亮這個黑暗大房間。Oracle，恰到好處地放置了足夠的蠟燭(AWR)，房間中只有極少的燭光未覆蓋之處，性能瓶頸就容易定位。而對于蠟燭較少或是沒有蠟燭的系統(tǒng)，性能優(yōu)化就如同黑暗中的舞者。”

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

(1)Sessions

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

(2)Cursors/session

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

(3)Elapsed

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

(4)DB Time

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

db time = cpu time + wait time(不包含空閑等待)(非后臺進程)

*db time就是記錄的服務(wù)器花在數(shù)據(jù)庫運算(非后臺進程)和等待(非空閑等待)上的時間。對應(yīng)于V$SESSION的elapsed_time字段累積。

需要注意的是AWR是一個數(shù)據(jù)合集。比如在1分鐘之內(nèi)，1個用戶等待了30秒鐘，那么10個用戶等待事件就是300秒。CPU時間也是一樣，在1分鐘之內(nèi)，1個CPU處理30秒鐘，那么4個CPU就是120秒。這些時間都是以累積的方式記錄在AWR當(dāng)中的。

DB CPU——這是一個用于衡量CPU的使用率的重要指標(biāo)。假設(shè)系統(tǒng)有N個CPU，那么如果CPU全忙的話，一秒鐘內(nèi)的DB CPU就是N秒。除了利用CPU進行計算外，數(shù)據(jù)庫還會利用其它計算資源，如網(wǎng)絡(luò)、硬盤、內(nèi)存等等，這些對資源的利用同樣可以利用時間進行度量。假設(shè)系統(tǒng)有M個session在運行，同一時刻有的session可能在利用CPU，有的session可能在訪問硬盤，那么在一秒鐘內(nèi)，所有session的時間加起來就可以表征系統(tǒng)在這一秒內(nèi)的繁忙程度。一般的，這個和的最大值應(yīng)該為M。這其實就是Oracle提供的另一個重要指標(biāo)：DB time，它用以衡量前端進程所消耗的總時間。

對除CPU以后的計算資源的訪問，Oracle用等待事件進行描述。同樣地，和CPU可分為前臺消耗CPU和后臺消耗CPU一樣，等待事件也可以分為前臺等待事件和后臺等待事件。DB Time一般的應(yīng)該等于"DB CPU + 前臺等待事件所消耗時間"的總和。等待時間通過v$system\_event視圖進行統(tǒng)計，DB Time和DB CPU則是通過同一個視圖，即v$sys_time_model進行統(tǒng)計。

--"Load Profile"中關(guān)于DB Time的描述

*這個系統(tǒng)的CPU個數(shù)是8，因此我們可以知道前臺進程用了系統(tǒng)CPU的7.1/8=88.75%。DB Time/s為11.7，可以看出這個系統(tǒng)是CPU非常繁忙的。里面CPU占了7.1，則其它前臺等待事件占了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。如果一個工作負載是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"的局限性

再研究下這個Top 5 Timed Foreground Events，如果先不看Load Profile，是不能計算出一個CPU-Bound的工作負載。要知道系統(tǒng)CPU的繁忙程序，還要知道這個AWR所基于兩個snapshot的時間間隔，還要知道系統(tǒng)CPU的個數(shù)。要不系統(tǒng)可以是一個很IDLE的系統(tǒng)呢。記住CPU利用率 = DB CPU/(CPU_COUNT*Elapsed TIME)。這個Top 5 給我們的信息只是這個工作負載應(yīng)該是并行查詢，從外部表讀取數(shù)據(jù)，并用insert append的方式寫入磁盤，同時，主要時間耗費在CPU的運算上。

--解讀"DB Time" > "DB CPU" + "前臺等待事件所消耗時間" ——進程排隊時間

上面提到，DB Time一般的應(yīng)該等于DB CPU + 前臺等待事件所消耗時間的總和。在下面有對這三個值的統(tǒng)計：

DB CPU = 6474.65

DB TIME = 10711.2

FG Wait Time = 1182.63

明顯的，DB CPU + FG Wait Time < DB Time，只占了71.5%

*其它的28.5%被消耗到哪里去了呢?這里其實又隱含著一個Oracle如何計算DB CPU和DB Time的問題。當(dāng)CPU很忙時，如果系統(tǒng)里存在著很多進程，就會發(fā)生進程排隊等待CPU的現(xiàn)象。在這樣，DB TIME是把進程排隊等待CPU的時間算在內(nèi)的，而DB CPU是不包括這一部分時間。這是造成 DB CPU + FG Wait Time < DB Time的一個重要原因。如果一個系統(tǒng)CPU不忙，這這兩者應(yīng)該就比較接近了。不要忘了在這個例子中，這是一個CPU非常繁忙的系統(tǒng)，而71.5%就是一個信號，它提示著這個系統(tǒng)可能是一個CPU-Bound的系統(tǒng)。

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

這兩部分是數(shù)據(jù)庫資源負載的一個明細列表，分隔成每秒鐘的資源負載和每個事務(wù)的資源負載。

Redo size

每秒(每個事務(wù))產(chǎn)生的日志大小(單位字節(jié))

Logical reads

每秒(每個事務(wù))產(chǎn)生的邏輯讀(單位是block)。在很多系統(tǒng)里select執(zhí)行次數(shù)要遠遠大于transaction次數(shù)。這種情況下，可以參考Logical reads/Executes。在良好的oltp環(huán)境下，這個應(yīng)該不會超過50，一般只有10左右。如果這個值很大，說明有些語句需要優(yōu)化。

Block Changes

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

Physical reads

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

Physical writes

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

User calls

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

Parses

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

Hard parses

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

Sorts

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

Logons

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

Executes

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

Transactions

每秒的事務(wù)數(shù)。表示一個系統(tǒng)的事務(wù)繁忙程度。目前已知的最繁忙的系統(tǒng)為淘寶的在線交易系統(tǒng)，這個值達到了1000。

% Blocks changed per Read

表示邏輯讀用于只讀而不是修改的塊的比例。如果有很多PLSQL，那么就會比較高。

Rollback per transaction %

看回滾率是不是很高，因為回滾很耗資源。

Recursive Call %

遞歸調(diào)用SQL的比例，在PL/SQL上執(zhí)行的SQL稱為遞歸的SQL。

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

Buffer Nowait %

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

這個值偏小，說明發(fā)生SQL訪問數(shù)據(jù)塊時數(shù)據(jù)塊正在被別的會話讀入內(nèi)存，需要等待這個操作完成。發(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，但是大量的非選擇的索引也會造成該值很高(大量的db file sequential read)。

In-memory Sort %

數(shù)據(jù)塊在內(nèi)存中排序的百分比。總排序中包括內(nèi)存排序和磁盤排序。當(dāng)內(nèi)存中排序空間不足時，使用臨時表空間進行排序，這個是內(nèi)存排序?qū)偱判虻陌俜直取?/p>

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

Library Hit %

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

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

Soft Parse %

軟解析占總解析數(shù)的百分比。可以近似當(dāng)作sql在共享區(qū)的命中率。

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

<95%：需要考慮到綁定

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

Execute to Parse %

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

如果該值偏小，說明解析(硬解析和軟解析)的比例過大，快速軟解析比例小。根據(jù)實際情況，可以適當(dāng)調(diào)整參數(shù)session_cursor_cache，以提高會話中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)致不能重用也是一個原因，當(dāng)然sharedpool太小也有可能，單純的加session_cached_cursors也不是根治的辦法，不同的sql還是不能重用，還要解析。即使是soft parse 也會被統(tǒng)計入 parse count,所以這個指標(biāo)并不能反應(yīng)出fast soft(pga 中)/soft (shared pool中)/hard (shared pool 中新解析) 幾種解析的比例。只有在pl/sql的類似循環(huán)這種程序中使用使用變量才能避免大量parse，所以這個指標(biāo)跟是否使用bind并沒有必然聯(lián)系增加session_cached_cursors 是為了在大量parse的情況下把soft轉(zhuǎn)化為fast soft而節(jié)約資源。

Latch Hit %

latch的命中率。

其值低是因為shared_pool_size過大或沒有使用綁定變量導(dǎo)致硬解析過多。要確保>99%，否則存在嚴(yán)重的性能問題，比如綁定等會影響該參數(shù)。

Parse CPU to Parse Elapsd %

解析總時間中消耗CPU的時間百分比。即:100*(parse time cpu / parse time elapsed)

解析實際運行事件/(解析實際運行時間+解析中等待資源時間)，越高越好。

% Non-Parse CPU

CPU非分析時間在整個CPU時間的百分比。

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

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

Memory Usage %

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

應(yīng)該穩(wěn)定在70%-90%間，太小浪費內(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)。

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

Oracle公司經(jīng)驗，下面GCS和GES各項指標(biāo)中，凡是與時間相關(guān)的指標(biāo)，只要GCS指標(biāo)低于10ms，GES指標(biāo)低于15ms，則一般表示節(jié)點間通訊效率正常。但是，即便時間指標(biāo)正常，也不表示應(yīng)用本身或應(yīng)用在RAC部署中沒有問題。

*如果CR的%Busy很大，說明節(jié)點間存在大量的塊爭用。

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

parse time elapsed/hard parse elapsed time

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

% Not-Parse CPU

花費在非解析上CPU消耗占整個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的值相吻合。

其實，在Load Profile部分，我們也可以看出DB對系統(tǒng)CPU的資源利用情況。

用DB CPU per Second除以CPU Count就可以得到DB在前臺所消耗的CPU%了。

這里 5.3/8 = 66.25 %

比69.1%稍小，說明DB在后臺也消耗了大約3%的CPU。

這一部分是等待的類型。可以看出那類等待占用的時間最長。

這一部分是整個實例等待事件的明細，它包含了TOP 5等待事件的信息。

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

這一部分是實例后臺進程的等待事件。如果我們懷疑那個后臺進程(比如DBWR)無法及時響應(yīng)，可以在這里確認(rèn)一下是否有后臺進程等待時間過長的事件存在。

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

OS級的User%, Sys%, Idle%

DB所占OS CPU資源的Busy%

DB CPU又可以分為前臺所消耗的CPU和后臺所消耗的CPU

如果數(shù)據(jù)庫的版本是11g，那么很幸運的，這些信息在AWR報告中一目了然：

OS級的%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，和報告的87.7相吻合。

如果是10g，則需要手工對Report里的一些數(shù)據(jù)進行計算了。Host CPU的結(jié)果來源于DBA_HIST_OSSTAT，AWR報告里已經(jīng)幫忙整出了這段時間內(nèi)的絕對數(shù)據(jù)(這里的時間單位是厘秒-也就是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

這里已經(jīng)隱含著這個AWR報告所捕捉的兩個snapshot之間的時間長短了。有下面的公式。正確的理解這個公式可以對系統(tǒng)CPU資源的使用及其度量的方式有更深一步的理解。

BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT

推算出：ELAPSED_TIME = (152946+41230)/8/100 = 242.72 seconds //這是正確的。

至于DB對CPU的利用情況，這就涉及到10g新引入的一個關(guān)于時間統(tǒng)計的視圖 - v$sys_time_model。簡單而言，Oracle采用了一個統(tǒng)一的時間模型對一些重要的時間指標(biāo)進行了記錄，具體而言，這些指標(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)的兩個: background cpu time 和 DB CPU。這兩個值在AWR里面也有記錄。

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

Elapsed Time(S)

SQL語句執(zhí)行用總時長，此排序就是按照這個字段進行的。注意該時間不是單個SQL跑的時間，而是監(jiān)控范圍內(nèi)SQL執(zhí)行次數(shù)的總和時間。單位時間為秒。Elapsed Time = CPU Time + Wait Time

CPU Time(s)

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

Executions

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

Elap per Exec(s)

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

% Total DB Time

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

SQL ID

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

SQL Module

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

SQL Text

簡單的SQL提示，詳細的需要點擊SQL ID。

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

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

記錄了執(zhí)行占CPU時間總和時間最長的TOP SQL(請注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占CPU時間總和，而不是單次SQL執(zhí)行時間)。這部分是SQL消耗的CPU時間從高到底的排序。

CPU Time (s)

SQL消耗的CPU時間。

Elapsed Time (s)

SQL執(zhí)行時間。

Executions

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

CPU per Exec (s)

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

% Total DB Time

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

這部分列出SQL獲取的內(nèi)存數(shù)據(jù)塊的數(shù)量，按照由大到小的順序排序。buffer get其實就是邏輯讀或一致性讀。在sql 10046里面，也叫query read。表示一個語句在執(zhí)行期間的邏輯IO，單位是塊。在報告中，該數(shù)值是一個累計值。Buffer Get=執(zhí)行次數(shù) * 每次的buffer get。記錄了執(zhí)行占總buffer gets(邏輯IO)的TOP SQL(請注意是監(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時間。

Elapsed Time (s)

SQL執(zhí)行時間。

因為statspack/awr列出的是總體的top buffer，它們關(guān)心的是總體的性能指標(biāo)，而不是把重心放在只執(zhí)行一次的語句上。為了防止過大，采用了以下原則。如果有sql沒有使用綁定變量，執(zhí)行非常差但是由于沒有綁定，因此系統(tǒng)人為是不同的sql。有可能不會被列入到這個列表中。

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

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

這部分列出了SQL執(zhí)行物理讀的信息，按照從高到低的順序排序。記錄了執(zhí)行占總磁盤物理讀(物理IO)的TOP SQL(請注意是監(jiān)控范圍內(nèi)該SQL的執(zhí)行占磁盤物理讀總和，而不是單次SQL執(zhí)行所占的磁盤物理讀)。

Physical Reads

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

Executions

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

Reads per Exec

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

%Total

占整個物理讀的百分比。

CPU Time (s)

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

Elapsed Time (s)

SQL的執(zhí)行時間。

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

Executions

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

Rows Processed

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

Rows per Exec

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

CPU per Exec (s)

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

Elap per Exec (s)

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

這部分列出了SQL按分析次(軟解析)數(shù)的信息，按照從高到底的順序排列。這部分對OLTP系統(tǒng)比較重要，這里列出的總分析次數(shù)并沒有區(qū)分是硬分析還是軟分析。但是即使是軟分析，次數(shù)多了，也是需要關(guān)注的。這樣會消耗很多內(nèi)存資源，引起latch的等待，降低系統(tǒng)的性能。軟分析過多需要檢查應(yīng)用上是否有頻繁的游標(biāo)打開、關(guān)閉操作。

Parse Calls

SQL分析的次數(shù)。

Executions

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

% Total Parses

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

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

Sharable Mem (b)

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

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

Version Count

SQL的版本數(shù)。

Executions

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

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

Cluster Wait Time (s)

集群等待時長。

CWT % of Elapsd Time

集群操作等待時長占總時長的百分比。

Elapsed Time(s)

SQL執(zhí)行總時長。

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

這部分是實例的信息統(tǒng)計，項目非常多。對于RAC架構(gòu)的數(shù)據(jù)庫，需要分析每個實例的AWR報告，才能對整體性能做出客觀的評價。

CPU used by this session

這個指標(biāo)用來上面在當(dāng)前的性能采集區(qū)間里面，Oracle消耗的CPU單位。一個CPU單位是1/100秒。從這個指標(biāo)可以看出CPU的負載情況。

在TOP5等待事件里，找到"CPU time"，可以看到系統(tǒng)消耗CPU的時間為26469秒。

在實例統(tǒng)計部分，可以看到整個過程消耗了1813626個CPU單位。每秒鐘消耗21個CPU單位，對應(yīng)實際的時間就是0.21秒。也就是每秒鐘CPU的處理時間為0.21秒。

系統(tǒng)內(nèi)CPU個數(shù)為8。每秒鐘每個CPU消耗是21/8=2.6(個CPU單位)。在一秒鐘內(nèi)，每個CPU處理時間就是2.6/100=0.026秒。

*總體來看，當(dāng)前數(shù)據(jù)庫每秒鐘每個CPU處理時間才0.026秒，遠遠算不上高負荷。數(shù)據(jù)庫CPU資源很豐富，遠沒有出現(xiàn)瓶頸。

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

Reads

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

Av Reads/s

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

Av Rd(ms)

平均一次物理讀的時間(毫秒)。一個高相應(yīng)的磁盤的響應(yīng)時間應(yīng)當(dāng)在10ms以內(nèi)，最好不要超過20ms；如果達到了100ms，應(yīng)用基本就開始出現(xiàn)嚴(yán)重問題甚至不能正常運行。

Av Blks/Rd

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

Writes

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

Av Writes/s

每秒鐘寫的次數(shù)。

Buffer Waits

獲取內(nèi)存數(shù)據(jù)塊等待的次數(shù)。

Av Buf Wt(ms)

獲取內(nèi)存數(shù)據(jù)塊平均等待時間。

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

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

Buffer pool的大小建議。

Size for Est (M)

Oracle估算Buffer pool的大小。

Size Factor

估算值與實際值的比例。如果0.9就表示估算值是實際值的0.9倍。1.0表示buffer pool的實際大小。

Buffers for Estimate

估算的Buffer的大小(數(shù)量)。

Est Phys Read Factor

估算的物理讀的影響因子，是估算物理讀和實際物理讀的一個比例。1.0表示實際的物理讀。

Estimated Physical Reads

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

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)存的個數(shù)。

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

Shared Pool Size(M)

估算的共享池大小。

SP Size Factr

共享池大小的影響因子。

Est LC Size (M)

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

Est LC Mem Obj

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

Est LC Time Saved (s)

需要額外將對象讀入共享池的時間。

Est LC Time Saved Factr

對象讀入共享池時間的影響因子。

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

Est LC Load Time (s)

分析所花費的時間。

Est LC Load Time Factr

分析花費時間的影響因子。

Est LC Mem Obj Hits

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

建議器對SGA整體的性能的一個建議。

SGA Target Size (M)

估算的SGA大小。

SGA Size Factor

SGA大小的影響因子。

Est DB Time (s)

估算的SGA大小計算出的DB Time。

Est Physical Reads

物理讀的次數(shù)。

Get Requests/Pct Get Miss/Avg Slps /Miss

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

NoWait Requests/Pct NoWait Miss

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

Pct Misses

比例最好接近0。

段的邏輯讀情況。

段的物理讀情況。

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

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

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

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

作者：韓鋒

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