DBA行业的老司机都知道等待事件分析对于数据库运维有多么重要。等待事件分析只有在Oracle在7.3版本中推出OWI后才能进行。它必须在数据库的核心。层提供要实现的接口。国内的数据库在等待事件接口方面也做了很多工作。刚开始使用大梦数据库的时候，发现有等待事件。虽然大梦数据库的等待事件比较简单，但是运维起来还是很方便的。有价值的。在最近与Oceanbase和Polardb的朋友交流中，我也发现他们在等待事件分析方面也有很多突破性的增强，一些能力可能很快会合并到主线版本中。PostgreSQL在9.6版本中首次引入了等待事件。虽然PostgreSQL基础版本的openGauss（9.2.4）不支持等待事件，但是openGauss从1.0开始就支持等待事件。当然，在2.0之后，openGauss的等待事件有了很大的改善。改进支持等待时间。对于等待事件分析，支持等待时间分析是一个巨大的改进，可以让等待事件分析更加有效。openGauss的等待事件并没有放在pg_stat_activity中，而是使用了另一个视图接口。我猜这个设计是为了避免对PG内核修改太多，影响PG内核的稳定性。因为等待事件采集和session活动有直接的关系，涉及到数据库的核心代码。openGauss分别通过两个表来实现等待事件分析。一个是thread_wat_status，一个是等待事件汇总信息wait_events，它记录了从数据库启动以来每个等待事件的发生次数，平均等待时间，最长等待时间，最短等待时间等信息。这个视图有点类似于Oracle的v$eventmetric。与Oracle（上图11g）的这个视图相比，openGauss提供了一些类似于最大值、最小值、平均值数据的信息，但是有经验的DBA都知道，全局的最大值和最小值是没有意义的，而数据库启动到最后，只要出现极端现象，这些值就会固化下来，但对运维没有任何价值。看来这个功能模块的产品经理在运维方面的实战经验很少。其实如果能保存最后1分钟、最后5分钟、最后10分钟、最后半小时的最大值和最小值，或者只保存最后1分钟的最大值/最小值都是对运营更有价值。不管怎么说，这样的设计体现了openGauss数据库产品的开发者已经考虑到了运维的需求。以上是openGauss2.1的等待事件数——321，足足是PG12的两倍，openGauss3.0的数相差不大。总数是353个，多了30多个。每个版本的等待事件数都在增加，说明这个接口的活跃度是可以接受的。这样下去，这个功能会越来越完善。不过与Oracle11g的1367相比，还是有差距的。在Oracle19c中，这个数字几乎翻了一番。国产产品还有很大的发展空间。但是看等待事件，不仅要看数量，还要看是否都是有效的等待事件。我们在openGauss3上做了几次小的benchmark压测（我们的环境只是功能测试环境，虚拟机部署了多套数据库，所以只能做一些小的压测），平均TPMC在2500左右.然后看哪些等待事件是非零的。非常好，有66个等待事件的等待计数非零。在类似的情况下，在Oracle11g中，只有大约100个等待事件是非零的，因为很多等待事件只发生在特定的场景中。从这个查询可以看出，排名靠前的等待事件基本都和IO相关。后面我们会研究具体的等待事件的含义，我们也会在PG知识图谱的基础上构建一个支持openGaus等待事件分析的知识图谱。接下来我们来看看openGauss等待事件性能视图的一些好的考虑。除了刚才说的均值之外，还有failed_wait字段和last_updated。失败的等待一般不会出现在正常的系统中。如果某个时间段内有很多失败的等待，说明这个等待有很大的问题。而last_updated记录了waiting事件的最后等待时间，在运维中遇到性能问题。分析根本原因非常重要。有可能这个时间戳可以帮你过滤掉一些重要的等待事件。从而帮助您更准确地定位问题。说完优点，再来说说缺点。Oracle将非零等待事件的直方图数据保存在v$event_histogram中。这些数据对于深入分析非常有价值。通过定期收集数据，可以了解有关等待事件的许多详细信息。让我们回头看看Oracle的v$eventmetric视图。通过begin_time/end_time，我们会发现，对于大多数EVENT，Oracle记录的都是1分钟采样周期内的情况。WAITEVENT是一种瞬间发生的等待。在具体的性能分析工作中，长期的累计值其实并不重要，最近的情况更重要，1分钟的统计值对于帮助DBA进行分析很有帮助。即使有一些特殊的异常值，通过多次观察一分钟的值，也基本可以了解这段时间等待事件的异常情况。Oracle的v$sysstat记录了一些系统统计数据。为这些数据记录一个统计值就足够了。我们可以分析多个SNAP的差异。如果不收集历史SNAP，分析历史数据还是有些困难的。但是，这些指标收集在AWR中。等待事件的分析不同于统计数据的分析。因此，仅仅记录统计值是不够的。openGauss的开发者也发现了这方面的问题，所以他们增加了一些属性，比如平均值。但是根据多年的运维经验，我还是更喜欢使用Oracle这种模式。可能是我在Oracle数据库运维上被洗脑了很多年，但是在现场分析上好像Oracle的方法效果更好。我们国内的数据库公司在一些细节上的处理，还是需要多多了解一下Oracle。这些细节都是多年数据库产品开发积累的。技术含量不一定高，但实战效果确实不错。最后我们来看一下thread_wait_status。有点遗憾的是，没有计算session级别的等待时间。我认为以后的版本应该慢慢添加。能够做系统级的等待事件分析，已经为能够对等待事件进行细粒度的分析提供了基础。
