宜信資料庫實踐|解讀Oracle AWR效能分析報告，更快定位效能瓶頸

Oracle中的AWR，全稱為Automatic Workload Repository，自動負載資訊庫。它收集關於特定資料庫的操作統計資訊和其他統計資訊，Oracle以固定的時間間隔(預設為1個小時)為其所有重要的統計資訊和負載資訊執行一次快照，並將快照存放入AWR中。這些資訊在AWR中保留指定的時間(預設為1周)，然後執行刪除。執行快照的頻率和保持時間都是可以自定義的。

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

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

一、MAIN

1、Database Information

2、Snapshot Information

(1)Sessions

表示採集例項連線的會話數。這個數可以幫助我們瞭解資料庫的併發使用者數大概的情況。這個數值對於我們判斷資料庫的型別有幫助。

(2)Cursors/session

每個會話平均開啟的遊標數。

(3)Elapsed

通過Elapsed/DB Time比較，反映出資料庫的繁忙程度。如果DB Time>>Elapsed，則說明資料庫很忙。

(4)DB Time

表示使用者操作花費的時間，包括CPU時間和等待事件。通常同時這個數值判讀資料庫的負載情況。

具體含義

db time = cpu time + wait time(不包含空閒等待)(非後臺程式)

*db time就是記錄的伺服器花在資料庫運算(非後臺程式)和等待(非空閒等待)上的時間。對應於V$SESSION的elapsed_time欄位累積。

"合集資料"

需要注意的是AWR是一個資料合集。比如在1分鐘之內，1個使用者等待了30秒鐘，那麼10個使用者等待事件就是300秒。CPU時間也是一樣，在1分鐘之內，1個CPU處理30秒鐘，那麼4個CPU就是120秒。這些時間都是以累積的方式記錄在AWR當中的。

示例

DB CPU——這是一個用於衡量CPU的使用率的重要指標。假設系統有N個CPU，那麼如果CPU全忙的話，一秒鐘內的DB CPU就是N秒。除了利用CPU進行計算外，資料庫還會利用其它計算資源，如網路、硬碟、記憶體等等，這些對資源的利用同樣可以利用時間進行度量。假設系統有M個session在執行，同一時刻有的session可能在利用CPU，有的session可能在訪問硬碟，那麼在一秒鐘內，所有session的時間加起來就可以表徵系統在這一秒內的繁忙程度。一般的，這個和的最大值應該為M。這其實就是Oracle提供的另一個重要指標：DB time，它用以衡量前端程式所消耗的總時間。

對除CPU以後的計算資源的訪問，Oracle用等待事件進行描述。同樣地，和CPU可分為前臺消耗CPU和後臺消耗CPU一樣，等待事件也可以分為前臺等待事件和後臺等待事件。DB Time一般的應該等於"DB CPU + 前臺等待事件所消耗時間"的總和。等待時間通過v$system_event檢視進行統計，DB Time和DB CPU則是通過同一個檢視，即v$sys_time_model進行統計。

--"Load Profile"中關於DB Time的描述

*這個系統的CPU個數是8，因此我們可以知道前臺程式用了系統CPU的7.1/8=88.75%。DB Time/s為11.7，可以看出這個系統是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"中關於DB CPU的描述

按照CPU/等待事件佔DB Time的比例大小，這裡列出了Top 5。如果一個工作負載是CPU繁忙型的話，那麼在這裡應該可以看到 DB CPU的影子。

*注意到，我們剛剛已經算出了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的工作負載。要知道系統CPU的繁忙程式，還要知道這個AWR所基於兩個snapshot的時間間隔，還要知道系統CPU的個數。要不繫統可以是一個很IDLE的系統呢。記住CPU利用率 = DB CPU/(CPU_COUNT*Elapsed TIME)。這個Top 5 給我們的資訊只是這個工作負載應該是並行查詢，從外部表讀取資料，並用insert append的方式寫入磁碟，同時，主要時間耗費在CPU的運算上。

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

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

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的問題。當CPU很忙時，如果系統裡存在著很多程式，就會發生程式排隊等待CPU的現象。在這樣，DB TIME是把程式排隊等待CPU的時間算在內的，而DB CPU是不包括這一部分時間。這是造成 DB CPU + FG Wait Time < DB Time的一個重要原因。如果一個系統CPU不忙，這這兩者應該就比較接近了。不要忘了在這個例子中，這是一個CPU非常繁忙的系統，而71.5%就是一個訊號，它提示著這個系統可能是一個CPU-Bound的系統。

