現在很多DBA都閱讀和分析STATSPACK/AWR報告，不過這份報告可不容易讀。一般的DBA頂多能夠看看前面的TOP EVENTS，命中率以及後面的一些ADVISORY，而實際上系統的更多的秘密存在於那些看起來十分生澀的InstanceActivity Stats中。但是對於這些STATS，大多數DBA都感到很無奈，沒有任何官方的資料披露這些STATS的含義，有些DBA經過長年的積累，可以從字面意思上對某些指標進行一些解讀。這些年裡，老白閱讀了數千份的STATSPACK/AWR報告，經過長期的積累，老白總結了一些閱讀STATS的經驗，在本節，將拿出來和大家分享。

經常有DBA問老白某某指標多大是不正常的，實際上由於每個系統的硬體配置、應用、週期性節奏等方面都存在不同，因此絕大多數資料庫的指標都沒有一個“正常值”。當然對於那些接觸過大量系統的老DBA，他們可以根據經驗，一打眼就看出某些指標不太正常，但是對於絕大多數DBA來說，看到這些指標就像看天書一樣，哪怕知道這些指標的含義，也無法使用這些指標來分析資料庫的問題。在這裡老白可以向大家透漏一個十分有用的方法。

這個方法實際上也很簡單，就是老白常說的基線對比的方法。對於一個系統，如果你為何的時間越長，越瞭解系統的脾氣，那麼這個系統出現問題的時候你處理起來越得心應手。而一個新系統，很多DBA可能覺得好像無從入手，很難摸到頭腦。這是什麼原因呢？實際上，一個你接觸多的系統，在你的心理已經對這個系統建立了很多基線指標，這樣的話如果系統出了問題，你就很容易透過和平時的比較找到問題。實際上你已經在實際工作中使用了老白所說的基線對比方法。基線對比方法的基礎是對某個系統透過一段時間的資訊採集，將其重要的系統指標建立基線，然後將出問題的時候的系統狀態資料和基線的資料進行比較，從而發現問題。DBA分析AWR報告的時候，最好的辦法是對比平時這個系統這些指標的平均值、合理的高值和低值這些指標，而不是孤立的從某一份報告中去查詢問題。

另外一個要注意的問題是，AWR報告中的指標之間是相互關聯的，在分析這些指標的時候，需要綜合分析，將這些指標和其他的資料對比分析，才能夠得到較為準確的分析結果，比如說你從某些指標上看出可能DB CACHE存在問題，那麼你就需要比對報告頭中的DB CACHE命中率情況，以及事件明細中的db file sequential read、db file scattered read等指標中的平均等待時間，如果DB CACHE的命中率較高，但是db file sequential read的平均等待時間較大，那麼也不能說DB CACHE就一定沒有問題，我們可以繼續透過後面的Buffer Pool Statistics等資訊來分析BUFFER CACHE是不是配置不合理，以及如何最佳化。

附表是AWR/STATSPACK報告中的主要指標的描述，該表可以作為DBA的一個參考資料來使用，沒必要每個指標都去認真研讀，也不必要把這張表的內容背誦下來。這張表中的內容大部分是老白這些年研讀STATSPACK報告體會出來的，並不是來自於官方的說法，因此可能部分描述也不很準確，如果大家對老白對這些指標的解釋有什麼疑問，歡迎到上去和老白探討。

