转眼六、七年过去了，在此期间也或多或少的和金仓数据库打交道，不过并不深入，干的主要的活还是和开发商一起优化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还比较困难，但是我们的国产数据库的不断成长，对于企业的大部分应用场景的支持与覆盖已经不成问题。我们必须给国产数据库足够的理解与支持，他们才能够在我们的应用需求的推动下，慢慢的从不好用变得能用，再变得好用，国产数据库的成长离不开广大用户的理解与支持。
