AWR報(bào)告目前已經(jīng)成為Oracle DBA分析問題，定位故障最為重要的報(bào)告，閱讀與分析AWR報(bào)告的技能也是Oracle DBA必備的技能。國產(chǎn)數(shù)據(jù)庫為了提高運(yùn)維便捷性，都在做類似Oracle AWR報(bào)告的模仿，只不過由于指標(biāo)體系不夠完善，因此其“AWR報(bào)告”大多數(shù)只是一個擺設(shè)，除了TOP SQL功能外，并不能給運(yùn)維帶來更大的幫助。

GaussDB的可觀測性指標(biāo)做得相當(dāng)不錯，指標(biāo)內(nèi)容很豐富，指標(biāo)的指向性也相當(dāng)不錯，而要做好“AWR報(bào)告”的基礎(chǔ)就是這些準(zhǔn)確而豐富的指標(biāo)?；谶@一點(diǎn)，我對GaussDB WDR報(bào)告的期待還是有點(diǎn)高的。下面我?guī)е蠹襾頌g覽一下GaussDB的WDR報(bào)告，看看這個報(bào)告能否滿足DBA日常運(yùn)維分析數(shù)據(jù)庫性能與故障的需要。

圖片

GaussDB的WDR報(bào)告全稱是工作負(fù)載診斷報(bào)告，不過在TPOPS里被稱為“性能報(bào)告”，我覺得“性能報(bào)告”不夠嚴(yán)謹(jǐn)，不過如果用“工作負(fù)載診斷報(bào)告”又有點(diǎn)不夠高大上。根據(jù)GaussDB分布式數(shù)據(jù)庫的特爾點(diǎn)，這個報(bào)告分為三種類別：集群、CN節(jié)點(diǎn)和DN節(jié)點(diǎn)。這三種類型的工作負(fù)載放在一起又比較亂，分為三種格式是比較合適的，這方面GaussDB的設(shè)計(jì)還是比較符合DBA的習(xí)慣的，不過我也在思考分布式數(shù)據(jù)庫的“AWR報(bào)告”是不是像PolarDB一樣做成單文件多頁的更加易讀。不過對于GaussDB這樣的可能會有很多個節(jié)點(diǎn)的分布式數(shù)據(jù)庫，如果整個集群生成一份報(bào)告，也有一些副作用，一份報(bào)告生成的時間可能會比較長，而且有時候我們并不需要整個集群所有節(jié)點(diǎn)的報(bào)告。    

今天因?yàn)闀r間關(guān)系，我先以集群報(bào)告為主線給大家介紹一下WDR都包含了哪些內(nèi)容。因?yàn)閳?bào)告的內(nèi)容比較多，因此我們將略去一些平時不大關(guān)注的內(nèi)容。

圖片

Database Stat我原本想略去的，不過里面還是有一些有價(jià)值的信息的，包括各個數(shù)據(jù)庫的Tuple、blk hit等信息對于DBA用來了解數(shù)據(jù)庫級別的總體訪問性能還是有價(jià)值的。

Gaussd的Load Profile和Oracle有點(diǎn)像，不過缺少了關(guān)于SQL解析的相關(guān)數(shù)據(jù)，實(shí)際上高斯數(shù)據(jù)庫里是有相關(guān)指標(biāo)的，不知道為什么沒有收錄進(jìn)來。WDR報(bào)告中的Load Profile在指標(biāo)選取上有點(diǎn)刻意學(xué)習(xí)Oracle了，實(shí)際上GaussDB的負(fù)載指標(biāo)與Oracle有較大的不同，可以提供比Oracle還豐富的負(fù)載信息，包括select /delete/update/insert/ddl/dcl等的負(fù)載信息，如果能把這些內(nèi)容收錄進(jìn)來就更好了。

圖片

在負(fù)載文件后面提供的P80/P95 sql響應(yīng)時間的數(shù)據(jù)，這是十分好的，特別是對于一些交易類系統(tǒng)，這兩個指標(biāo)便于發(fā)現(xiàn)系統(tǒng)中的SQL性能是否存在問題。    

