前些天一個(gè)D-SMART的用戶說在用PG 14的等待事件分析工具分析系統(tǒng)的等待事件的時(shí)候，發(fā)現(xiàn)工具能夠采集到相關(guān)的等待事件，但是無法對(duì)某些等待事件進(jìn)行推理，導(dǎo)致部分等待事件背后隱藏的問題無法被發(fā)現(xiàn)。比如CommitTs等待事件應(yīng)該代表了當(dāng)時(shí)事務(wù)負(fù)載很高，而且當(dāng)時(shí)服務(wù)器的IO性能不佳，但是工具并沒有展現(xiàn)出這方面的推理結(jié)果。

在我的印象里，PG的運(yùn)維知識(shí)圖譜中是包含了這些等待事件的知識(shí)描述的，于是我打開系統(tǒng)檢查了一下。下一秒鐘，我驚訝地發(fā)現(xiàn)，在我們的知識(shí)圖譜里并沒有CommitTs這個(gè)等待事件，而是commit_timestamp。難道是PG 14的等待事件發(fā)生了變化？于是我查找了一下這方面的資料，發(fā)現(xiàn)從PG 13開始，PG的研發(fā)人員認(rèn)為以前版本PG的等待事件名稱有些隨意，出于嚴(yán)謹(jǐn)?shù)目茖W(xué)態(tài)度，從PG 13起作了較大的優(yōu)化。在D-SMART中PG等待事件的知識(shí)圖譜是以PG 10為藍(lán)圖構(gòu)建的，并且在11、12版本出現(xiàn)后都做了升級(jí)。但是PG 13后等待事件的知識(shí)圖譜就沒有做過升級(jí)了，雖然后面陸續(xù)增加了人大金倉、GAUSSDB等的等待事件，但是并沒有針對(duì)PG 13做升級(jí)。因此目前D-SMART的等待事件分析推理工具對(duì)PG 13或者以后的PG數(shù)據(jù)庫版本的支持是存在問題的。

數(shù)據(jù)庫的一些監(jiān)控接口發(fā)生較大的變化是數(shù)據(jù)庫生態(tài)工具廠商最頭疼的事情，因?yàn)檫@些工具廠商必須投入巨大的成本才能不斷地進(jìn)行版本適配。以前工具僅僅支持Oracle數(shù)據(jù)庫的時(shí)候，是沒有這個(gè)問題的，因?yàn)獒槍?duì)Oracle數(shù)據(jù)庫，我們只需要不斷的加入新版本的功能就可以了，不需要針對(duì)以前已經(jīng)完成的功能不斷的進(jìn)行版本迭代。Oracle的等待事件也是如此，新版本只會(huì)增加新的等待事件，不會(huì)修改已經(jīng)存在的等待事件。最為典型的例子就是db file sequential read和db file scatterd read，這原本是Oracle內(nèi)核研發(fā)中發(fā)生的一個(gè)烏龍事件，當(dāng)時(shí)把離散讀和順序讀的等待事件弄反了，但是后來Oracle很“科學(xué)”的解釋了這個(gè)錯(cuò)誤，但是出于知識(shí)延續(xù)性的問題，并沒有對(duì)此進(jìn)行糾正。久而久之這兩個(gè)等待事件也成為了數(shù)據(jù)庫IO等待事件關(guān)于離散讀和順序讀的標(biāo)準(zhǔn)。在OWI方面也是如此，雖然目前v$session已經(jīng)包含了完整的會(huì)話等待事件的信息，但是v$session_wait視圖依然保留著。我有時(shí)候還會(huì)偶爾錯(cuò)用，用v$session_wait來分析等待事件。而新一代的DB可能都不一定知道這個(gè)接口到底是干啥用的。在OWI剛剛出來的Oracle 7.3.4里，這個(gè)接口就存在了，我們只能用v$session 來分析會(huì)話的其他信息，不能分析等待事件，因?yàn)榈却录荒軓牧硗庖粋€(gè)接口—v$session_wait中獲得。

保持?jǐn)?shù)據(jù)庫接口的向下兼容性是對(duì)產(chǎn)品和客戶負(fù)責(zé)的表現(xiàn)，雖然PG 13后的等待事件命名更科學(xué)一些，但是我不大認(rèn)可這種做法。因?yàn)檫@會(huì)打破知識(shí)的傳承，讓使用者的學(xué)習(xí)成本增加。在接口上也是如此，變來變?nèi)サ慕涌谧寯?shù)據(jù)庫核心開發(fā)人員覺得更爽了，因?yàn)榇_實(shí)改變后更合理了，但是對(duì)于使用者來說，其學(xué)習(xí)成本就大幅度增加了。去年年底Oceanbase 4.0發(fā)布的時(shí)候，我就和螞蟻的朋友吐槽，好不容易把OB 3.0復(fù)雜的監(jiān)控視圖搞明白了，OB 4.0來了個(gè)大顛覆，我又得從頭學(xué)起了。OB的研發(fā)人員很驚訝的說：“你難道沒覺得現(xiàn)在的監(jiān)控視圖用起來更舒服了嗎？4.0的視圖更加科學(xué)了！”。確實(shí)4.0的視圖更科學(xué)了，但是我并不喜歡，因?yàn)槲疫€要從頭學(xué)習(xí)，以前的很多關(guān)于OB 的工具、和腳本也都要重新適配，這樣的更科學(xué)的接口，實(shí)際上是不夠科學(xué)的。更好的做法是保留這些接口，再新增一組“更科學(xué)”的接口。

商用數(shù)據(jù)庫不是開發(fā)者的玩具，而是要被用戶長期使用的，不斷升級(jí)的技術(shù)不應(yīng)該讓使用者的知識(shí)不斷的過期，保持知識(shí)與接口的兼容性方面，我們的國產(chǎn)數(shù)據(jù)庫還是有很多地方要多學(xué)學(xué)Oracle。