数据库的等待事件分析接口其实比我们想象的更丰富

数据库的等待事件分析接口其实比我们想象的更丰富

​等待事件是数据库十分重要的可观测性接口，通过等待事件可以快速定位数据库存在的问题，并及时掌握数据库的运行状态。二十年前的时候，我给一家银行做服务的时候，他们要求核心系统监控，要求监控人员每隔五分钟查看一次是否存在异常等待事件，从而确保核心业务的正常。

***是首先提供等待事件接口的数据库产品，而现在很多数据库也都提供了等待事件接口，只不过提供的能力有些差别。国庆假期七天时间里，我每天看一点SQL SERVER的资料，首先发现微软的文档功力真的十分了得，看SQL SERVER的资料甚至比看***的资料还要舒服。其次我也发现，SQL SERVER在等待事件接口方面也做的十分到位。

今天我就以***、SQL SERVER、***、Polardb四个数据库为例，分析一下这些数据库的等待事件接口的特点，以及如何使用这些接口来进行系统诊断。谈起他数据库之前，我们先来看看等待事件分析的鼻祖***提供了哪些等待事件。我还是用*** 11g这个经典版本为例，虽然这个版本是十多年前推出的，不过在等待事件方面已经十分完善了。

实际上不管是现在的***数据库还是其他一些支持等待事件分析的数据库，都已经和***刚刚推出OWI的时候不同了，等待事件接口也丰富了很多。不过这些年里，我发现大家还在用20多年前OWI刚刚出现时的等待事件接口来分析数据库系统，并没有去使用在某些分析场景下更为有效的一些新的接口数据。这是一种惯性，就像十多年前，我还习惯于使用v$session_wait视图去分析会话的等待事件，而不像一些年轻的DBA一样使用v$session。V$session_wait是***在7.3.2版本中就推出的一个等待事件接口的视图，也是最经典的一个。不过这个视图不是我们今天要讨论的主角，因为目前数据库系统的等待事件分析的数据接口已经极大丰富了。

我习惯于把等待事件接口数据分为明细数据、汇总数据、采样数据以及这些数据的历史数据。这些数据在不同的场景中能够发挥不同的作用，用好了，可以满足DBA的很多方面的分析工作。

明细数据是当前等待事件的实时状态，对于做当前的实时分析是十分有价值的。如果故障问题一直存在，则分析当前的数据可以给我们一个直观的反映。不过在使用v$session的时候，大家要注意一个问题，那就是***的等待事件接口与其他数据库有所不同。我们来看看有什么不同。

我们以往可能仅仅关注active状态的会话，而很少去关注state，***的v$session里显示的等待事件不仅仅是显示正在等待的，而且会显示刚刚等待结束的，状态。所以有时候我们看到的某个等待事件可能当时已经结束了，而不是正在发生，而有些则正在发生。注意到这个差别十分关键，可以帮助我们在细节上分析数据库的等待事件。其他数据库一旦结束某个等待事件，就会立即进入IDLE状态，这样在系统中，我们看到的更多的是IDLE。对等待事件相关视图进行多次查询，可能会有较大的差异。作为DBA，我更喜欢***的这种输出接口的方式。因为大多数情况下，我们不是需要了解准确的实时状态，而是要了解在这个期间的一个大体趋势，保留刚刚结束还没有开始其他等待事件之前的状态十分重要。

实际上明细数据更有助于分析当前的实时状态，查找某个会话当时存在的问题，或者某些会话引发的某个问题。而要了解系统当期的等待事件的总体情况，从而发现系统存在的一些隐藏的很深的问题，往往需要统计数据。这也是DBA往往更容易从AWR报告中看到系统问题的所在，而不是通过v$session的主要原因。

在PG数据库中pg_stat_activity提供了一部分会话等待事件的信息，不过缺少了等待时长。一些基于PG的开业或者国产数据库里，也提供了这个视图，同时还做了一些扩展。

