?和人大金倉數(shù)據(jù)庫的第一次接觸是2014年某省的省調(diào)要把Oracle數(shù)據(jù)庫去掉，換成人大金倉數(shù)據(jù)庫。當(dāng)時省調(diào)自動化處的處長十分憂慮，認(rèn)為調(diào)度這么復(fù)雜并且關(guān)鍵的系統(tǒng)，用Oracle還算比較省心，換了國產(chǎn)數(shù)據(jù)庫，會不會今后都沒有好日子過了。2016年，全國產(chǎn)方案的調(diào)控云在他那兒成功上線，這也確實(shí)讓我這個Oracle DBA感到有些意外。在此期間，我們的優(yōu)化團(tuán)隊(duì)也參與了一些基于金倉數(shù)據(jù)庫的優(yōu)化工作，第一次接觸了這個國產(chǎn)數(shù)據(jù)庫。說實(shí)在的，這次優(yōu)化雖然按用戶的需求完成了任務(wù)，不過也讓我們感到了國產(chǎn)數(shù)據(jù)庫與Oracle的技術(shù)差距。因?yàn)槲覀儓F(tuán)隊(duì)缺乏對金倉數(shù)據(jù)庫的了解，并且當(dāng)時能夠獲得的文檔也十分有限，而人大金倉數(shù)據(jù)庫能夠?qū)ν馓峁┑目捎^測性接口也十分有限，也沒有我們在Oracle數(shù)據(jù)庫上習(xí)慣使用的AWR報告，ASH報告，等待事件分析等功能。因此我們不知道如何去更好的調(diào)優(yōu)金倉數(shù)據(jù)庫，使之與用戶的應(yīng)用更為融合，優(yōu)化主要主要集中在和開發(fā)商一起對慢SQL的優(yōu)化上，對于其他的問題，我們是無能為力的。

轉(zhuǎn)眼六、七年過去了，在此期間也或多或少的和金倉數(shù)據(jù)庫打交道，不過并不深入，干的主要的活還是和開發(fā)商一起優(yōu)化SQL。隨著信創(chuàng)工作的開展，有不少客戶都選擇了金倉數(shù)據(jù)庫替代Oracle，于是針對金倉的運(yùn)維與運(yùn)維工具的需求多了起來，因此我們的數(shù)據(jù)庫運(yùn)維工具D-SMART與金倉KES的對接也日益急迫。

作為一款深度運(yùn)維工具，D-SMART要覆蓋健康監(jiān)控、故障預(yù)警、問題診斷、定期巡檢、專項(xiàng)審計等諸多自動化運(yùn)維功能，想要在KES完成這些自動化工具，KES本身能夠提供的可觀測性接口就十分關(guān)鍵。有些國產(chǎn)、開源數(shù)據(jù)庫因?yàn)榭捎^測性接口過于簡單，導(dǎo)致D-SMART對其的支持能力很難提升。

再次和人大金倉結(jié)緣，KES的版本已經(jīng)是V8了，令人高興的是，KES的官方文檔比起六、七年前有了較大的提升。豐富的文檔為我們梳理KES的運(yùn)維知識提供了很大的便利，我和幾個KES的老用戶交流的時候，他們也覺得V8版本在文檔上的提高還是挺大的，這些文檔對他們?nèi)粘＿\(yùn)維也很有幫助。

在可觀測性方面，KES V8也有了很大的提升。這一點(diǎn)我們可以從KWR報告的內(nèi)容上看得出來。KWR是模仿Oracle AWR的一個性能分析報告。AWR是DBA運(yùn)維Oracle數(shù)據(jù)庫不可或缺的工具，因此很多國產(chǎn)數(shù)據(jù)庫也都提供類似AWR的功能，也有一些朋友為MYSQL/PG等開源數(shù)據(jù)庫也提供了類似的報告。只不過這些報告大多數(shù)是照貓畫虎，只學(xué)了Oracle AWR的形，而沒有得到AWR的神。數(shù)據(jù)不夠豐富與有效導(dǎo)致了這些類AWR報告實(shí)際上對運(yùn)維的作用有限。

KWR報告的基本內(nèi)容還是全面致敬Oracle AWR報告的，負(fù)載文件、重要百分比、操作系統(tǒng)、IO，時間模型、TOP SQL、數(shù)據(jù)庫狀態(tài)統(tǒng)計等一應(yīng)俱全。不過大多數(shù)國產(chǎn)數(shù)據(jù)庫的類AWR報告也包含這些內(nèi)容。我們還需要進(jìn)一步觀察其實(shí)際內(nèi)容。

從TOP WAIT EVENTS上我們看到了最想看到的AVG Times指標(biāo)，在很多國產(chǎn)數(shù)據(jù)庫上我們也能看到等待事件，但是我們僅能看到等待事件的次數(shù)統(tǒng)計，無法了解到等待事件的等待時長信息。等待次數(shù)只能讓我們感受到數(shù)據(jù)庫的并發(fā)方面的等待，并不能告訴我們哪些等待事件存在問題。比如說WALWriteLock等待，我們知道在報告期間一共產(chǎn)生了98103次，但是如果僅僅知道等待次數(shù)，我們是無法確定WAL寫入是否存在性能問題的。但是如果我們看到了平均等待時間是20.94毫秒，那么我們基本上可以確定當(dāng)前系統(tǒng)肯定是存在問題了。