名稱	註釋
CPU used by this session	統計CALL發起開始到結束的CPU時間片的數量，每個計數代表一個CPU週期，也就是10毫秒。不過如果有一個CALL不足一個CPU週期就執行完了，那麼統計值的時候START TIME和END TIME是相同的，這樣會計算為0.這個計數基本上可以代表了ORACLE資料庫消耗的CPU資源，不過計算的時候要注意單位是釐秒(cs)，乘以10可以換算成毫秒。比如平均每秒這個指標值是782.1，表示ORACLE消耗了7821毫秒CPU時間，如果這個系統是一個16個CPU的系統，那麼這個指標可以說明ORACLE消耗了超過50%的CPU資源。不過由於部分小的CALL可能由於消耗的時間小於10毫秒而沒有計算進去，實際的使用率可能略高於透過這個值計算出來的。一般來說大多數CALL消耗的CPU都會大於10毫秒，所以這個值還是能夠基本反映出ORACLE對CPU資源的開銷
CR blocks created	CURRENT塊被克隆後用於建立CR（consistent read）塊。被克隆的主要原因是BUFFER被非相容的模式佔用,如果單位時間內CR BLOCKS CREATED值比較高，說明資料庫中對某些資料塊的修改和訪問比較頻繁。如果這些訪問集中在某些熱塊上，那麼可能會形成較為嚴重的BUFFER BUSY WAITS，在RAC環境中，可能還會導致全域性熱塊衝突，如果這個指標比較高，那麼應該關注BUFFER BUSY WAITS以及CACHE BUFFER CHAINS閂鎖等
current blocks converted for CR	一個CURRENT的BUFFER在被使用前生成了CR
DBWR buffers scanned	當某些觸發條件發生時，DBWR會在LRU鏈的冷端開始掃描髒塊，組成DBWR BATCH，這個指標統計的是DBWR在LRU上掃描的BUFFER的總數，包含髒塊和乾淨的塊，這個指標除以DBWR LRU SCANS這個指標就是每次掃描查詢的資料塊的數量。
DBWR checkpoint buffers written	CHECKPOINTS時dbwr寫入的的髒塊數量，如果在單位時間裡這個指標比較高，說明系統中資料塊的變更較為頻繁
DBWR free buffers found	DBWR從LRU鏈中掃描BUFFER的時候發現的FREE的BUFFER的數量，除以DBWR MAKE FREE REQUESTS就是平均每次DBWR在收到DBWR MAKE FREE訊息的時候掃描LRU鏈找到的FREE BUFFER的平均數，這個平均數一般會比較少
DBWR make free requests	DBWR收到的MAKE FREE 訊息的數量，如果某個前臺程式在查詢一個空閒的BUFFER的時候無法找到的時候或者其他一些觸發條件，會向DBWR發出MAKE FREE訊息。如果在單位時間內這個值較高，說明DB CACHE可能存在不足的現象
DBWR summed scan depth	DBWR掃描LRU鏈查詢髒塊的時候，查詢的BUFFER的數量，這個數越大說明LRU鏈尾部的贓塊數量越少。從Oracle 8i開始，由於LRU鏈的演算法發生了變化，因此如果LRU鏈尾部的熱塊比較多，也可能造成這個指標較大
DBWR timeout	DBWR IDLE超過一個特定值，該指標就會加1。如果該值較高，說明BUFFER CACHE中的資料變化較小，需要寫入磁碟的髒塊數量極少
DBWR transaction table writes	DBWR寫入的回滾段頭的數量，這個指標比較高說明有較多熱塊正在被寫入，而大量使用者程式在等待這些塊寫入完成
DBWR undo block writes	DBWR寫入回滾段的資料塊數量
DDL statements parallelized	DDL操作併發執行的計數
DML statements parallelized	DML操作併發執行的計數
background checkpoints completed	後臺程式完成的CHECKPOINTS的數量。
background checkpoints started	後臺程式啟動的CHECKPOINTS數量，可能比上一個狀態的值大一些。如果一個新的CHECKPOINT覆蓋了一個未完成的CHECKPOINT或者CHECKPOINT還正在執行。這個狀態只包含REDO的CHECKPOINT，不包括其他型別的CHECKPOINT，比如OFFLINE檔案或者BEGIN BACKUP或者ALTER SYSTEM CHECKPOINT LOCAL命令等
branch node splits	由於插入資料導致的索引枝節點分裂的數量，這個指標較高說明目前存在索引產生了較多的枝節點分裂，可能某張表上的某個索引欄位變化十分頻繁，這種頻繁的變化可能對某個應用的效能有較大的影響
BUFFER DEADLOCK	DB CACHE死鎖的數量計數，如果單位時間內該指標較高，可能DB CACHE存在效能問題，或者存在某些BUG
buffer is not pinned count	當訪問一個BUFFER的時候，這個BUFFER已經釋放的數量，只用於Oracle內部除錯，並不說明效能問題
buffer is pinned count	當訪問一個BUFFER的時候，該BUFFER已經被PIN住了，如果單位時間內這個指標比較高，說明可能存在熱塊
change write time	當前塊的變化被寫入REDO的時間，單位釐秒（cs,10毫秒），該指標一般不會太大，如果太大需要分析
commit cleanout failures: block lost	在commit的時候準備做塊清理操作的時候，發現不能找到正確的塊的次數計數。
commit cleanout failures: buffer being written	Oracle在COMMIT的時候，去清除BUFFER的時候，發現這個BUFFER 正在被其他會話寫入的計數，如果改指標比較高，可能說明存在熱塊
commit cleanout failures: callback failure	Oracle在COMMIT的時候，做清除操作時呼叫CALLBACK函式返回FALSE的計數
commit cleanout failures: cannot pin	Oracle在COMMIT的時候，做清除操作時無法PIN到這個BUFFER的計數,有可能在準備清理的時候該BUFFER又被其他會話PIN住了，如果該指標較高，可以檢視DB CACHE相關的情況，包括DB CACHE的大小，命中率，相關閂鎖的命中率，以及熱塊爭用的情況
commit cleanout failures: hot backup in progress	Oracle在COMMIT的時候，做清除操作時發現正在做熱備份的技術。此時在修改這個BUFFER前，這個BUFFER在被修改前，必須先被寫入LOG BUFFER，以確保資料庫恢復的時候不會產生塊斷裂
commit cleanout failures: write disabled	Oracle在COMMIT的時候，做清除操作時發現資料庫的寫操作暫時被關閉了。這種情況出現的很少
commit cleanouts	在做COMMIT的時候做塊清除工作的計數，無論成功與否計數器都會加1
commit cleanouts successfully completed	COMMIT時成功完成CLEANOUTS的計數。這個指標和上一個指標參考來看，兩個指標應該較為接近（這個指標略低一些），如果這兩個指標相差太大，需要分析DB CACHE是否存在過小的問題，或者應用中是否經常對大表進行大資料量的修改操作
consistent changes	資料塊提交了UNDO資訊成為CR塊的計數，這個指標說明了系統中CR塊產生的數量，這個指標越大，越要注意CACHE BUFFER CHAINS等閂鎖的情況，以及熱塊對系統效能的影響
consistent gets	一致性讀的計數，會話發出的對某個資料塊進行一致性讀的請求。這個指標不能和consistent changes混淆，一個CR塊產生後，可能被多次consistent gets使用，因此這個指標要比前一個指標大的多。
data blocks consistent reads - undo records applied	從UNDO中讀取資料，形成CR READ。本計數器是記錄從UNDO中獲取UNDO記錄的計數，如果這個指標的值較大，說明對於某些修改較為頻繁的表的查詢和其他操作也很頻繁，有可能存在熱點表和索引
deferred (CURRENT) block cleanout applications	做延遲塊清除操作的計數。在提交的時候該資料塊由於某些原因，某些資料塊無法馬上做塊清除工作，這種情況下，這個資料塊就會做延遲塊清除，延遲塊清除操作可能在下次該資料塊被查詢的時候進行，這種情況也導致了有時候我們會看到我們做SELECT操作的時候也會產生大量的REDO
dirty buffers inspected	當某個會話在LRU鏈的冷端開始查詢空閒的資料塊，查到一個髒塊，這個指標就會被增加，如果在單位時間內該指標較大，說明LRU鏈的冷端存在較多的髒塊。這種情況的出現有幾種可能： l 系統中的贓塊數量十分巨大，而且DBWR的寫入速度不足，從而導致DBWR無法儘快將這些髒塊寫入硬碟 l 部分BUFFER 特別熱，並且被更改的頻率特別高，從而造成LRU鏈的尾端存在大量這樣的塊 l 本系統是一個以DML為主的系統，資料塊的變更十分頻繁碰到這種情況，可以關注一下dbwr的效能，並且關注一下DB CACHE的命中率及cache buffer chains等閂鎖的情況
enqueue waits	等待各種鎖的計數
exchange deadlocks	當進行兩個BUFFER交換的時候，發生內部死鎖的計數。索引掃描是導致這種交換的唯一因素，如果改指標較高，可以檢查是否存在十分熱的索引（可以透過BUFFER BUSY WAITS分析來定位）
free buffer inspected	從LRU佇列的尾部掃描可重用的BUFFER的時候跳過的BUFFER的數量。
global cache freelist waits	當ping一個buffer的時候由於所有的lock element都被使用而引起的等待。
global lock convert time	同步全域性鎖的轉換時間（單位是10ms），這個指標較高說明全域性鎖衝突較為嚴重，需要檢查cluster interconnect的效能
hot buffers moved to head of LRU	當一個熱塊到達LRU佇列的尾部的時候，ORACLE自動會把這個塊移動到LRU佇列的頭上，以便於使之能夠繼續被使用。每發生一次這樣的操作，這個計數就加一，值得注意的是，從8i開始，LRU的演算法發生了變化，透過引入TCH計數來確定熱塊，而不是透過將熱塊在LRU鏈上移動來保證熱塊不被過早的換出。如果熱塊存在於LRU鏈的尾部，掃描的時候發現了熱塊，會主動跳過，從而保證熱塊不被過早的重用
immediate (CURRENT) block cleanout applications	獲取BUFFER（GET BUFFER）後，立即進行記錄清除操作的計數。
leaf node splits	當INSERT發生後，導致索引葉節點分裂的次數，一般來說對於插入較為頻繁的系統，這個指標一般會比較高，除非出現葉節點熱塊較為嚴重的現象，一般來所不需要特別關注該指標
logons current	當前登入資料庫的計數
opened cursors current	當前的Open CURSORS的數量
opens of replaced files	檔案由於不在開啟檔案緩衝中而重新開啟的計數。每個Oracle會話都有一個檔案開啟緩衝區，保持部分開啟的資料檔案的控制程式碼，以避免重複開啟檔案
parse count (hard)	硬分析的統計值，該值需要和parse count (total)對比來看硬分析的比例。
parse count (soft)	軟分析的統計值
parse count (total)	發生的parse call的總數
parse time cpu	PARSE消耗的CPU的統計，單位是10毫秒
parse time elapsed	PASE的持續時間，單位是10毫秒。這個指標減去parse time cpu就是parse中等待的時間。如果parse time cpu佔整個parse time elapsed的比例較低，說明parse中的等待時間過長，可能共享池存在效能問題，需要進行分析
physical reads direct	直接物理讀的數量。讀的時候不經過BUFFER。一般發生這種操作的情況有：排序操作、並行查詢操作的SLAVE或者預讀
physical writes direct	直接寫的數量，不經過BUFFER，直接寫入。一般發生這種操作的情況有： l 直接裝載操作，比如CREATE TABLE AS SELECT l 並行DML操作 l 排序操作中的臨時表空間寫入 l 寫入沒有緩衝的LOB欄位
physical writes non checkpoint	非CHECKPOINT引起的物理寫。物理寫的發生情況包括CHECKPOINT或者無足夠的空閒BUFFER可用，或者DBWR超時等，一般情況下這個指標會超過physical writes的一半以上，除非是CHECKPOINT十分頻繁的系統。如果該指標占physical writes的比重比較少，應該進行分析
pinned buffers inspected	當一個使用者程式掃描REPLACEMENT列表，尋找一個可重用的BUFFER的時候，發現一個冷塊被PIN了或者有一個PIN請求的等待事件。這種情況很少發生，因為冷塊很少會被PIN。如果平均每秒該指標值較大，需要進行分析
queries parallelized	並行查詢執行的次數統計
recursive cpu usage	非使用者呼叫的CUP時間
recovery array read time	做recovery的時候產生的IO消耗的時間
recovery array reads	做RECOVERY的時候產生的IO的次數
recovery blocks read	做recovery的時候讀取的資料塊的數量
redo entries	當一個redo資訊被複製到log buffer的時候這個計數增加
redo entries linearized	小於等於REDO_ENTRY_PREBUILD_THRESHOLD的redo entries的數量，這些redo entries可以併發生成，不需要受閂鎖的限制，但是會增加CPU的消耗，在多CPU的系統中，這個值會比較高
redo buffer allocation retries	當申請REDO BUFFER的時候，重試的次數。一般來說重試發生的原因是REDO WRITER還沒完成或者日誌切換正在進行。如果該指標較高，說明REDO LOG產生的頻率很高，LGWR無法及時重新整理LOG BUFFER，可以考慮加大LOG BUFFER的大小。LOG BUFFER一般可以為幾兆到幾十兆，不過由於很多資料庫版本中存在BUG，因此不建議將LOG BUFFER設定的過大，一般來說30-40M對於絕大多數系統來說都是足夠的了如果是由於等待日誌切換，那麼可能是存在的問題包括： l REDO LOG檔案過小 l REDO LOG IO效能不佳 l 資料檔案的IO效能不佳導致DBWR寫入較慢 l DBWR的數量太少，導致DBWR的寫入效能不足
redo log space requests	當前ACTIVE的日誌檔案滿了，Oracle必須等待日誌切換完成後才能分配REDO LOG磁碟空間，就會產生這個等待。如果SGA的大小和日誌檔案的大小不匹配，並且系統中的COMMIT十分頻繁。當日志切換的時，DBWR需要把已經提交的髒塊也寫入磁碟，在這些髒塊寫入磁碟完成前，日誌切換不能完成。在這種情況下，這個統計值會比較高。如果這個統計值較高，建議檢查以下幾個方面： l REDO LOG檔案的IO效能是否存在問題，如果log file parallel write的平均耗時較大，說明REDO LOG的寫效能出現了問題，建議將REDO LOG放到效能更好的磁碟上，或者將REDO LOG檔案獨立存放，避免IO衝突 l LOG BUFFER的大小是否過小 l 應用軟體中的提交可能過於頻繁，建議採用批次提交的方式，而不要每條記錄都提交
redo log space wait time	Redo log space requests的等待時間（單位釐秒），這個指標需要和上一個指標一起看
redo size	生成的所有redo的大小，單位是位元組
redo synch time	Redo synch呼叫消耗的時間，單位是10毫秒（釐秒）
redo sync writes	一般來說redo資訊生成後，會被複製到log buffer中，並不需要馬上被寫入redo log檔案，lgwr會週期性將這些資料寫入redo log檔案。不過如果事務提交了，那麼這些redo 資訊必須馬上被寫入REDO LOG檔案，這個時侯redo sync writes計數器會增加
redo wastage	在把LOG BUFFER資料寫入REDO LOG檔案的時候計算的LOG BUFFER空閒的空間
redo writer latching time	LGWR獲得每個COPY LATCH的時間（單位釐秒），如果該指標存在問題，需要檢查REDO LOG檔案的IO效能以及LOG BUFFER的大小是否足夠，這個指標只有在LOG_SIMULTANEOUS_COPIES > 0的時候才有意義
redo writes	LGWR將LOG BUFFER寫入REDO LOG檔案的計數
remote instance undo block writes	如果遠端的例項需要讀取某個UNDO BLOCK，需要這個例項先將這個“髒的”UNDO BLOCK回寫，這個計數器就會增加
remote instance undo header writes	和上一個指標類似，只是寫入的是UNDO HEADER
remote instance undo requests	由於要做CR從遠端的例項中請求UNDO的數量，如果這個指標較大，說明RAC中的某些資料塊經常在例項間進行共享，某個例項修改過的資料也正在被其他例項使用，這種情況下需要留意CLUSTER INTERCONNECT的效能
rollback changes - undo records applied	當使用者需要ROLLBACK的時候，提交的UNDO記錄的數量，當事務需要回滾時，需要從UNDO中取出資料，並且提交到已被修改過的資料上，這個計數和系統中ROLLBACK的數量以及每次ROLLBACK的記錄的數量有關
rollbacks only - consistent read gets	當使用者需要進行CR READ的時候，提交的UNDO記錄的數量，此時並沒有BUFFER CLEAR操作發生。當進行一致性讀的時候，也需要從UNDO中取出相關的資料，然後生成一個CR BLOCK，把這些資料提交到CR BLOCK上，這個時候這個指標就會增加。
rows fetched via callback	CALLBACK函式返回的記錄數。該統計量僅僅用於內部DEBUG
session cursor cache count	會話CURSOR緩衝區的計數，只有當session_cached_cursors大於0的時候才有意義，如果這個值已經很接近甚至到達了引數中session_cached_cursors的值，那麼說明這個引數可能需要加大
session cursor cache hits	這個指標也只有當session_cached_cursors大於0才有意義，會話直接從SESSION CURSOR CACHE中找到某個SQL的計數，這個值可以看出CURSOR CACHE產生的作用，可以將這個值和parse count(total)進行比較
sorts (disk)	磁碟排序的數量，如果平均每秒該指標的值較高，需要檢查一下PGA_AGGREGATE_TARGET引數是否設定過低，或者*_AREA_SIZE是否設定過小（PGA手工管理模式）。檢查該指標的時候，同時應該檢視一下TEMP表空間的相關檔案的IO效能，如果TEMP表空間檔案的IO效能不足，需要加大PGA的配置來減少硬碟排序
sorts (memory)	記憶體排序的統計
summed dirty queue length	每次寫請求發生的時候，髒資料塊連結串列的長度總和除以寫請求的次數，這個統計值越大，說明系統中需要回寫的髒塊較多
switch current to new buffer	將當前BUFFER移動到另外一個新的BUFFER，原有的BUFFER成為一個CR BLOCK，這種操作的次數
table fetch by rowid	透過ROWID訪問表，這種操作一般是透過索引訪問，還有一種情況是SQL直接透過rowid去訪問某個表。
table fetch continued row	如果訪問某一行資料，需要訪問多個BLOCK，這個計數器就會增加。產生這種情況的一個很主要的原因是行鏈和行遷移，如果某個表的PCT_FREE設定不合理，可能導致UPDATE的時候產生行遷移，這樣就會增加這個計數第二種可能性是某一行計數的長度相對BLOCK SIZE來說過大，這樣一行資料被儲存在多個BLOCK中的機會就較大，這種情況下應該將這種表存放於更大的BLOCK SIZE的表空間中還有一種可能性就是系統中訪問帶LOB欄位的訪問較多，因為大的LOB欄位一般來說採用獨立的SEGMENT存放，因此訪問這種資料也會增加這個統計值
total file opens	被INSTANCE開啟的檔案的數量（包含資料檔案、控制檔案、REDO LOG等）
transaction rollbacks	被成功回退的事務的總數
write clones created in background	如果當前的BUFFER正在被寫入，那麼後臺程式或者前臺程式克隆一個新的BUFFER，使原來BUFFER的寫入可以繼續進行
enqueue conversions	表或者行鎖的轉換統計
enqueue deadlocks	死鎖統計
enqueue releases	鎖釋放統計
enqueue requests	鎖申請統計
enqueue timeouts	鎖申請超時統計
enqueue waits	鎖等待統計

AWR中的主要事件分析精講

相關文章