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

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

圖片

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

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

圖片

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

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

圖片

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

圖片

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

圖片

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

圖片

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

圖片

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

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

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

1）集群的拓撲信息，CMS/CN/DN/GTM/ETCD等的基本信息，基本健康狀態(tài)等。

2）系統(tǒng)關鍵指標詳細清單（集群匯總信息）。

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

4）全局事務的總體情況。

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

6）SEQUENCE的使用情況。

7）復制組與RTO/RPO情況。

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

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