發(fā)現(xiàn)了日志寫存在問題，那么我們就可以從Host IO這一章節(jié)去做進(jìn)一步分析了，在這里我們明顯看出了寫IO延時存在問題，要遠(yuǎn)遠(yuǎn)高于讀IO的延時。在數(shù)據(jù)庫的可觀測性接口上能夠提供等待時長，是DBA最希望的。除此之外，KES V8還提供了一個類似于Oracle ASH的KSH，將sys_stat_activity中的采樣定期刷新到數(shù)據(jù)表中。這對于DBA分析故障，定位性能問題提供了很有效的能力。

KES V8的等待事件等待時長是采集到sys_stat_sqlwait系統(tǒng)視圖中的。其采集粒度細(xì)化到queryid，我們可以根據(jù)userid,datid，queryid,wait_event等粒度來進(jìn)行匯總分析。同時可以通過bgwait標(biāo)識位來排除后臺進(jìn)程產(chǎn)生的等待。通過統(tǒng)計數(shù)據(jù)CALLS/TIMES這對組合可以計算平均等待時間。這種設(shè)計雖然在采集與存儲這些數(shù)據(jù)上會消耗一些性能，但是對于大多數(shù)應(yīng)用場景來說，影響并不大，與這些數(shù)據(jù)帶來的運(yùn)維方面的能力提升相比，這點(diǎn)性能損耗完全能夠接受。當(dāng)然在一些高并發(fā)，低延時SQL為主，對響應(yīng)時間有嚴(yán)格要求的場景，這方面的性能損失可能無法接受，可以通過參數(shù)關(guān)閉這方面的數(shù)據(jù)采集。

我們可以通過匯總這張表的數(shù)據(jù)獲得等待事件的平均等待時間，也可以按照QUERYID來統(tǒng)計該數(shù)據(jù)，從而發(fā)現(xiàn)不同SQL語句的buffer_content方面的差異。

這些SQL產(chǎn)生的熱塊沖突明顯是比較嚴(yán)重的，我們可以加以關(guān)注。

這幾個數(shù)據(jù)庫的數(shù)據(jù)文件讀的平均等待時間明顯存在差異，這也是我們今后可以深入分析的數(shù)據(jù)。如果我們定期采樣這個視圖，并在監(jiān)控系統(tǒng)中保存起來，今后我們就可以通過兩個采樣點(diǎn)之間的DELTA值計算某個時間段內(nèi)的等待事件的平均等待時間。在KWR的采樣數(shù)據(jù)中，就已經(jīng)保存了這些數(shù)據(jù)。如果我們設(shè)置了定期采樣KWR，就可以通過這些數(shù)據(jù)來做較為粗略的分析。如果你開啟了KWR功能，并且做了定期采樣，那么數(shù)據(jù)將會被保存在perf.kwr_snap_sql_wait 表中。

KES V8提供的SYS_STAT_SQLWAIT給運(yùn)維人員提供了十分有價值的數(shù)據(jù)，可以用于對數(shù)據(jù)庫、SQL以及整體性能提供強(qiáng)大的分析能力。利用KES V8提供的可觀測性接口，D-SMART構(gòu)建了數(shù)據(jù)庫運(yùn)行質(zhì)量監(jiān)控方面的基礎(chǔ)能力。

在健康模型中，我們能夠針對KES 數(shù)據(jù)庫構(gòu)建類似Oracle數(shù)據(jù)庫一樣的數(shù)據(jù)庫IO相關(guān)的指標(biāo)模型。

我們不僅能夠了解數(shù)據(jù)庫的IO負(fù)載情況，也能了解數(shù)據(jù)庫的IO質(zhì)量，從而更為準(zhǔn)確的掌握數(shù)據(jù)庫的狀態(tài)，找到數(shù)據(jù)庫運(yùn)行中的短板。

數(shù)據(jù)庫等待事件分析工具也因?yàn)橛辛似骄却龝r間而可以更為準(zhǔn)確的定位數(shù)據(jù)庫中等待事件存在的問題，從而為DBA支持問題定位的方向。

利用專門為KES等待事件構(gòu)建的運(yùn)維知識圖譜，智能分析算法可以很準(zhǔn)確的定位到，當(dāng)前數(shù)據(jù)庫存在的主要問題集中在并發(fā)上，次要問題集中在IO性能上。

在構(gòu)建KES運(yùn)維知識圖譜的時候，我們除了利用了以往運(yùn)維與優(yōu)化KES的知識積累外，最重要的依據(jù)就是人大金倉官方提供的各種手冊。只有少數(shù)幾個可觀測性接口是通過咨詢金倉的售后服務(wù)人員后才搞明白的。從一點(diǎn)上可以看出目前金倉KES的文檔資料還是相對豐富的。在文檔方面，金倉數(shù)據(jù)庫雖然與Oracle數(shù)據(jù)庫還有一定的差距，不過在國產(chǎn)數(shù)據(jù)庫中已經(jīng)處于中上水平。

對比這些年與金倉KES的兩次深度接觸，也感受到了國產(chǎn)數(shù)據(jù)庫在不斷的進(jìn)步。國產(chǎn)數(shù)據(jù)庫雖然想要趕超Oracle還比較困難，但是我們的國產(chǎn)數(shù)據(jù)庫的不斷成長，對于企業(yè)的大部分應(yīng)用場景的支持與覆蓋已經(jīng)不成問題。我們必須給國產(chǎn)數(shù)據(jù)庫足夠的理解與支持，他們才能夠在我們的應(yīng)用需求的推動下，慢慢的從不好用變得能用，再變得好用，國產(chǎn)數(shù)據(jù)庫的成長離不開廣大用戶的理解與支持。?