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

網(wǎng)站制作、建網(wǎng)站找專業(yè)網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián):定制網(wǎng)站、模板網(wǎng)站、仿站、小程序開發(fā)、軟件開發(fā)、成都App定制開發(fā)等。做網(wǎng)站價格咨詢成都創(chuàng)新互聯(lián):服務(wù)完善、十載建站、值得信賴!網(wǎng)站制作電話：18982081108

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

注：原ppt可以關(guān)注數(shù)據(jù)和云（OraNews）回復(fù)關(guān)鍵字2017oow 獲取。

以下是對該ppt的解讀

真實環(huán)境下，性能問題的根源有以下幾種：

1、數(shù)據(jù)庫沒有按照預(yù)期設(shè)計的目的被使用

2、應(yīng)用的架構(gòu)或代碼設(shè)計不佳

3、數(shù)據(jù)庫中存在一些不良的算法可能會引發(fā)問題

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

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

在他們的工作當(dāng)中，一般性能優(yōu)化會涉及到以下幾個方面的處理：

代碼的改寫，應(yīng)用的邏輯修改，保證被正常地使用，bug的修復(fù)等。通過多個維度的調(diào)整和修改，最終實現(xiàn)系統(tǒng)性能千倍的提升。

發(fā)現(xiàn)數(shù)據(jù)庫性能問題的方法很多，而不只是簡單地看wait event 和 top SQL。事實上，我們需要的很多數(shù)據(jù)都可以從AWR報告中獲取，同時，我們也需要了解系統(tǒng)架構(gòu)的設(shè)計方式、實現(xiàn)原理。在我們的經(jīng)驗中，很多性能問題都是架構(gòu)設(shè)計不合理或者應(yīng)用代碼的邏輯問題導(dǎo)致的。

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

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

猜測：可能是會話泄露或者是連接風(fēng)暴。

知識點補充

會話泄露：當(dāng)應(yīng)用程序斷開連接而數(shù)據(jù)庫中對應(yīng)的會話還處于活動狀態(tài)的時候，就會發(fā)生會話泄露。對于應(yīng)用來說，就意味著程序的丟失。一般都是由于應(yīng)用程序的異常導(dǎo)致的，在數(shù)據(jù)庫中沒有正常地執(zhí)行commit或者rollback的時候失去了與數(shù)據(jù)庫的聯(lián)系。

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

猜測：可能存在游標(biāo)泄露的問題。

再看詳細負載信息

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

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

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

接下來我們來看數(shù)據(jù)庫的一些參數(shù)的設(shè)置。

我們看到數(shù)據(jù)庫中塊的大小是非默認(rèn)塊16k。同時將cursor_sharing設(shè)置為Force。

知識點補充

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

在一般情況下不建議將參數(shù)設(shè)置為Force。這很可能會引發(fā)SQL注入的風(fēng)險，對于SQL中的函數(shù)來說，在一些直接使用文本而非綁定變量更優(yōu)的情況下，如果使用系統(tǒng)生成的綁定變量，可能會對執(zhí)行計劃產(chǎn)生負面的影響。

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

DB_file_multiblock_read_count 默認(rèn)值對應(yīng)于可以高效執(zhí)行且與平臺相關(guān)的大I / O大小 。此處與系統(tǒng)CPUs核數(shù)相等，說明IO沒有問題。

open_cursors 參數(shù)指定一個會話一次最多可以打開的游標(biāo)的數(shù)量，默認(rèn)值為50.現(xiàn)在設(shè)置為2000，這是很高的，說明系統(tǒng)存在異常。

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

DB_Writer_processes的默認(rèn)值為1或者CPU_count/8,取較大者。此時設(shè)置為12，比默認(rèn)值大，應(yīng)該是手動調(diào)整過。

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

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

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

因此，綜合上述的信息，推測系統(tǒng)可能是出現(xiàn)會話泄露和游標(biāo)泄露的問題。對于會話泄露，一般是由于應(yīng)用的異常導(dǎo)致，不能直接通過數(shù)據(jù)庫層面的分析得出結(jié)論也不能單純從數(shù)據(jù)庫的層面解決。

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

文章標(biāo)題：且聽AWR之父解讀AWR報告-創(chuàng)新互聯(lián)
當(dāng)前鏈接：http://m.rwnh.cn/article46/eppeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、云服務(wù)器、網(wǎng)站制作、App開發(fā)、網(wǎng)站維護、網(wǎng)站營銷

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)