作者介紹
韓鋒，宜信技術研發中心資料庫架構師。精通多種關系型資料庫，曾任職于當當網、tom線上等公司，曾任多家公司首席dba、資料庫架構師等職，多年一線資料庫架構、設計、開發經驗。著有《sql優化最佳實踐》一書。
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執行時間。
sql執行次數。
cpu per exec (s)
每次執行消耗cpu時間。
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執行獲得的記憶體資料塊數量。
gets per exec
每次執行獲得的記憶體資料塊數量。
%total
占總數的百分比。
消耗的cpu時間。
篩選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執行所占的磁盤實體讀)。
sql實體讀的次數。
reads per exec
sql每次執行産生的實體讀。
占整個實體讀的百分比。
sql執行消耗的cpu時間。
sql的執行時間。
5 sql ordered by executions
這部分列出了sql執行次數的資訊，按照從大到小的順序排列。如果是oltp系統的話，這部分比較有用。是以sql執行頻率非常大，sql的執行次數會對性能有比較大的影響。olap系統因為sql重複執行的頻率很低，是以意義不大。
sql的執行次數。
rows processed
sql處理的記錄數。
rows per exec
sql每次執行處理的記錄數。
每次執行消耗的cpu時間。
elap per exec (s)
每次執行的時長。
6 sql ordered by parse calls
這部分列出了sql按分析次(軟解析)數的資訊，按照從高到底的順序排列。這部分對oltp系統比較重要，這裡列出的總分析次數并沒有區分是硬分析還是軟分析。但是即使是軟分析，次數多了，也是需要關注的。這樣會消耗很多記憶體資源，引起latch的等待，降低系統的性能。軟分析過多需要檢查應用上是否有頻繁的遊标打開、關閉操作。
parse calls
sql分析的次數。
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的版本數。
9 sql ordered by cluster wait time
記錄了叢集的等待時間的top sql。這部分隻在rac環境中存在，列出了執行個體之間共享記憶體資料時發生的等待。在rac環境下，幾個執行個體之間需要有一種鎖的機制來保證資料塊版本的一緻性，這就出現了一類新的等待事件，發生在rac執行個體之間的資料通路等待。對于rac結構，還是采用業務分隔方式較好。這樣某個業務固定使用某個執行個體，它通路的記憶體塊就會固定地存在某個執行個體的記憶體中，這樣降低了執行個體之間的gc等待事件。此外，如果rac結構采用負載均衡模式，這樣每個執行個體都會被各種應用的會話連接配接，大量的資料塊需要在各個執行個體的記憶體中被拷貝和鎖定，會加劇gc等待事件。
cluster wait time (s)
叢集等待時長。
cwt % of elapsd time
叢集操作等待時長占總時長的百分比。
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在這個周期開始之前就已經運作了很久，恰好結束于這個采樣周期。這些因素都導緻了采樣周期裡面的資料并不絕對是這個時間段發生的所有資料庫操作的資源使用的資料。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-10-19</b>