作者介紹
白鳝（徐戟）：南京基石資料技術有限責任公司技術總監，南瑞子衿技術團隊首席架構師。曾供職于DEC、長天集團、聯想集團等。在軟體開發、系統運維、系統優化、資訊系統國産化替代等領域從事技術工作30年多，參與了營運商、金融、政府、能源等行業的資訊化建設。著有《OracleRAC日記》《OracleDBA優化日記》和《DBA的思想天空》等技術專著。深圳市信創産業聯盟進階顧問，OracleACE，POSTGRESQLACEDIRECTOR。
以下為正文：
和人大金倉資料庫的第一次接觸是2014年某省的省調要把Oracle資料庫去掉，換成人大金倉資料庫。當時省調自動化處的處長十分憂慮，認為排程這麼複雜并且關鍵的系統，用Oracle還算比較省心，換了國産資料庫，會不會今後都沒有好日子過了。2016年，全國産方案的調控雲在他那兒成功上線，這也确實讓我這個OracleDBA感到有些意外。在此期間，我們的優化團隊也參與了一些基于金倉資料庫的優化工作，第一次接觸了這個國産資料庫。說實在的，這次優化雖然按使用者的需求完成了任務，不過也讓我們感到了國産資料庫與Oracle的技術差距。因為我們團隊缺乏對金倉資料庫的了解，并且當時能夠獲得的文檔也十分有限，而人大金倉資料庫能夠對外提供的可觀測性接口也十分有限，也沒有我們在Oracle資料庫上習慣使用的AWR報告，ASH報告，等待事件分析等功能。是以我們不知道如何去更好的調優金倉資料庫，使之與使用者的應用更為融合，優化主要集中在和開發商一起對慢SQL的優化上，對于其他的問題，我們是無能為力的。
轉眼六、七年過去了，在此期間也或多或少的和金倉資料庫打交道，不過并不深入，幹的主要的活還是和開發商一起優化SQL。随着信創工作的開展，有不少客戶都選擇了金倉資料庫替代Oracle，于是針對金倉的運維與運維工具的需求多了起來，是以我們的資料庫運維工具D-SMART與金倉KES的對接也日益急迫。
作為一款深度運維工具，D-SMART要覆寫健康監控、故障預警、問題診斷、定期巡檢、專項審計等諸多自動化運維功能，想要在KES完成這些自動化工具，KES本身能夠提供的可觀測性接口就十分關鍵。有些國産、開源資料庫因為可觀測性接口過于簡單，導緻D-SMART對其的支援能力很難提升。
再次和人大金倉結緣，KES的版本已經是V8了，令人高興的是，KES的官方文檔比起六、七年前有了較大的提升。豐富的文檔為我們梳理KES的運維知識提供了很大的便利，我和幾個KES的老使用者交流的時候，他們也覺得V8版本在文檔上的提高還是挺大的，這些文檔對他們日常運維也很有幫助。
在可觀測性方面，KESV8也有了很大的提升。這一點我們可以從KWR報告的内容上看得出來。KWR是模仿OracleAWR的一個性能分析報告。AWR是DBA運維Oracle資料庫不可或缺的工具，是以很多國産資料庫也都提供類似AWR的功能，也有一些朋友為MYSQL/PG等開源資料庫也提供了類似的報告。隻不過這些報告大多數是照貓畫虎，隻學了OracleAWR的形，而沒有得到AWR的神。資料不夠豐富與有效導緻了這些類AWR報告實際上對運維的作用有限。
KWR報告的基本内容還是全面緻敬OracleAWR報告的，負載檔案、重要百分比、作業系統、IO，時間模型、TOPSQL、資料庫狀态統計等一應俱全。不過大多數國産資料庫的類AWR報告也包含這些内容。我們還需要進一步觀察其實際内容。
從TOPWAITEVENTS上我們看到了最想看到的AVGTimes名額，在很多國産資料庫上我們也能看到等待事件，但是我們僅能看到等待事件的次數統計，無法了解到等待事件的等待時長資訊。等待次數隻能讓我們感受到資料庫的并發方面的等待，并不能告訴我們哪些等待事件存在問題。比如說WALWriteLock等待，我們知道在報告期間一共産生了98103次，但是如果僅僅知道等待次數，我們是無法确定WAL寫入是否存在性能問題的。但是如果我們看到了平均等待時間是20.94毫秒，那麼我們基本上可以确定目前系統肯定是存在問題了。
發現了日志寫存在問題，那麼我們就可以從HostIO這一章節去做進一步分析了，在這裡我們明顯看出了寫IO延時存在問題，要遠遠高于讀IO的延時。在資料庫的可觀測性接口上能夠提供等待時長，是DBA最希望的。除此之外，KESV8還提供了一個類似于OracleASH的KSH，将sys_stat_activity中的采樣定期重新整理到資料表中。這對于DBA分析故障，定位性能問題提供了很有效的能力。
KESV8的等待事件等待時長是采集到sys_stat_sqlwait系統視圖中的。其采集粒度細化到queryid，我們可以根據userid，datid，queryid，wait_event等粒度來進行彙總分析。同時可以通過bgwait辨別位來排除背景程序産生的等待。通過統計資料CALLS/TIMES這對組合可以計算平均等待時間。這種設計雖然在采集與存儲這些資料上會消耗一些性能，但是對于大多數應用場景來說，影響并不大，與這些資料帶來的運維方面的能力提升相比，這點性能損耗完全能夠接受。當然在一些高并發，低延時SQL為主，對響應時間有嚴格要求的場景，這方面的性能損失可能無法接受，可以通過參數關閉這方面的資料采集。
我們可以通過彙總這張表的資料獲得等待事件的平均等待時間，也可以按照QUERYID來統計該資料，進而發現不同SQL語句的buffer_content方面的差異。
這些SQL産生的熱塊沖突明顯是比較嚴重的，我們可以加以關注。
這幾個資料庫的資料檔案讀的平均等待時間明顯存在差異，這也是我們今後可以深入分析的資料。如果我們定期采樣這個視圖，并在監控系統中儲存起來，今後我們就可以通過兩個采樣點之間的DELTA值計算某個時間段内的等待事件的平均等待時間。在KWR的采樣資料中，就已經儲存了這些資料。如果我們設定了定期采樣KWR，就可以通過這些資料來做較為粗略的分析。如果你開啟了KWR功能，并且做了定期采樣，那麼資料将會被儲存在perf.kwr_snap_sql_wait表中。
KESV8提供的SYS_STAT_SQLWAIT給運維人員提供了十分有價值的資料，可以用于對資料庫、SQL以及整體性能提供強大的分析能力。利用KESV8提供的可觀測性接口，D-SMART建構了資料庫運作品質監控方面的基礎能力。
在健康模型中，我們能夠針對KES資料庫建構類似Oracle資料庫一樣的資料庫IO相關的名額模型。
我們不僅能夠了解資料庫的IO負載情況，也能了解資料庫的IO品質，進而更為準确的掌握資料庫的狀态，找到資料庫運作中的短闆。
資料庫等待事件分析工具也因為有了平均等待時間而可以更為準确的定位資料庫中等待事件存在的問題，進而為DBA支援問題定位的方向。
利用專門為KES等待事件建構的運維知識圖譜，智能分析算法可以很準确的定位到，目前資料庫存在的主要問題集中在并發上，次要問題集中在IO性能上。
在建構KES運維知識圖譜的時候，我們除了利用了以往運維與優化KES的知識積累外，最重要的依據就是人大金倉官方提供的各種手冊。隻有少數幾個可觀測性接口是通過咨詢金倉的售後服務人員後才搞明白的。從一點上可以看出目前金倉KES的文檔資料還是相對豐富的。在文檔方面，金倉資料庫雖然與Oracle資料庫還有一定的差距，不過在國産資料庫中已經處于中上水準。
對比這些年與金倉KES的兩次深度接觸，也感受到了國産資料庫在不斷的進步。國産資料庫雖然想要趕超Oracle還比較困難，但是我們的國産資料庫的不斷成長，對于企業的大部分應用場景的支援與覆寫已經不成問題。我們必須給國産資料庫足夠的了解與支援，他們才能夠在我們的應用需求的推動下，慢慢的從不好用變得能用，再變得好用，國産資料庫的成長離不開廣大使用者的了解與支援。