DBA行業(yè)的老司機(jī)知道等待事件分析對數(shù)據(jù)庫運(yùn)維來說有多么重要，等待事件分析是Oracle在7.3版本中推出OWI后才變得可能的，必須在數(shù)據(jù)庫核心層提供接口才能實(shí)現(xiàn)。

國產(chǎn)數(shù)據(jù)庫在等待事件接口方面也做了很多的工作，我第一次用達(dá)夢數(shù)據(jù)庫的時(shí)候就發(fā)現(xiàn)居然有等待事件，雖然達(dá)夢數(shù)據(jù)庫的等待事件還比較簡單，不過對于運(yùn)維來說還是很有價(jià)值的。最近和Oceanbase、Polardb的朋友交流中也發(fā)現(xiàn)他們也在等待事件分析方面做很多突破性的功能增強(qiáng)，一些能力可能很快就可以合并到主線版本中了。

PostgreSQL是在9.6版本首先引入等待事件的，雖然openGauss的基礎(chǔ)PostgreSQL版本(9.2.4)并不支持等待事件，不過openGauss從1.0開始就支持等待事件了，當(dāng)然2.0之后openGauss的等待事件有了極大的提升，支持了等待時(shí)間。對于等待事件分析來說，支持等待時(shí)間分析是一個(gè)巨大的提升，這可以讓等待事件分析更為有效。

openGauss的等待事件并沒有放在pg_stat_activity中，而是另外使用了一個(gè)視圖接口。這種設(shè)計(jì)我猜想是為了避免對PG內(nèi)核做過多的修改，從而影響PG核心的穩(wěn)定性。因?yàn)榈却录杉蜁?huì)話的活動(dòng)有直接的關(guān)系，涉及到數(shù)據(jù)庫最核心的代碼。openGauss通過兩張表分別來實(shí)現(xiàn)等待事件分析。

一張是thread_wat_status,另外一張是等待事件匯總信息wait_events，記錄了數(shù)據(jù)庫啟動(dòng)以來每個(gè)等待事件發(fā)生的次數(shù)、平均等待時(shí)間，最大等待時(shí)間，最小等待時(shí)間等信息。這張視圖有點(diǎn)類似Oracle的v$eventmetric。

比較Oracle(上圖是11g)的這張視圖，openGauss提供了一些類似信息最大值，最小值，平均值的數(shù)據(jù)，只是有經(jīng)驗(yàn)的DBA都知道全局的最大值最小值是沒有意義的，數(shù)據(jù)庫啟動(dòng)后只要出現(xiàn)過一次極端現(xiàn)象，就會(huì)把這些值固化了，反而對于運(yùn)維來說沒有價(jià)值了。

看樣子這個(gè)功能模塊的產(chǎn)品經(jīng)理運(yùn)維實(shí)戰(zhàn)的經(jīng)驗(yàn)還略顯不足，實(shí)際上如果能夠保存最近1分鐘，最近5分鐘，最近10分鐘，最近半小時(shí)這些最大最小值，或者僅僅保存最近1分鐘的最大/最小值對于運(yùn)維來說更有價(jià)值。不管如何，這種設(shè)計(jì)體現(xiàn)了openGauss數(shù)據(jù)庫產(chǎn)品的開發(fā)者是考慮了運(yùn)維的需求的。

上面是openGauss 2.1的等待事件數(shù)量-321個(gè)，比PG 12足足多了一倍，openGauss 3.0的數(shù)量差不太多。

總數(shù)是353，多了30多個(gè)，每個(gè)版本等待事件數(shù)量都在增加，說明這個(gè)接口的活躍度是可以的，如此發(fā)展下去，這個(gè)功能會(huì)越來越完善。

不過比起Oracle 11g的1367還是有差距，Oracle 19c，這個(gè)數(shù)量贏又快翻了一倍了。國貨還是有很大的發(fā)展余地。不過看等待事件，不僅僅要看數(shù)量，而是要看是不是都是一些有效的等待事件。我們在openGauss3上做了幾次小的benchmark壓測(我們的環(huán)境只是功能測試環(huán)境，一臺(tái)虛擬機(jī)上部署了多套數(shù)據(jù)庫，因此只能做一些小壓測)，大概平均TPMC為2500左右。然后來看看有哪些等待事件是非零的。

