3.7 如何分析 AWR Report

當 Oracle 資料庫發生系統上或是效能上的問題時，AWR Report 便是幫助你用來分析問題的好幫手。那麼拿到一份 AWR Report 時應該怎麼來解讀它 ?  AWR Report 揭露的資訊非常多，我們不需要每個項目都仔細閱讀，有些項目是需要互相配合來看，例如從 wait event 發現有 latch 相關事件時，需要再搭配 Latch Statistics 項目來做進一步分析，平時若是沒有 latch 相關事件，則 Latch Statistics 就不是需要關注的項目。大體上 AWR Report 可以從最一開始的資料庫資訊與 Report Summary 開始看起。

打開一份 AWR Report，最一開始會揭露這個資料庫的一些相關訊息:

從這個項目可以知道資料庫名稱、開啟時間、是否為 RAC、系統平台，系統資源配置(CPU、Memory)。當你拿到一份陌生的 AWR Report 時，可以經由這個項目對這個資料庫有些初步的認識。

接下來這個項目可以反映出 AWR 時段的系統負載程度:

首先這邊需注意的是，在  Begin Snap 與 End Snap 期間中，資料庫的 session  數量是否有異常增加，若是有異常增加的情形，表示此資料庫在這段時間可能遭受了連接風暴(Connection Storm)  因而影響效能。Elapsed 表示 AWR Report 產出的時間區間，DB Time 表示在這一個區間中，資料庫所有非 idle  sessions 所使用的時間，這是一個累加的數值，也就是在這一段區間把所有非 idle sessions (active session)  所消耗的時間相加起來，就是我們所看到的 DB Time，由於這是一個累加的數值，因此我們有可能看到 DB Time > Elapsed。由  Elapsed 與 DB Time，大致上可以判斷這個系統的負載程度，若是 Elapsed < DB Time，表示資料庫所有非  idle session 所使用的時間小於我們的觀察區間，系統負載低，反之則是系統負載中等或是過重，在一個非常繁忙或是效能有問題的系統上，DB  Time 有可能遠大於 Elapsed 超過 10 倍，甚至 20 倍以上。

Cache Size 可以觀察目前資料庫的記憶體配置情況:

使用 SGA_TARGET (MEMORY_TARGET) 時，我們並不知道系統配置多少給 Buffer Cache、Shared Pool，由這個項目可以知道系統配置的情形。<

Load Profile 可以觀察資料庫負載時的相關資訊:

首先觀察的是  DB Time 與 DB CPU，DB Time = CPU Time + Wait Event Time，而 DB CPU 所表示的就是  DB Time 當中的 CPU Time，一般來說，我們希望資料庫能夠充分的運用到系統資源 (CPU)，而不是花太多時間在處理內部的等待事件  (Wait Event)；從 Redo size 可以大致上知道這段時間資料庫系統的交易量，Redo size 越大表示交易量越大；從  Parses 數據可以了解資料庫 SQL Statement 的共用情形，一般來說，我們不希望資料庫有太多的 Hard  Parses，這個指標可以搭配 TOP SQL 的項目來分析是否系統中有太多的 SQL 未使用 Bind Variable；Logons  可以用來觀察資料庫的登入行為，以目前最普遍的三層式架構來說，平時資料庫不會有太多的 Logons，過多的 Logons 需注意資料庫是否遭受到了  Connection Storm。

Hit Ratio 用來觀察資料庫記憶體的命中率，一般來說 Hit Ratio 在 95% 屬良好範圍，若 Hit Ratio 偏低需要做調整時，可以搭配 Advisory 項目進行分析:

整份  AWR Report 當中最重要的部分莫過於 Wait Event 了，先前提到過，一般我們希望資料庫能夠充分運用系統資源 (CPU)  ，不希望花太多時間在處理內部的等待事件 (Wait Event)，因此由 Wait Event  這個項目可以用來分析是否資料庫存在太多的等待事件而影響效能:

從  Wait Event 表格來看，我們需關注的是哪個事件所佔的 %DB Time 較多，以上述表格來說，DB CPU 佔了 DB Time 的  81%，這是我們期望所看到的，因為表示大部分的資料庫作業都使用到了系統資源 (CPU)。其次是 log file sync，這個等待事件佔了  DB Time 的 9%，若是可以解決這個等待事件，那麼資料庫就可以提升 9% 的效能，由 Wait Class 顯示的 Commit，可知這個  log file sync 事件是在進行 DML 操作時，使用了太多的 commit 所引起，一般的解決方法，就是減少 DML 語句所使用  commit 的次數。若是某個事件佔了 %DB Time  比例不高，那麼我們可以去忽略它，因為就算我們解決了這個等待事件，效能只能提升一點點，這一點點有可能是感受不出來的。

最後我們所要關注的，就是 TOP SQL 了。TOP SQL 需搭配其他項目一起來看:

例如我們從  Time Model 發現資料庫所使用的 DB CPU 較多時，就必須從 SQL ordered by CPU Time 或是 SQL  ordered by Gets 找出 TOP SQL；從 Wait Event 發現 I/O相關事件，就必須從 SQL ordered by  User I/O Wait Time 或是 SQL ordered by Reads... 等 I/O 相關的排序來找出TOP SQL。

從  Oracle 10g 開始，AWR Report 已經完全取代 Statspack Report 作為分析問題的基礎，Statspack  Report 判讀的方法與 AWR Report 相同，在此不多作介紹。然而 Statspack 在 Oracle 10g  之後就完全用不到嗎，其實也不盡然，因為 AWR 是必須是在企業版(Enterprise Edition)  才有的功能，若是使用標準版(Standard Edition)，則 AWR Report  就沒有相關的數據可以顯示，此時如果想要藉由這些數據來分析問題，那麼就只能安裝 Statspack 了。