如何使用AWR報告來診斷資料庫效能問題

如何使用AWR報告來診斷資料庫效能問題

如何主動避免問題發生及做好診斷資訊的收集

有些問題是無法預見的，但大部分其它的問題如果及早發現一些徵兆其實是可以避免的。同時，如果問題確實發生了，那麼收集問題發生時的資訊就非常重要。有關於如何主動避免問題及診斷資訊的收集.
對於資料庫整體的效能問題，AWR的報告是一個非常有用的診斷工具。
 一般來說，當檢測到效能問題時，我們會收集覆蓋了發生問題的時間段的AWR報告-但是最好只收集覆蓋1個小時時間段的AWR報告-如果時間過長，那麼AWR報告就不能很好的反映出問題所在。還應該收集一份沒有效能問題的時間段的AWR報告，作為一個參照物來對比有問題的時間段的AWR報告。這兩個AWR報告的時間段應該是一致的，比如都是半個小時的，或者都是一個小時的。 

Oracle AWR報告產生與查看

在CentOS 6.4下安裝Oracle 11gR2(x64)

Oracle 11gR2 在VMWare虛擬機器中安裝步驟

Debian 下 安裝 Oracle 11g XE R2

Oracle AWR報告產生步驟

 
Interpretation

在處理效能問題時，我們最關注的是資料庫正在等待什麼。
 當進程因為某些原因不能進行操作時，它需要等待。花費時間最多的等待事件是我們最需要關注的，因為降低它，我們能夠獲得最大的好處。
AWR報告中的"Top 5 Timed Events"部分就提供了這樣的資訊，可以讓我們只關注主要的問題。
• 
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR報告中最重要的部分。它指出了資料庫的sessions花費時間最多的等待事件，如下：

Top 5 Timed Events                                        Avg %Total

~~~~~~~~~~~~~~~~~~                                        wait  Call

Event                                Waits    Time (s)  (ms)  Time Wait Class

------------------------------ ------------ ----------- ------ ------ ----------

db file scattered read          10,152,564      81,327      8  29.6  User I/O

db file sequential read          10,327,231      75,878      7  27.6  User I/O

CPU time                                        56,207          20.5

read by other session            4,397,330      33,455      8  12.2  User I/O

PX Deq Credit: send blkd            31,398      26,576    846    9.7      Other

        -------------------------------------------------------------

Top 5 Events部分包含了一些跟Events（事件）相關的資訊。它記錄了這期間遇到的等待的總次數，等待所花費的總時間，每次等待的平均時間；這一部分是按照每個Event佔總體call time的百分比來進行排序的。

 根 據Top 5 Events部分的資訊的不同，接下來我們需要檢查AWR報告的其他部分，來驗證發現的問題或者做定量分析。等待事件需要根據報告期的期間和當時資料 庫中的並發使用者數進行評估。如：10分鐘內1000萬次的等待事件比10個小時內的1000萬等待更有問題；10個使用者引起的1000萬次的等待事件比 10,000個使用者引起的相同的等待要更有問題。

 就像上面的例子，將近60%的時間是在等待IO相關的事件。

• 事件"db file scattered read"一般表明正在做由全表掃描或者index fast full scan引起的多塊讀。
• 事件"db file sequential read"一般是由不能做多塊讀的操作引起的單塊讀（如讀索引）

 其他20%的時間是花在使用或等待CPU time上。過高的CPU使用經常是效能不佳的SQL引起的（或者這些SQL有可能用更少的資源完成同樣的操作）；對於這樣的SQL，過多的IO操作也是一個癥狀。關於CPU使用方面，我們會在之後討論。

 在以上基礎上，我們將調查是否這個等待事件是有問題的。若有問題，解決它；若是正常的，檢查下個等待事件。

 過多的IO相關的等待一般會有兩個主要的原因：

• 資料庫做了太多的讀操作
• 每次的IO讀操作都很慢
Top 5 Events部分的顯示的資訊會協助我們檢查：

• 是否資料庫做了大量的讀操作：
 上面的圖顯示了在這段時間裡兩類讀操作都分別大於1000萬，這些操作是否過多取決於報告的時間是1小時或1分鐘。我們可以檢查AWR報告的elapsed time如果這些讀操作確實是太多了，接下來我們需要檢查AWR報告中 SQL Statistics 部分的資訊，因為讀操作都是由SQL語句發起的。
• 是否是每次的IO讀操作都很慢：
 上面的圖顯示了在這段時間裡兩類讀操作平均的等待時間是小於8ms的
 至於8ms是快還是慢取決於底層的硬體裝置；一般來講小於20ms的都可以認為是可以接受的。

 我們還可以在AWR報告"Tablespace IO Stats"部分得到更詳細的資訊

Tablespace IO Stats                      DB/Inst: VMWREP/VMWREP  Snaps: 1-15

-> ordered by IOs (Reads + Writes) desc

 

Tablespace

------------------------------

                Av      Av    Av                      Av    Buffer Av Buf

        Reads Reads/s Rd(ms) Blks/Rd      Writes Writes/s      Waits Wt(ms)

-------------- ------- ------ ------- ------------ -------- ---------- ------

TS_TX_DATA

  14,246,367    283    7.6    4.6  145,263,880    2,883  3,844,161    8.3

USER

      204,834      4  10.7    1.0  17,849,021      354    15,249    9.8

UNDOTS1

      19,725      0    3.0    1.0  10,064,086      200      1,964    4.9

AE_TS

    4,287,567      85    5.4    6.7          932        0    465,793    3.7

TEMP

    2,022,883      40    0.0    5.8      878,049      17          0    0.0

UNDOTS3

    1,310,493      26    4.6    1.0      941,675      19        43    0.0

TS_TX_IDX

    1,884,478      37    7.3    1.0      23,695        0    73,703    8.3

>SYSAUX

      346,094      7    5.6    3.9      112,744        2          0    0.0

SYSTEM

    101,771      2    7.9    3.5      25,098        0        653    2.7

如，我們關心Av Rd(ms)的指標。如果它高於20ms並且同時有很多讀操作的，我們可能要開始從OS的角度調查是否有潛在的IO問題。

更多詳情見請繼續閱讀下一頁的精彩內容：

1 2 3 下一頁