依赖于***的polar_monitor/polar_monitor_reload这两个插件，我们可以获得很多的原生态PG数据库所没有的监控特性。其中最为重要的是，我们能够获得等待事件的等待时长的数据了。等待时长可以为运维分析提供更为准确的信息。这一点我前阵子发的几篇关于***的文章中也做了阐述。Polar_monitor插件为我们带来了数个polar开头的监控视图。其中就有我们锁期待的polar_stat_activity，这个和pg_stat_activity近似的监控接口有着我们需要的新数据。

SQL SERVER从2016（13.x）版本开始提供了一个dm_exec_session_wait_stats视图，这个视图可以提供类似v$session的数据接口。

***实际上提供了十分丰富的等待事件统计信息，通过v$eventmetric，我们可以看到最近1分钟的等待事件统计信息。

在这个系统接口里，我们可以看到每个等待事件在最近一分钟内的等待次数，等待时间，等待的会话数量，以及前台进程的等待次数与总时长数据。这些数据都十分有利于我们去分析某个等待事件在最近一分钟发生的情况。

不过如果我们想了解等待事件在系统中的整体情况，v$eventmetric提供的信息是不够的，我们还需要v$system_event的信息。

v$system_event提供了系统中按照等待事件类别的统计信息，这是一个从数据库启动以来的统计值。如果我们针对这个视图的数据做定期采样，那么就可以掌握系统中等待事件的总体情况。这个采样数据可以用于任意时段的等待事件总体分析。

在***和***中也提供了类似的统计数据接口。***的dbe_perf.wait_events提供了和***类似的统计数据，而且更为详细。

因为***不提供类似***的histogram的信息，因此它提供了最大值，最小值这些统计值。虽然不如提供柱状图那么直观，不过对于等待事件分析来说依然十分有价值。

SQL SERVER也提供了一个类似的统计数据接口dm_os_wait_stats。

可以看出，max_wait_time_ms这个字段也出现在了这里，观察最大值对于分析等待事件来说十分关键。

上面两种统计数据对于等待事件分析来说还不足够，因为我们只掌握了平均值，如果在一个数十万甚至数百万的等待事件中，有几千个是异常的，那么我们无法从平均等待时间发现这几千个数据的异常。而v$event_histogram补上了这个缺陷。

通过柱状图，我们可以了解各种等待时长的等待事件的统计数据，从而发现在某个时段存在某个问题。这个接口也是一个从系统启动来的统计值。不过我们通过LAST_UPDATE_TIME就可以分析出某个柱状图的数据在我们分析的时间段内是否被更新过。因此如果我们没有定时采集这个数据，我们还是能够看出一些端倪的。当然如果能够实现对这个数据的定期采集肯定是有益的。AWR会定期采集这个数据并加以保存，不过其采集粒度过于粗了一点。

有些数据如果要完全保存历史的明细数据是十分困难的，因此往往会采用采样的方式。***针对v$session这个十分重要的数据会做1秒钟为单位的动态采样。将活跃会话的全量采样保存下来，***、***等也做了类似的采样。***在新版本中也将会提供类似的采样。***中，这个采样可以通过v$active_session_history来访问。不过大家要注意的是，既然是采样数据，那么就会遗漏一些的，1秒钟虽然是比较短的采样周期，不过还是会漏掉一些等待事件。不过如果某个问题一直在发生，采样中大概率会抓到这个等待事件。

除了***数据库外，***率先提供了类似ASH的数据接口，***和***也紧随其后。我想今后越来越多的国产数据库也会提供类似的接口。因为这个接口对于分析数据库的问题，特别是性能问题，是十分关键的。

除此之外，历史数据也是我们分析问题最常用的，因为我们经常要分析以前的某个时段数据库存在的问题，而不仅仅是做当前分析。缺乏历史事件积累，我们就无法进行分析了。借助于AWR等成熟的数据采样机制，***提供了多种历史数据的保存机制。我们如果能够加以充分利用，则可以帮助我们解决很多的问题。

与***相比，国产、开业数据库这方面的数据接口还是比较少，我想这也是今后国产数据库会加以改进的地方。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。