相當(dāng)不錯(cuò)了，有66個(gè)等待事件的等待次數(shù)是非零的。類似的情況，在Oracle 11g里，大約也只有100多個(gè)等待事件是非零的，因?yàn)楹芏嗟却录悄承﹫鼍跋虏艜?huì)發(fā)生的。

從這個(gè)查詢中我們可以看到等待事件排序比較靠前的基本上都是和IO相關(guān)的。具體某個(gè)等待事件的含義我們后面再慢慢研究，我們也會(huì)在PG知識(shí)圖譜的基礎(chǔ)上構(gòu)建支持openGaus等待事件分析的知識(shí)圖譜。

接下來我們先來看幾個(gè)openGauss 等待事件性能視圖的考慮的比較好的地方。除了剛才說的并均值之類的，還有就是failed_wait字段和last_updated。正常的系統(tǒng)中一般不會(huì)出現(xiàn)failed wait，如果某個(gè)時(shí)間段里出現(xiàn)了較多的failed wait,說明這個(gè)等待存在較大的問題。而last_updated則記錄了該等待事件最后一次等待的時(shí)間，這在運(yùn)維中遇到了性能問題，需要分析根因的時(shí)候十分重要，有可能這個(gè)時(shí)間戳就可以幫你過濾掉一些重要的等待事件，從而幫你更精準(zhǔn)的定位問題。

說完優(yōu)點(diǎn)，我們就要說說缺點(diǎn)了，Oracle在v$event_histogram中保留了非零等待事件的直方圖數(shù)據(jù)。

這個(gè)數(shù)據(jù)對于做深度的分析十分有價(jià)值。通過定期采集數(shù)據(jù)，可以了解很多等待事件的詳情。

我們再回過頭來看看Oracle的v$eventmetric視圖，通過begin_time/end_time我們會(huì)發(fā)現(xiàn)，對于大多數(shù)EVENT，oracle記錄的都是1分鐘的采樣周期內(nèi)的情況。WAIT EVENT是一種瞬間發(fā)生的等待，在具體的性能分析工作中，長時(shí)間的累計(jì)值實(shí)際上并不重要，更為重要的是最近的情況，而1分鐘的統(tǒng)計(jì)值十分有助于幫助DBA進(jìn)行分析。哪怕存在一些特殊的異常值，通過觀察幾次一分鐘的數(shù)值，就可以基本了解某個(gè)等待事件在此期間的異常情況。

Oracle的v$sysstat中記錄的是一些系統(tǒng)統(tǒng)計(jì)數(shù)據(jù)，這些數(shù)據(jù)記錄一個(gè)統(tǒng)計(jì)值就夠用了，我們可以通過多個(gè)SNAP的差異來進(jìn)行分析。如果我們沒有采集歷史的SNAP，那么分析歷史數(shù)據(jù)還是有些困難的。不過這些指標(biāo)在AWR中都有采集。而對于等待事件這種分析，和統(tǒng)計(jì)數(shù)據(jù)的分析需求是不同的。因此簡單的記錄統(tǒng)計(jì)值是不夠的，openGauss的研發(fā)人員也發(fā)現(xiàn)了這方面的問題，因此增加了一些平均值之類的屬性。不過個(gè)人以多年的運(yùn)維經(jīng)驗(yàn)來看，還是更喜歡使用Oracle的這種模式。有可能是我已經(jīng)在多年的Oracle數(shù)據(jù)庫運(yùn)維中被洗腦了，不過似乎Oracle的方式在現(xiàn)場分析時(shí)效果更好。我們的國產(chǎn)數(shù)據(jù)庫企業(yè)還是需要多學(xué)習(xí)學(xué)習(xí)Oracle在一些細(xì)節(jié)上的處理的。這些細(xì)節(jié)都是多年數(shù)據(jù)庫產(chǎn)品發(fā)展中積累下來的，技術(shù)含量并不一定很高，但是實(shí)戰(zhàn)效果確實(shí)很好。

最后我們再來看看thread_wait_status，令人略感遺憾的是在會(huì)話級的等待事件上并沒有包含等待時(shí)間，我想以后的版本應(yīng)該會(huì)慢慢的加上，能做系統(tǒng)級的等待事件分析已經(jīng)為具有細(xì)粒度等待事件分析的能力提供了一個(gè)基礎(chǔ)。