第一次接触人大金仓数据库是在2014年的一个省级调查想去掉Oracle数据库，换成人大金仓数据库的时候.当时，省调试自动化处处长很着急，认为这么复杂、关键的系统，用Oracle调度会更省心。2016年，国产计划的监管云和他一起成功上线，着实让我这个OracleDBA很惊喜。这期间我们的优化团队也参与了一些基于金仓数据库的优化工作，这也是我们第一次接触到这个国产数据库。说实话，这次优化虽然按照用户的需求完成了任务，但也让我们感受到了国产数据库与Oracle的技术差距。因为我们团队对金仓数据库缺乏了解，而且当时能得到的文档也非常有限，而且中国人民大学金仓数据库能够对外提供的可观察接口也非常有限，也没有AWR我们习惯在Oracle数据库上使用的报告。、ASH报告、等待事件分析等功能。因此，我们不知道如何更好地调优金仓数据库，使其与用户的应用更加融合。优化主要是和开发者一起优化慢SQL。对于其他问题，我们束手无策。一转眼六七年过去了。期间也或多或少接触过金仓数据库，但并不深入。我做的主要工作是和开发人员一起优化SQL。随着鑫创工作的发展，很多客户都选择了金仓数据库来替代Oracle，因此对金仓运维工具的需求量也随之增加。因此，我们的数据库运维工具D-SMART与金仓KES的对接也越来越迫切。D-SMART作为深度运维工具，需要覆盖健康监测、故障预警、问题诊断、定期巡检、专项审计等诸多自动化运维功能。KES，KES本身能否提供Observable接口很关键。一些国产和开源数据库的可观测性接口过于简单，导致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产生的热块冲突明显比较严重，大家可以关注一下。这些数据库读取数据文件的平均等待时间明显不同，这也是我们以后可以深入分析的数据。如果我们定期对这个view进行采样，保存在监控系统中，就可以通过未来两个采样点之间的DELTA值，计算出某个时间段内等待事件的平均等待时间。在KWR的采样数据中，已经保存了这些数据。如果我们设置KWR的定期采样，我们可以利用这些数据做一个粗略的分析。如果开启KWR功能，做周期采样，数据会保存在perf.kwr_snap_sql_wait表中。KESV8提供的SYS_STAT_SQLWAIT为运维人员提供了非常有价值的数据，可以用来为数据库、SQL和整体性能提供强大的分析能力。D-SMART利用KESV8提供的可观测接口，构建了数据库运行质量监控的基础能力。在健康模型中，我们可以为KES数据库建立一个类似Oracle数据库的数据库IO相关指标模型。我们不仅可以了解数据库的IO负载，还可以了解数据库的IO质量，从而更准确地掌握数据库的状态，找到数据库运行中的短板。数据库等待事件分析工具还可以根据平均等待时间更准确地定位数据库中等待事件存在的问题，为DBA提供问题定位的方向支持。利用专门针对KES等待事件构建的运维知识图谱，智能分析算法可以准确定位当前数据库存在的以并发为中心的主要问题，以IO性能为中心的次要问题。在构建KES运维知识图谱时，除了利用之前KES运维优化的知识积累外，最重要的依据是仁达金仓提供的各种官方手册。咨询了金仓售后服务人员后，只了解了几个可观察性接口。从一点可以看出，目前金仓KES的文档还是比较丰富的。在文档方面，虽然金仓数据库与Oracle数据库还有一定差距，但在国内数据库中已经处于中上水平。对比这些年与金仓KES的两次深入接触，我也觉得国内的数据库在不断完善。虽然国产数据库还很难赶上Oracle，但是随着我们国产数据库的不断壮大，支撑和覆盖企业的大部分应用场景已经不是问题了。我们必须给予国产数据库足够的理解和支持，让它们在我们的应用需求的推动下，逐渐从不能用到可以用再到好用。国产数据库的成长离不开广大用户。理解和支持。