圖片

這個報(bào)告中的命中率和IO PROFILE明顯有點(diǎn)敷衍了，估計(jì)很少有DBA能夠在這些指標(biāo)中看出系統(tǒng)到底有啥問題。以我對GaussDB的了解都知道，在這里可以顯示的數(shù)據(jù)可以翻好幾倍。

圖片

隨后是TOP SQL的報(bào)告，說實(shí)在的GaussDB的SQL報(bào)告內(nèi)容還是不錯的，十分詳盡，除了TOP SQL的維度分解十分全面外，每條SQL的執(zhí)行指標(biāo)分解也比較全面。特別是后面sort/hash的詳情分解對于一些復(fù)雜SQL的性能問題分析，是一目了然的。    

圖片

Cache IO Stats是Oracle沒有的內(nèi)容，針對TOP OBJECT的緩沖命中情況進(jìn)行分析。這對于發(fā)現(xiàn)shared_buffers設(shè)置是否過小，以及某些數(shù)據(jù)是否需要預(yù)熱還是比較有用的。通過對某些對象Cache IO的狀態(tài)也可以為解釋某條SQL為什么會在執(zhí)行計(jì)劃沒有變化的情況下，執(zhí)行時間變長的某種原因。

圖片

Object Stats相當(dāng)于Oracle的Top Segments，用于發(fā)現(xiàn)某個對象存在的問題有一定的價(jià)值。維度劃分也比較詳細(xì)，應(yīng)用開發(fā)商應(yīng)該能夠從中發(fā)現(xiàn)很多有價(jià)值的信息。

至此看到的WDR報(bào)告的內(nèi)容雖然說存在一定的遺憾，不過總體還是不錯的?？上У氖强吹竭@里報(bào)告也到了結(jié)尾，似乎有點(diǎn)意猶未盡，作為一個DBA，我還沒有看到一些我特別想看到的東西。    

這份報(bào)告如果用于性能分析，那么一些關(guān)鍵指標(biāo)的數(shù)據(jù)依然是十分需要的，可惜這里沒有。GaussDB的WDR報(bào)告中把更多的細(xì)節(jié)留在CN節(jié)點(diǎn)的報(bào)告中，集群報(bào)告似乎過于簡單了。即使細(xì)節(jié)可以從CN節(jié)點(diǎn)的報(bào)告中獲得，在集群的報(bào)告里，還是缺少了一些十分重要的信息，目前從GaussDB的可觀測性指標(biāo)中，這些數(shù)據(jù)都是可以十分輕松地獲取到的，要想加在報(bào)告里并不困難。我從一個DBA的角度列舉一下我希望在WDR集群報(bào)告里想看到但是沒看到的數(shù)據(jù)：

1）集群的拓?fù)湫畔ⅲ珻MS/CN/DN/GTM/ETCD等的基本信息，基本健康狀態(tài)等。

2）系統(tǒng)關(guān)鍵指標(biāo)詳細(xì)清單（集群匯總信息）。

3）系統(tǒng)關(guān)鍵目錄的使用情況（各節(jié)點(diǎn)數(shù)據(jù)目錄/日志目錄）。

4）全局事務(wù)的總體情況。

5）報(bào)告時間區(qū)間內(nèi)的數(shù)據(jù)庫鎖沖突情況。

6）SEQUENCE的使用情況。

7）復(fù)制組與RTO/RPO情況。

8）集群負(fù)載均衡性，集群中各個CN節(jié)點(diǎn)的負(fù)載是否均衡。集群資源使用均衡性（CPU/IO/內(nèi)存/網(wǎng)絡(luò)）。

今天只是分析了一下集群的WDR報(bào)告，還有一些信息會在CN/DN的報(bào)告中看到。在沒有分析CN/DN節(jié)點(diǎn)的WDR之前，我先不做總體的評價(jià)，等CN/DN報(bào)告分析結(jié)束后再來做最后的點(diǎn)評吧。