講講AWR

我的原創連線：

講講AWR (qq.com)

    我這幾天一直在處理一些Oracle的分析，積累了一些要說的，前幾天說了要些，一直在處理問題。這幾天白鱔老師也在寫，說明現階段來說AWR對我們來是一個最好的輔助工具。前段時間在一個PG的群中一位朋友說了一句話：“說一個oracle極難被超越的地方，就是故障處理owi的思想。雖然國產很多也在借鑑，但是沒有做 得很好的。即使現在，一個好的dba就是it後臺運維故障處理的入口，前臺只會說交易慢了，清算慢了，oracle dba可以甚至可以最終定位到儲存光纖線光衰（硬體一點不報錯情況）”，可以看得出這位朋友有著非常好的技術功底和實戰經驗。

     我個人沒處理過這種問題（光纖衰減），但是我處理的問題也不少。定位儲存IO和網路還是做過的。不過更多的是看SQL執行的效率和執行頻次。透過改善這些降低系統負荷。我們不知道應用程式開發是怎麼寫的邏輯，也不知道開發 用的是什麼語言（java、Python等等），我們也不知道是直連資料庫還是呼叫介面。不過這一切都不重要，因為最後運算元據庫的只能是SQL，就是select、update、delete、insert。那麼AWR會將這些消耗全部統計，從而讓我們得到了最真實的資料。

     比如我可以看到平均每秒執行過的

Redo size可以判斷寫的情況如何？多還是少？

Logical read可以判斷讀記憶體多還是少，系統負荷主要來源之一。

physical read可以判斷讀磁碟多還是少，系統負荷主要來源之一也是SQL寫的好不好的一個稽核角度。

IM scan rows 看看記憶體發揮了多少

Executes (SQL):每秒執行多少SQL

Transactions：每秒多少個事務

下面是從其他地方找過來樣例

由於AWR博大精深，每個指標都搞清楚的人可能沒幾個。其他很多指標估計寫一本書都不夠，非常複雜。如果寫出來了，而且都講明白了。我估計這本書要個幾千頁。不過就這些大項指標看起來就能知道大致方向。就像看病一樣的望聞問切，看出是什麼大致的病。比如說鎖了，我就看Segments by Row Lock Waits；還有是全表還是索引建立反了，在AWR中一目瞭然，稍微懂Oracle的人都可以快速定位。有的時候我甚至都能推斷出主要邏輯或者開發的風格特點。不得不說真的很好。而這個東西已經有了快20年了。

     所有這些是靠資料庫中的探針獲得的，有多少我不知道，和版本不同也有不同。我聽過一個版本說有大約2萬個探針。現在估計不止了。我有一點很佩服就是有這麼多探針居然還不影響效能。要知道有的時候我按照個監控軟體，結果監控軟體佔用較高的資源把被監控的資料庫或者中介軟體高的沒法用了。這種笑話也是見過的。

       我們可以利用這個進行分析什麼語句執行的最慢，什麼執行的最快。對執行態的資料庫瞭如指掌。多次問題都是靠這些資料進行分析而定位的。MySQL什麼時候有個這個就好了。官方自帶那種。

      其實每個資料庫都應該帶一個自己的負載報告，這樣使用者才能知道現在資料庫遇到什麼問題了。