二、Report Summary

1、Cache Sizes

這部分列出AWR在效能採集開始和結束的時候，資料緩衝池(buffer cache)和共享池(shared pool)的大小。通過對比前後的變化，可以瞭解系統記憶體消耗的變化。

2、Load Profile

這兩部分是資料庫資源負載的一個明細列表，分隔成每秒鐘的資源負載和每個事務的資源負載。

• Redo size

每秒(每個事務)產生的日誌大小(單位位元組)

• Logical reads

每秒(每個事務)產生的邏輯讀(單位是block)。在很多系統裡select執行次數要遠遠大於transaction次數。這種情況下，可以參考Logical reads/Executes。在良好的oltp環境下，這個應該不會超過50，一般只有10左右。如果這個值很大，說明有些語句需要優化。

• Block Changes

每秒(每個事務)改變的資料塊數。

• Physical reads

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

• Physical writes

每秒(每個事務)產生的物理寫(單位是block)。

• User calls

每秒(每個事務)使用者呼叫次數。User calls/Executes基本上代表了每個語句的請求次數，Executes越接近User calls越好。

• Parses

每秒(每個事務)產生的解析(或分析)的次數，包括軟解析和硬解析，但是不包括快速軟解析。軟解析每秒超過300次意味著你的"應用程式"效率不高，沒有使用soft soft parse，調整session_cursor_cache。

• Hard parses

每秒(每個事務)產生的硬解析次數。每秒超過100次，就可能說明你繫結使用的不好。

• Sorts

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

• Logons

每秒(每個事務)登入資料庫次數。

• Executes

每秒(每個事務)SQL語句執行次數。包括了使用者執行的SQL語句與系統執行的SQL語句，表示一個系統SQL語句的繁忙程度。

• Transactions

每秒的事務數。表示一個系統的事務繁忙程度。目前已知的最繁忙的系統為淘寶的線上交易系統，這個值達到了1000。

• % Blocks changed per Read

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

• Rollback per transaction %

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

• Recursive Call %

遞迴呼叫SQL的比例，在PL/SQL上執行的SQL稱為遞迴的SQL。

3、Instance Efficiency Percentages (Target 100%)

這個部分是記憶體效率的統計資訊。對於OLTP系統而言，這些值都應該儘可能地接近100%。對於OLAP系統而言，意義不太大。因為在OLAP系統中，大查詢的速度才是對效能影響的最大因素。

• Buffer Nowait %

非等待方式獲取資料塊的百分比。

這個值偏小，說明發生SQL訪問資料塊時資料塊正在被別的會話讀入記憶體，需要等待這個操作完成。發生這樣的事情通常就是某些資料塊變成了熱塊。

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

• Redo NoWait %

非等待方式獲取redo資料百分比。

• Buffer Hit %

資料緩衝命中率，表示了資料塊在資料緩衝區中的命中率。

Buffer Hit<95%，可能是要加db_cache_size，但是大量的非選擇的索引也會造成該值很高(大量的db file sequential read)。

• In-memory Sort %

資料塊在記憶體中排序的百分比。總排序中包括記憶體排序和磁碟排序。當記憶體中排序空間不足時，使用臨時表空間進行排序，這個是記憶體排序對總排序的百分比。

過低說明有大量排序在臨時表空間進行。在oltp環境下，最好是100%。如果太小，可以調整PGA引數。

• Library Hit %

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

Library Hit<95%，要考慮加大共享池，繫結變數，修改cursor_sharing等。

• Soft Parse %

