数据库系统是一个十分神奇的系统，我们以前习惯于监控某个指标是否出现了异常。不过单一指标的波动与异常往往很难定位故障或者问题。不同的应用系统中，指标之间的关联度会有很大的差异。如果在类似业务场景，类似的负载情况下，数据库的指标波动与相互影响还是具有一定的相似性的。这也是智能化运维的算法具有一定的普适性应用范围的理论基础。
我们探究指标后面的复杂关系是为了分析问题时能够尽快抓住要点，从而避开错误的路径分叉，直击问题的根源于本质。因此我们对数据库的指标体系理解的越为深刻，分析问题的能力也就越强。在二十多年的Oracle数据库运维工作中，我就是通过不断的理解指标与指标后面的复杂关联关系，再结合Oracle数据库内部原理与基础概念，去不断的提升自己的分析问题的能力的。
接下来我们来看一个例子，这个例子来自于一套负载比较高的Gaussdb数据库系统，这套数据库的配置比较豪华，有6个CN节点，12个DN节点，运行于华为云上，每个CN节点配置了16个CPU核心。Gaussdb的CN是采用负载均衡的模式接受来自应用的负载的，这套应用系统是十分典型的后台交易型业务，大部分业务负载来自于前端过来的流式交易数据。数据库是均匀分区在多个DN上的，应用负载也是较为均匀的分布在多个CN上的。
在一般情况下，这几个CN承载的业务与业务负载十分相近，也不存在特别差的SQL语句。我们选取相同的时间片切面，用“每秒返回行数”这个指标，看看在同一时间切片上，不同的CN节点中，与这个指标具有较为相似的波动特性的指标有哪些。
图片
首先我们来看187节点的情况，有较强关联性的指标是每秒逻辑读、每秒获取行数、活跃会话数（低相似性）这几个指标。
图片
再来看看224节点的情况，也十分类似，关联性最强的是每秒逻辑读和每秒获取行数。
图片
235节点的情况又会如何呢？也差不多，不过每秒获取行数的指标波动更为相近一些。
图片
从上面的数据可以看出，每秒逻辑读与每秒获取行数是关联性最强的两个指标。逻辑读是与返回行数与并发SQL执行量是十分强关联的指标，因此这个指标的波动特性与每秒返回行数的关联系很强，在大多数场景中都可能会出现。
而每秒获取行数指标看上去和每秒返回行数的血缘关系十分相近。不过实际上在不同的应用场景中，二者可能会有较大的差异。每秒获取行数是在扫描表或者访问表时读取的行的数量，而每秒返回行数是每秒返回到客户端的行的数量。这二者在不同的SQL中可能会有较大的差异。比如SELECT COUNT(*)可能统计了1万条数据，但是只返回了1条数据，这样访问数和返回数可能会相差万倍。再比如说我们通过索引找出了一万行数据，再根据SQL中的和索引无关的过滤条件从中筛选出1000条，那么二者会有10倍的差异。从这两个指标的波动关联性强弱可以看出数据库执行的SQL是否发生了变化，亦或是SQL访问的数据或者使用的参数是否发生了变化。一般来说探索这些问题需要很复杂的过程，而通过指标波动关联性的分析就可以比较简单，粗略的获得了。
下面我把时间窗口调整到0点系统做批处理报表的时间段，我们会发现指标波动的规律完全改变了。
图片
白天的业务特点是大量的小型的查询语句并发执行，因此与之关联的指标数量较多，集中度较低。而晚上是少量的批处理作业在执行，因此指标波动的集中度很高，波动相似性也较强，每秒逻辑读与返回行数的关系十分相近。
虽然说某种业务下的某个指标的波动关联性会发生一些变化，不过有些东西是不会变的，那就是指标之间的波动关联性都是与数据库的基本原理有关的。一般情况下不会存在两个完全不相干的指标之间存在较强的波动关联性。
数据库系统中的指标波动特性是存在内在的必然联系的。比如说我们这个例子中的每秒返回行数指标，与每秒获取行数（获取是指从数据库中访问到了，但是并不一定返回客户端了）、每秒逻辑读、每秒物理读、长查询数量等，这些指标之间都是存在较大的关联关系的。活跃会话数虽然与这些指标直接不存在直接的关系，不过是能够标识出数据库的活跃程度的，与之存在稍微弱一点的波动关联性也是解释得过去的。
研究与分析指标之间的关系，有助于理解某个数据库产品的基本特性，有助于在分析问题时抓住隐藏在表面之下的问题。这些年我们对Oracle数据库的研究已经十分深入了，这方面的知识很丰富。不过不幸的是，目前的国产数据库厂家并没有对外公布任何这方面的知识，这对于我们今后运维国产数据库形成了一定的障碍。我想现在肯定有一些从事数据库服务的企业与个人已经开展了这方面的研究，我们也希望数据库厂商除了完善用户文档外，也发布一些这方面的知识，从而丰富国产数据库运维生态中的知识库。我们团队也会通过我的公众号，不断的向外公开一些我们的研究成果。
