聊聊人大金倉KES數據庫的可觀測性能力
?和人大金倉數據庫的第一次接觸是2014年某省的省調要把Oracle數據庫去掉，換成人大金倉數據庫。當時省調自動化處的處長十分憂慮，認為調度這么復雜并且關鍵的系統，用Oracle還算比較省心，換了國產數據庫，會不會今后都沒有好日子過了。2016年，全國產方案的調控云在他那兒成功上線，這也確實讓我這個Oracle DBA感到有些意外。在此期間，我們的優化團隊也參與了一些基于金倉數據庫的優化工作，第一次接觸了這個國產數據庫。說實在的，這次優化雖然按用戶的需求完成了任務，不過也讓我們感到了國產數據庫與Oracle的技術差距。因為我們團隊缺乏對金倉數據庫的了解，并且當時能夠獲得的文檔也十分有限，而人大金倉數據庫能夠對外提供的可觀測性接口也十分有限，也沒有我們在Oracle數據庫上習慣使用的AWR報告，ASH報告，等待事件分析等功能。因此我們不知道如何去更好的調優金倉數據庫，使之與用戶的應用更為融合，優化主要主要集中在和開發商一起對慢SQL的優化上，對于其他的問題，我們是無能為力的。
轉眼六、七年過去了，在此期間也或多或少的和金倉數據庫打交道，不過并不深入，干的主要的活還是和開發商一起優化SQL。隨著信創工作的開展，有不少客戶都選擇了金倉數據庫替代Oracle，于是針對金倉的運維與運維工具的需求多了起來，因此我們的數據庫運維工具D-SMART與金倉KES的對接也日益急迫。
作為一款深度運維工具，D-SMART要覆蓋健康監控、故障預警、問題診斷、定期巡檢、專項審計等諸多自動化運維功能，想要在KES完成這些自動化工具，KES本身能夠提供的可觀測性接口就十分關鍵。有些國產、開源數據庫因為可觀測性接口過于簡單，導致D-SMART對其的支持能力很難提升。
再次和人大金倉結緣，KES的版本已經是V8了，令人高興的是，KES的官方文檔比起六、七年前有了較大的提升。豐富的文檔為我們梳理KES的運維知識提供了很大的便利，我和幾個KES的老用戶交流的時候，他們也覺得V8版本在文檔上的提高還是挺大的，這些文檔對他們日常運維也很有幫助。
在可觀測性方面，KES V8也有了很大的提升。這一點我們可以從KWR報告的內容上看得出來。KWR是模仿Oracle AWR的一個性能分析報告。AWR是DBA運維Oracle數據庫不可或缺的工具，因此很多國產數據庫也都提供類似AWR的功能，也有一些朋友為MYSQL/PG等開源數據庫也提供了類似的報告。只不過這些報告大多數是照貓畫虎，只學了Oracle AWR的形，而沒有得到AWR的神。數據不夠豐富與有效導致了這些類AWR報告實際上對運維的作用有限。
KWR報告的基本內容還是全面致敬Oracle AWR報告的，負載文件、重要百分比、操作系統、IO，時間模型、TOP SQL、數據庫狀態統計等一應俱全。不過大多數國產數據庫的類AWR報告也包含這些內容。我們還需要進一步觀察其實際內容。
從TOP WAIT EVENTS上我們看到了最想看到的AVG Times指標，在很多國產數據庫上我們也能看到等待事件，但是我們僅能看到等待事件的次數統計，無法了解到等待事件的等待時長信息。等待次數只能讓我們感受到數據庫的并發方面的等待，并不能告訴我們哪些等待事件存在問題。比如說WALWriteLock等待，我們知道在報告期間一共產生了98103次，但是如果僅僅知道等待次數，我們是無法確定WAL寫入是否存在性能問題的。但是如果我們看到了平均等待時間是20.94毫秒，那么我們基本上可以確定當前系統肯定是存在問題了。
發現了日志寫存在問題，那么我們就可以從Host IO這一章節去做進一步分析了，在這里我們明顯看出了寫IO延時存在問題，要遠遠高于讀IO的延時。在數據庫的可觀測性接口上能夠提供等待時長，是DBA最希望的。除此之外，KES V8還提供了一個類似于Oracle ASH的KSH，將sys_stat_activity中的采樣定期刷新到數據表中。這對于DBA分析故障，定位性能問題提供了很有效的能力。
KES V8的等待事件等待時長是采集到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 表中。
KES V8提供的SYS_STAT_SQLWAIT給運維人員提供了十分有價值的數據，可以用于對數據庫、SQL以及整體性能提供強大的分析能力。利用KES V8提供的可觀測性接口，D-SMART構建了數據庫運行質量監控方面的基礎能力。
在健康模型中，我們能夠針對KES 數據庫構建類似Oracle數據庫一樣的數據庫IO相關的指標模型。
我們不僅能夠了解數據庫的IO負載情況，也能了解數據庫的IO質量，從而更為準確的掌握數據庫的狀態，找到數據庫運行中的短板。
數據庫等待事件分析工具也因為有了平均等待時間而可以更為準確的定位數據庫中等待事件存在的問題，從而為DBA支持問題定位的方向。
利用專門為KES等待事件構建的運維知識圖譜，智能分析算法可以很準確的定位到，當前數據庫存在的主要問題集中在并發上，次要問題集中在IO性能上。
在構建KES運維知識圖譜的時候，我們除了利用了以往運維與優化KES的知識積累外，最重要的依據就是人大金倉官方提供的各種手冊。只有少數幾個可觀測性接口是通過咨詢金倉的售后服務人員后才搞明白的。從一點上可以看出目前金倉KES的文檔資料還是相對豐富的。在文檔方面，金倉數據庫雖然與Oracle數據庫還有一定的差距，不過在國產數據庫中已經處于中上水平。
對比這些年與金倉KES的兩次深度接觸，也感受到了國產數據庫在不斷的進步。國產數據庫雖然想要趕超Oracle還比較困難，但是我們的國產數據庫的不斷成長，對于企業的大部分應用場景的支持與覆蓋已經不成問題。我們必須給國產數據庫足夠的理解與支持，他們才能夠在我們的應用需求的推動下，慢慢的從不好用變得能用，再變得好用，國產數據庫的成長離不開廣大用戶的理解與支持。?
