且聽AWR之父解讀AWR報告

AWR報告是數據庫性能評估和優化的重要參考，將數據庫的問題已量化的形式展現出來，給DBA帶來了很多便利。然而AWR中的內容是非常多的，如何才能以最佳的方式解讀AWR報告，最高效地找出數據庫的性能問題所在呢？

在剛剛過去的OOW2017大會上，AWR之父Graham 做了一個主題分享，名為“AWR Analysis for Admins, Developers and Architects” 運維、開發及架構師都應該一讀的AWR報告分析。演講ppt已在oow官網公開，接下來我們簡單解讀一下分享的主要內容。希望對大家有所幫助和借鑒。

注：原ppt可以關注數據和云（OraNews）回復關鍵字2017oow 獲取。

以下是對該ppt的解讀

真實環境下，性能問題的根源有以下幾種：

1、數據庫沒有按照預期設計的目的被使用

2、應用的架構或代碼設計不佳

3、數據庫中存在一些不良的算法可能會引發問題

對于大部分人來說，都會講優化的目標集中在一些小細節上，比如某一條SQL的性能比較差，shared pool的某一組件設置不合理等等。對于這些細節的調整，一般會帶來小幅度的性能提升，而大部分人則滿足于此。

RWP團隊一直追求千倍以上極致的性能提升，對于他們來說，每一個性能問題，都應該找到根源，從最有效的角度解決問題，而不是滿足于小幅度的性能提升。

在他們的工作當中，一般性能優化會涉及到以下幾個方面的處理：

代碼的改寫，應用的邏輯修改，保證被正常地使用，bug的修復等。通過多個維度的調整和修改，最終實現系統性能千倍的提升。

發現數據庫性能問題的方法很多，而不只是簡單地看wait event 和 top SQL。事實上，我們需要的很多數據都可以從AWR報告中獲取，同時，我們也需要了解系統架構的設計方式、實現原理。在我們的經驗中，很多性能問題都是架構設計不合理或者應用代碼的邏輯問題導致的。

接下來我們分享如何通過AWR的解讀來定位問題，在AWR報告中應該關注哪些重要的信息，有效地利用報告中的數據，從而發揮AWR的真正價值。

首先看AWR報告的頭部。要關注的部分如圖中黃色標記所示。首先我們看到系統中有4個socket，總共32核，CPUs顯示為64，應該是開了超線程。session值很高，在采樣時間內還不斷增長。

猜測：可能是會話泄露或者是連接風暴。

知識點補充

會話泄露：當應用程序斷開連接而數據庫中對應的會話還處于活動狀態的時候，就會發生會話泄露。對于應用來說，就意味著程序的丟失。一般都是由于應用程序的異常導致的，在數據庫中沒有正常地執行commit或者rollback的時候失去了與數據庫的聯系。

在session本身很高的時候，每個session中的cursor值也從8增加到了26。這說明會話中游標耗盡，

猜測：可能存在游標泄露的問題。

再看詳細負載信息

DBtime達到260，就意味著同一時間的活動會話數量達到260，DB CPUs大于系統CPU核數（32）。

Logons 為10.5，每秒有10+的會話登錄，這個值是非常高的，在正常情況下，一般系統可能在1左右。這說明系統存在異常，再次推測可能是會話泄露或連接風暴等原因，與前面的信息相符。

60%的用戶事務在做回滾。（圖中寫40%應該是誤寫，40%的事務是做提交）這也是不正常的。

接下來我們來看數據庫的一些參數的設置。

我們看到數據庫中塊的大小是非默認塊16k。同時將cursor_sharing設置為Force。

知識點補充

cursor_sharing 參數有 exact和Force兩個選項，force 選項指的是優化器會將所有的文本值用系統生成的綁定變量替換，如果在使用綁定變量之后SQL語句一樣的話，優化器就會使用同樣的執行計劃。

在一般情況下不建議將參數設置為Force。這很可能會引發SQL注入的風險，對于SQL中的函數來說，在一些直接使用文本而非綁定變量更優的情況下，如果使用系統生成的綁定變量，可能會對執行計劃產生負面的影響。

因此系統一般建議設置為EXACT，只有在特殊情況下才設置為Force。詳情請參考官網（http://docs.oracle.com/database/122/TGSQL/improving-rwp-cursor-sharing.htm#TGSQL-GUID-6C3AFFA0-21DD-41BC-8DEE-5FC9A58B0954）

DB_file_multiblock_read_count 默認值對應于可以高效執行且與平臺相關的最大I / O大小 。此處與系統CPUs核數相等，說明IO沒有問題。

open_cursors 參數指定一個會話一次最多可以打開的游標的數量，默認值為50.現在設置為2000，這是很高的，說明系統存在異常。

而從db_recovery_file_dest參數的設置是哪個，我們看到存儲類型為ASM，ASM是支持異步IO的，在支持異步IO 的情況下，open_cursor達到2000也是不正常的。

DB_Writer_processes的默認值為1或者CPU_count/8,取較大者。此時設置為12，比默認值大，應該是手動調整過。

前面的信息判斷，系統應該是2個節點的RAC，processes推薦值為 50*2+50=150. 此時達到5500，而sessions默認值為processes*1.5+22=8272，圖中的值應該也是手動調整過。 而調整的原因，推測是8272也不夠用。這是很不正常的。

接下來是等待事件的分析。看到系統大部分處于等待。

以下是對于具體的top SQL的分析描述。

因此，綜合上述的信息，推測系統可能是出現會話泄露和游標泄露的問題。對于會話泄露，一般是由于應用的異常導致，不能直接通過數據庫層面的分析得出結論也不能單純從數據庫的層面解決。

以上，針對一份具體的AWR報告，我們看到哪些問題是最需要我們關注的，是能夠幫助我們最有效地分析出系統的問題所在的。希望對大家有借鑒意義