軟解析佔總解析數的百分比。可以近似當作sql在共享區的命中率。

這個數值偏低，說明系統中有些SQL沒有重用，最優可能的原因就是沒有使用繫結變數。

<95%：需要考慮到繫結

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

• Execute to Parse %

執行次數對分析次數的百分比。

如果該值偏小，說明解析(硬解析和軟解析)的比例過大，快速軟解析比例小。根據實際情況，可以適當調整引數session_cursor_cache，以提高會話中sql執行的命中率。

round(100*(1-:prse/:exe),2)  即(Execute次數 - Parse次數)/Execute次數 x 100%
prse = select value from v$sysstat where name = 'parse count (total)';
exe = select value from v$sysstat where name = 'execute count';

沒繫結的話導致不能重用也是一個原因，當然sharedpool太小也有可能，單純的加session_cached_cursors也不是根治的辦法，不同的sql還是不能重用，還要解析。即使是soft parse 也會被統計入 parse count,所以這個指標並不能反應出fast soft(pga 中)/soft (shared pool中)/hard (shared pool 中新解析) 幾種解析的比例。只有在pl/sql的類似迴圈這種程式中使用使用變數才能避免大量parse，所以這個指標跟是否使用bind並沒有必然聯絡增加session_cached_cursors 是為了在大量parse的情況下把soft轉化為fast soft而節約資源。

• Latch Hit %

latch的命中率。

其值低是因為shared_pool_size過大或沒有使用繫結變數導致硬解析過多。要確保>99%，否則存在嚴重的效能問題，比如繫結等會影響該引數。

• 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解析時間)，太低表示解析消耗時間過多。

4、Shared Pool Statistics

• Memory Usage %

共享池記憶體使用率。

應該穩定在70%-90%間，太小浪費記憶體，太大則記憶體不足。

• % SQL with executions>1

執行次數大於1的SQL比率。

若太小可能是沒有使用繫結變數。

• % Memory for SQL w/exec>1

執行次數大於1的SQL消耗記憶體/所有SQL消耗的記憶體(即memory for sql with execution > 1)。

5、Top 5 Timed Events

三、RAC Statistics

這一部分只在有RAC環境下才會出現，是一些全域性記憶體中資料傳送、接收方面的效能指標，還有一些全域性鎖的資訊。除非這個資料庫在執行正常是設定了一個基線作為參照，否則很難從這部分資料中直接看出效能問題。

經驗

Oracle公司經驗，下面GCS和GES各項指標中，凡是與時間相關的指標，只要GCS指標低於10ms，GES指標低於15ms，則一般表示節點間通訊效率正常。但是，即便時間指標正常，也不表示應用本身或應用在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很大，說明節點間存在大量的塊爭用。

四、Wait Events Statistics

1、Time Model Statistics

這部分資訊列出了各種操作佔用的資料庫時間比例。

• parse time elapsed/hard parse elapsed time

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

• % Not-Parse CPU

花費在非解析上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對系統CPU的資源利用情況。

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

這裡 5.3/8 = 66.25 %

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

2、Wait Class

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

3、Wait Events

這一部分是整個例項等待事件的明細，它包含了TOP 5等待事件的資訊。

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

4、Background Wait Events

這一部分是例項後臺程式的等待事件。如果我們懷疑那個後臺程式(比如DBWR)無法及時響應，可以在這裡確認一下是否有後臺程式等待時間過長的事件存在。

5、Operating System Statistics

(1)背景知識

如果關注資料庫的效能，那麼當拿到一份AWR報告的時候，最想知道的第一件事情可能就是系統資源的利用情況了，而首當其衝的，就是CPU。而細分起來，CPU可能指的是：

• OS級的User%, Sys%, Idle%

• DB所佔OS CPU資源的Busy%

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

(2)11g

如果資料庫的版本是11g，那麼很幸運的，這些資訊在AWR報告中一目瞭然：

OS級的%User為75.4，%Sys為2.8，%Idle為21.2，所以%Busy應該是78.8。

