程序員筆記|按部就班解讀Oracle AWR性能分析報告

Oracle中的AWR，全稱爲Automatic Workload Repository，自動負載信息庫。它收集關於特定數據庫的操做統計信息和其餘統計信息，Oracle以固定的時間間隔(默認爲1個小時)爲其全部重要的統計信息和負載信息執行一次快照，並將快照存放入AWR中。這些信息在AWR中保留指定的時間(默認爲1周)，而後執行刪除。執行快照的頻率和保持時間都是能夠自定義的。

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

那如何解讀AWR的數據呢？Oracle自己提供了一些報告，方便進行查看、分析。下面就針對最爲常見的一種報告——《AWR數據庫報告》進行說明。但願經過這篇文章，能方便你們更好地利用AWR，方便進行分析工做。

1、MAIN

一、Database Information

二、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的系統。

2、Report Summary

一、Cache Sizes

這部分列出AWR在性能採集開始和結束的時候，數據緩衝池(buffer cache)和共享池(shared pool)的大小。經過對比先後的變化，能夠了解系統內存消耗的變化。

二、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。

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

四、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)。

五、Top 5 Timed Events

3、RAC Statistics

這一部分只在有RAC環境下才會出現，是一些全局內存中數據發送、接收方面的性能指標，還有一些全局鎖的信息。除非這個數據庫在運行正常是設定了一個基線做爲參照，不然很難從這部分數據中直接看出性能問題。

經驗

Oracle公司經驗，下面GCS和GES各項指標中，凡是與時間相關的指標，只要GCS指標低於10ms，GES指標低於15ms，則通常表示節點間通信效率正常。可是，即使時間指標正常，也不表示應用自己或應用在RAC部署中沒有問題。

一、Global Cache Load Profile

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

三、Global Cache and Enqueue Services - Workload Characteristics

四、Global Cache and Enqueue Services - Messaging Statistics

五、Global Cache Transfer Stats

*若是CR的%Busy很大，說明節點間存在大量的塊爭用。

4、Wait Events Statistics

一、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。

二、Wait Class

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

三、Wait Events

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

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

四、Background Wait Events

這一部分是實例後臺進程的等待事件。若是咱們懷疑那個後臺進程(好比DBWR)沒法及時響應，能夠在這裏確認一下是否有後臺進程等待時間過長的事件存在。

五、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裏面也有記錄。

5、SQL Statistics

一、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，致使大量的無用功。

二、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的百分比。

三、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的數值。

四、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的執行時間。

五、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)

每次執行的時長。

六、SQL ordered by Parse Calls

這部分列出了SQL按分析次(軟解析)數的信息，按照從高到底的順序排列。這部分對OLTP系統比較重要，這裏列出的總分析次數並無區分是硬分析仍是軟分析。可是即便是軟分析，次數多了，也是須要關注的。這樣會消耗不少內存資源，引發latch的等待，下降系統的性能。軟分析過多須要檢查應用上是否有頻繁的遊標打開、關閉操做。

• Parse Calls

SQL分析的次數。

• Executions

SQL執行的次數。

• % Total Parses

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

七、SQL ordered by Sharable Memory

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

• Sharable Mem (b)

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

八、SQL ordered by Version Count

這部分列出了SQL多版本的信息。記錄了SQL的打開子游標的TOP SQL。一個SQL產生多版本的緣由有不少，能夠查詢視圖v$sql_sahred_cursor視圖瞭解具體緣由。對於OLTP系統，這部分值得關注，瞭解SQL被重用的狀況。

• Version Count

SQL的版本數。

• Executions

SQL的執行次數。

九、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執行總時長。

十、Complete List of SQL Text

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

6、Instance Activity Statistics

一、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資源很豐富，遠沒有出現瓶頸。

7、IO Stats

一、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)

獲取內存數據塊平均等待時間。

二、File IO Stats

文件級別的I/O統計。

8、Advisory Statistics

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

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

估計的物理讀次數。

二、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大小下額外分配內存的個數。

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

內存中對象被發現的次數。

四、SGA Target Advisory

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

• SGA Target Size (M)

估算的SGA大小。

• SGA Size Factor

SGA大小的影響因子。

• Est DB Time (s)

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

• Est Physical Reads

物理讀的次數。

9、Latch Statistics

一、Latch Activity

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

表示願意等待類型的latch的統計信息。

• NoWait Requests/Pct NoWait Miss

表示不肯意等待類型的latch的統計信息。

• Pct Misses

比例最好接近0。

10、Segment Statistics

一、Segments by Logical Reads

段的邏輯讀狀況。

二、 Segments by Physical Reads

段的物理讀狀況。

三、Segments by Buffer Busy Waits

從這部分能夠發現那些對象訪問頻繁。Buffer Busy Waits事件一般因爲某些數據塊太過頻繁的訪問，致使熱點塊的產生。

四、Segments by Row Lock Waits

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

11、其餘問題

SQL運行週期對報告的影響

對SQL語句來說，只有當它執行完畢以後，它的相關信息纔會被Oracle所記錄(好比：CPU時間、SQL執行時長等)。當時當某個SQL終止於作AWR報告選取的2個快照間隔時間以後，那麼它的信息就不能被這個AWR報告反映出來。儘管它在採樣週期裏面的運行，也消耗了不少資源。

也就是說某個區間的性能報告並不能精確地反映出在這個採樣週期中資源的消耗狀況。由於有些在這個區間運行的SQL可能結束於這個時間週期以後，也可能有一些SQL在這個週期開始以前就已經運行了好久，剛好結束於這個採樣週期。這些因素都致使了採樣週期裏面的數據並不絕對是這個時間段發生的全部數據庫操做的資源使用的數據。

做者：韓鋒

來源：宜信技術學院