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

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

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

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

以下是對(duì)該ppt的解讀

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

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

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

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

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

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

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

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

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

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

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

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

知識(shí)點(diǎn)補(bǔ)充

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

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

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

再看詳細(xì)負(fù)載信息

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

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

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

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

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

知識(shí)點(diǎn)補(bǔ)充

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

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

因此系統(tǒng)一般建議設(shè)置為EXACT，只有在特殊情況下才設(shè)置為Force。詳情請(qǐng)參考官網(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)值對(duì)應(yīng)于可以高效執(zhí)行且與平臺(tái)相關(guān)的大I / O大小 。此處與系統(tǒng)CPUs核數(shù)相等，說(shuō)明IO沒(méi)有問(wèn)題。

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

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

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

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

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

以下是對(duì)于具體的top SQL的分析描述。

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

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

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

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

廣告

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