DB佔了OS CPU資源的69.1，%Busy CPU則可以通過上面的資料得到:%Busy CPU = %Total CPU/(%Busy) * 100 = 69.1/78.8 * 100 = 87.69，和報告的87.7相吻合。

(3)10g

如果是10g，則需要手工對Report裡的一些資料進行計算了。Host CPU的結果來源於DBA_HIST_OSSTAT，AWR報告裡已經幫忙整出了這段時間內的絕對資料(這裡的時間單位是釐秒-也就是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

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

BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT

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

時間統計檢視v$sys_time_model

至於DB對CPU的利用情況，這就涉及到10g新引入的一個關於時間統計的檢視 - v$sys_time_model。簡單而言，Oracle採用了一個統一的時間模型對一些重要的時間指標進行了記錄，具體而言，這些指標包括：

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

我們這裡關注的只有和CPU相關的兩個: background cpu time 和 DB CPU。這兩個值在AWR裡面也有記錄。

五、SQL Statistics

1、SQL ordered by Elapsed Time

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

• Elapsed Time(S)

SQL語句執行用總時長，此排序就是按照這個欄位進行的。注意該時間不是單個SQL跑的時間，而是監控範圍內SQL執行次數的總和時間。單位時間為秒。Elapsed Time = CPU Time + Wait Time

• CPU Time(s)

為SQL語句執行時CPU佔用時間總時長，此時間會小於等於Elapsed Time時間。單位時間為秒。

• Executions

SQL語句在監控範圍內的執行次數總計。如果Executions=0，則說明語句沒有正常完成，被中間停止，需要關注。

• Elap per Exec(s)

執行一次SQL的平均時間。單位時間為秒。

• % Total DB Time

為SQL的Elapsed Time時間佔資料庫總時間的百分比。

• SQL ID

SQL語句的ID編號，點選之後就能導航到下邊的SQL詳細列表中，點選IE的返回可以回到當前SQL ID的地方。

• SQL Module

顯示該SQL是用什麼方式連線到資料庫執行的，如果是用SQL*Plus或者PL/SQL連結上來的那基本上都是有人在除錯程式。一般用前臺應用連結過來執行的sql該位置為空。

• SQL Text

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

分析說明

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

如果SQL語句執行次數很多，需要關注一些對應表的記錄變化。如果變化不大，需要從前面考慮是否大多數操作都進行了Rollback，導致大量的無用功。

2、SQL ordered by CPU Time

記錄了執行佔CPU時間總和時間最長的TOP SQL(請注意是監控範圍內該SQL的執行佔CPU時間總和，而不是單次SQL執行時間)。這部分是SQL消耗的CPU時間從高到底的排序。

• CPU Time (s)

SQL消耗的CPU時間。

• Elapsed Time (s)

SQL執行時間。

• Executions

SQL執行次數。

• CPU per Exec (s)

每次執行消耗CPU時間。

• % Total DB Time

SQL執行時間佔總共DB time的百分比。

3、SQL ordered by Gets

這部分列出SQL獲取的記憶體資料塊的數量，按照由大到小的順序排序。buffer get其實就是邏輯讀或一致性讀。在sql 10046裡面，也叫query read。表示一個語句在執行期間的邏輯IO，單位是塊。在報告中，該數值是一個累計值。Buffer Get=執行次數 * 每次的buffer get。記錄了執行佔總buffer gets(邏輯IO)的TOP SQL(請注意是監控範圍內該SQL的執行佔Gets總和，而不是單次SQL執行所佔的Gets)。

• Buffer Gets

SQL執行獲得的記憶體資料塊數量。

• Executions

SQL執行次數。

• Gets per Exec

每次執行獲得的記憶體資料塊數量。

• %Total

佔總數的百分比。

• CPU Time (s)

消耗的CPU時間。

• Elapsed Time (s)

SQL執行時間。

篩選SQL的標準

因為statspack/awr列出的是總體的top buffer，它們關心的是總體的效能指標，而不是把重心放在只執行一次的語句上。為了防止過大，採用了以下原則。如果有sql沒有使用繫結變數，執行非常差但是由於沒有繫結，因此係統人為是不同的sql。有可能不會被列入到這個列表中。

大於閥值buffer_gets_th的數值，這是sql執行緩衝區獲取的數量(預設10000)。

小於define top_n_sql=65的數值。

4、SQL ordered by Reads

這部分列出了SQL執行物理讀的資訊，按照從高到低的順序排序。記錄了執行佔總磁碟物理讀(物理IO)的TOP SQL(請注意是監控範圍內該SQL的執行佔磁碟物理讀總和，而不是單次SQL執行所佔的磁碟物理讀)。

• Physical Reads

SQL物理讀的次數。

• Executions

SQL執行次數。

• Reads per Exec

SQL每次執行產生的物理讀。

• %Total

佔整個物理讀的百分比。

• CPU Time (s)

SQL執行消耗的CPU時間。

• Elapsed Time (s)

SQL的執行時間。

5、SQL ordered by Executions

這部分列出了SQL執行次數的資訊，按照從大到小的順序排列。如果是OLTP系統的話，這部分比較有用。因此SQL執行頻率非常大，SQL的執行次數會對效能有比較大的影響。OLAP系統因為SQL重複執行的頻率很低，因此意義不大。

• Executions

SQL的執行次數。

• Rows Processed

SQL處理的記錄數。

• Rows per Exec

SQL每次執行處理的記錄數。

• CPU per Exec (s)

每次執行消耗的CPU時間。

• Elap per Exec (s)

每次執行的時長。

6、SQL ordered by Parse Calls

這部分列出了SQL按分析次(軟解析)數的資訊，按照從高到底的順序排列。這部分對OLTP系統比較重要，這裡列出的總分析次數並沒有區分是硬分析還是軟分析。但是即使是軟分析，次數多了，也是需要關注的。這樣會消耗很多記憶體資源，引起latch的等待，降低系統的效能。軟分析過多需要檢查應用上是否有頻繁的遊標開啟、關閉操作。

• Parse Calls

SQL分析的次數。

• Executions

SQL執行的次數。

• % Total Parses

佔整個分析次數的百分比。

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的開啟子游標的TOP SQL。一個SQL產生多版本的原因有很多，可以查詢檢視v$sql_sahred_cursor檢視瞭解具體原因。對於OLTP系統，這部分值得關注，瞭解SQL被重用的情況。

• Version Count

SQL的版本數。

• Executions

SQL的執行次數。

9、SQL ordered by Cluster Wait Time

記錄了叢集的等待時間的TOP SQL。這部分只在RAC環境中存在，列出了例項之間共享記憶體資料時發生的等待。在RAC環境下，幾個例項之間需要有一種鎖的機制來保證資料塊版本的一致性，這就出現了一類新的等待事件，發生在RAC例項之間的資料訪問等待。對於RAC結構，還是採用業務分隔方式較好。這樣某個業務固定使用某個例項，它訪問的記憶體塊就會固定地存在某個例項的記憶體中，這樣降低了例項之間的GC等待事件。此外，如果RAC結構採用負載均衡模式，這樣每個例項都會被各種應用的會話連線，大量的資料塊需要在各個例項的記憶體中被拷貝和鎖定，會加劇GC等待事件。

• Cluster Wait Time (s)

叢集等待時長。

• CWT % of Elapsd Time

叢集操作等待時長佔總時長的百分比。

• Elapsed Time(s)

SQL執行總時長。

10、Complete List of SQL Text

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

六、Instance Activity Statistics

1、Instance Activity Stats

這部分是例項的資訊統計，專案非常多。對於RAC架構的資料庫，需要分析每個例項的AWR報告，才能對整體效能做出客觀的評價。

• CPU used by this session

這個指標用來上面在當前的效能採集區間裡面，Oracle消耗的CPU單位。一個CPU單位是1/100秒。從這個指標可以看出CPU的負載情況。

案例 - 分析系統CPU繁忙程度

在TOP5等待事件裡，找到"CPU time"，可以看到系統消耗CPU的時間為26469秒。

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

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

*總體來看，當前資料庫每秒鐘每個CPU處理時間才0.026秒，遠遠算不上高負荷。資料庫CPU資源很豐富，遠沒有出現瓶頸。

七、IO Stats

1、Tablespace IO Stats

表空間的I/O效能統計。

• Reads

發生了多少次物理讀。

• Av Reads/s

每秒鐘物理讀的次數。

• Av Rd(ms)

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

• Av Blks/Rd

每次讀多少個資料塊。

• Writes

發生了多少次寫。

• Av Writes/s

每秒鐘寫的次數。  

• Buffer Waits

獲取記憶體資料塊等待的次數。

• Av Buf Wt(ms)

獲取記憶體資料塊平均等待時間。

2、File IO Stats

檔案級別的I/O統計。

八、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

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

• Buffers for Estimate

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

• Est Phys Read Factor

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

• Estimated Physical Reads

估計的物理讀次數。

2、PGA Memory Advisory

PGA的大小建議。

• PGA Target Est (MB)

PGA的估算大小。

• Size Factr

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

• W/A MB Processed

Oracle為了產生影響估算處理的資料量。

• Estd Extra W/A MB Read/ Written to Disk

處理資料中需要物理讀寫的資料量。

• Estd PGA Cache Hit %

估算的PGA命中率。

• Estd PGA Overalloc Count

需要在估算的PGA大小下額外分配記憶體的個數。

3、Shared Pool Advisory

建議器通過設定不同的共享池大小，來獲取相應的效能指標值。

• Shared Pool Size(M)

估算的共享池大小。

• SP Size Factr

共享池大小的影響因子。

• Est LC Size (M)

估算的庫快取記憶體佔用的大小。

• Est LC Mem Obj

快取記憶體中的物件數。

• Est LC Time Saved (s)

需要額外將物件讀入共享池的時間。

• Est LC Time Saved Factr

物件讀入共享池時間的影響因子。

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

• Est LC Load Time (s)

分析所花費的時間。

• Est LC Load Time Factr

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

• Est LC Mem Obj Hits

記憶體中物件被發現的次數。

4、SGA Target Advisory

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

• SGA Target Size (M)

估算的SGA大小。

• SGA Size Factor

SGA大小的影響因子。

• Est DB Time (s)

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

• Est Physical Reads

物理讀的次數。

九、Latch Statistics

1、Latch Activity

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

表示願意等待型別的latch的統計資訊。

• NoWait Requests/Pct NoWait Miss

表示不願意等待型別的latch的統計資訊。

• Pct Misses

比例最好接近0。

十、Segment Statistics

1、Segments by Logical Reads

段的邏輯讀情況。

2、 Segments by Physical Reads

段的物理讀情況。

3、Segments by Buffer Busy Waits

從這部分可以發現那些物件訪問頻繁。Buffer Busy Waits事件通常由於某些資料塊太過頻繁的訪問，導致熱點塊的產生。

4、Segments by Row Lock Waits

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

十一、其他問題

SQL執行週期對報告的影響

對SQL語句來講，只有當它執行完畢之後，它的相關資訊才會被Oracle所記錄(比如：CPU時間、SQL執行時長等)。當時當某個SQL終止於做AWR報告選取的2個快照間隔時間之後，那麼它的資訊就不能被這個AWR報告反映出來。儘管它在取樣週期裡面的執行，也消耗了很多資源。

也就是說某個區間的效能報告並不能精確地反映出在這個取樣週期中資源的消耗情況。因為有些在這個區間執行的SQL可能結束於這個時間週期之後，也可能有一些SQL在這個週期開始之前就已經執行了很久，恰好結束於這個取樣週期。這些因素都導致了取樣週期裡面的資料並不絕對是這個時間段發生的所有資料庫操作的資源使用的資料。

作者：韓鋒

來源： 宜信技術學院  

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69918724/viewspace-2644116/，如需轉載，請註明出處，否則將追究法律責任。