KINGBASE ES V8的等待事件增强

今天和大家讨论的是关于人大金仓KINGBASE V8.6在等待事件方面的增强特性。D-SMART针对人大金仓V8.6的增强特性的支持是近期研发计划的内容，这些工作从一个多月前就已经开始了，指标梳理、等待事件知识图谱优化等工作在一个多月前就已经基本完成。相关的诊断脚本优化、巡检工具提升等工作也在陆续进行，只是因为疫情，大量研发人员都倒了，因此整个工作也变得支离破碎，其完整功能可能无法全面出现在12月社区版的发布版本里了。

为了这部分功能的研发，我们在几个月前就开始了针对KINGBASE ES V8.6的可观测性能力增强方面的技术分析。与V8.2相比，人大金仓的V8.6增加了kwr/ksh/kddm等性能分析工具，在可观测性方面，为数据库运维通过了更有效的手段。

从上面的基础信息可以看出，KINGBASE ES V8.6版本是基于PG 12.1内核的，与V8.2的PG 9.X内核相比，有了较大的版本变动。对于PG内核来说，我们诟病的比较多的是我们仅仅能够通过pg_stat_activity去统计一些等待事件的发生次数，不能通过等待时长来发现系统中某些等待事件现象可能存在的隐患。

基于PG代码的国产数据库产品，如果要实现类似Oracle AWR/ASH/ADDM这样的功能，如果仅仅依靠原生态开源代码的等待事件，是无法让这些报告具有Oracle数据库那样的分析能力的。我以前也分析过一些数据库产品模仿Oracle AWR报告，这些报告虽然内容上学的很像，但是缺少了一些灵魂-那就是数据的准确性。只有当报告中的各种数据能够十分清晰的反映出数据库运行的状态时，这些报告才有价值。

Kingbase的kwr报告依然是学习Oracle的AWR报告，虽然从章节上看，还是没有Oracle那么丰富，不过比起一些“国产AWR报告”来，还算是内容比较丰富的。

让我比较意外的是，在TOP 10 Foreground Wait Events中我看到了Avg Time这个列，这就意味着Kingbase中对等待事件做了等待时间的采集。有了这一个指标，就为通过等待事件的变化来分析数据库出现了某些问题提供了基础。

通过和人大金仓的技术人员的交流，我们了解到在V8.6版本中，他们在可观测性接口上有两个较大的提升，一个是提供了等待事件时长的指标，另外一个是提供了类似Oracle ASH的等待事件历史采样。这两样东西都是D-SMART进行数据库性能与故障分析最为需要的，于是我们对此做了一番分析。

于是我们就这这个问题做了比较深入的探索，首先我们从文档入手进行分析，查找这个接口。人大金仓V8.6以后的产品手册做了较大的优化，手册无论从种类还是从内容方面来看，都比V8.3/V8.2有了质的提升。不过通过翻阅相关手册后，我们还是没有找到相关的接口描述。仅仅从参数设置上，我们看到了一些不同。

Trace_wait_timing,trace_io_timing等参数是以前版本中没有的，而这些参数正是使用kwr/ksh必须打开的参数。打开这些参数后，针对等待事件的采样数据才是完整的。以前我也分析过openGauss、Polardb等同样基于PG开发的国产数据库产品，在等待事件增强方面，大家采取的措施都十分类似，那就是不去修改pg_stat_activity这个性能视图，而是新增接口来实现采集。KES在等待事件的等待时长采集方面也采取了类似的方法，不过KES的实现方式与openGauss和Polardb有着较大的不同。

KES将等待事件的等待明细情况记录到了一张名为sys_stat_sqlwait的系统表中。

刚刚开始接触到这张系统表的时候，我还觉得有点奇怪，为什么KES要设计如此怪异的一张表来保存等待事件的一些细节数据呢？经过仔细考虑后，我觉得这种设计是一种综合考虑后的妥协。如果对于这张表的数据进行合并统计，就可以粗略的了解到某个等待事件在某个时间段内的平均延时等信息。如果按照QUERYID进行分组统计，还可以计算出某个时间段内某个等待事件在不同QUERY上的差异。

而如果通过QUERYID和DBID进行统计分析，那么我们还可以知道某个QUERYID执行过程中，其等待事件的等待分布以及等待平均延时这些信息。等待事件与QUERYID关联的作用是十分明显的，绝大多数数据库性能问题都特定的SQL语句有关，而某条SQL运行不正常时候，通过等待事件的差异也可以做更精准的定位。

KES V8.6的另外一个十分重要的可观测性接口是类似于Oracle ASH的ksh。一旦打开了sys_ksh.enable参数，就开启了KSH自动采集。KES内核就会自动将抽样采集的sys_stat_activity的数据保存在内存中，并自动输出到perf.session_history系统表中。

利用session_history,KES 可以通过perf.ksh_report函数来生成类似于Oracle ASH report这样的活跃会话历史分析报告。ASH报告对于分析某个故障时段到底发生了什么，有什么异常时十分重要的报告工具。

今天我给大家初步介绍了KES V8.6在数据库可观测性上的两个十分重要的特性，实际上我们最近也正在利用这两个特性做一些研发工作，通过这些特性，我们可以大大提升数据库在遇到问题时的分析诊断能力，为用户分析问题，发现需要优化的重点提供一手的结论。今天时间关系，我们先介绍这么多，明天我会带着大家更为深入的去了解这些特性。