为SQL SERVER准备一只透视眼

目前国内外的运维工具中，SQL SERVER的工具偏少，而且也仅仅偏向于简单的状态监测和一些关键指标基线告警。缺乏深度问题的分析与发现能力，也缺乏复杂问题溯源的能力。因此我们可能知道某个指标异常了，但是不知道为什么异常，是什么引发的异常，我们该如何去优化它。微软虽然提供了一些诊断分析工具，不过这些工具用起来太复杂了，一般人也真的不太容易掌握。再加上Windows的问题本身就比较难以分析，这导致了SQL SERVER这个看似用起来很简单的数据库，反而不那么好分析了。

微软提供了一些基于Windows平台的分析工具，不过大多数是交互式分析工具，问题发生时进行在线分析的能力虽然较强，但是使用起来专业性太强，另外也无法分析历史情况，因此无法满足运维优化的全面需求。

基于此原因，DBAIOPS社区对SQL SERVER的需求还是挺旺盛的，很多朋友都认为D-SMART中SQL SERVER的监控功能和诊断功能必然Oracle等其他数据库弱很多，希望我们在今后的版本中能够加强。经过这段时间的社区推广，我们发现确实在政务、医疗文教、制造业等行业，SQL SERVER的使用量是相当高的，为了这些客户，我们有必要对D-SMART的SQL SERVER做一些加强。

前阵子社区的一个朋友通过Hola发来一个SQL SERVER的监控数据，让我们帮助分析一下SQL语句经常出现执行时间抖动的问题。从月检报告上，我们发现了数据库存在IO_COMPLETION指标的异常。当时基于SQL SERVER的知识图谱并不完整，因此分析过程完全通过人工，我们花了数个小时，发现了一个疑点，SQL语句执行时间变长总是和物理内存100%，PAGEFILE使用率接近100%有关，最终定位了问题主因是物理内存不足。

如果利用智能诊断工具，我们是可以大大简化分析的过程的，有了完整的知识图谱，我们就可以使用各种智能诊断工具来辅助我们发现问题了。比如上面所说的问题完全可以通过“指标关联性分析”工具进行分析，比如我们发现数据库的闩锁等待有点不正常，从“指标关联度分析”的结论上看，这个指标相关联的问题主要几种在IO并发量过大上，而最终定位的问题是操作系统IO延时过大，IO能力不足引发了IO性能问题。整个分析只需要点击下按钮，是不是很简单？

在D-SMART V2.1.6.20221010月度升级版中，我们着重加强了SQL SERVER的监控与运维诊断能力。针对SQL SERVER的指标做了一定的增强，增加了一些对于分析诊断十分有价值的新指标。另外健康模型也做了较大的调整，新的模型能够更好的反映出SQL SERVER数据库实例的运行状态。而最大的升级来自于SQL SERVER的知识图谱在这个版本中已经完成了对所有指标的覆盖，因此这个版本的“智能诊断”功能真正可以发挥作用了。

点击智能指标分析，D-SMART的智能诊断引擎可以根据知识图谱的数据自动对当前的问题进行归类和分析。

当我们发现某个关键指标出现异常时，我们也可以十分方便的利用智能诊断工具中的“关联度分析”工具，去分析可能的关联因素。

选取指标存在问题的时间段，点击“智能指标分析”，就可以选择其中的工具进行分析了。当我们对某个单一指标异常没有头绪，不知道该如何分析的时候，使用“指标关联度分析”工具就可以去发现与该指标的波动特征较为相似的指标，这些指标很可能与这个你不知道该如何分析的指标有关联关系的指标。

相似因子越小的指标可能关联度越强。智能诊断工具还可以通过根因分析算法，自动归纳引发指标波动的可能问题。

不过这个问题是通过关联关系推断的，而并不是系统当前可能存在的问题。在报告的后面，会提供这个分析。

随后的问题分析工具会自动分析这些关联性的指标中存在的异常，从而推导可能存在的系统问题，最终原因还是IO能力不足，而诱因可能是大量的SQL加大了IO。智能诊断工具采用纯数学计算的方式来分析问题，不过其分析的规则来自于知识图谱中的专家经验。智能诊断充分利用已有的专家知识，结合异常检测算法，自动对指标进行检测，并且通过知识图谱中积累的模型，自动进行根因归类，将一系列指标异常收敛到有限的问题点上。这样就好像给我们的DBA装上了一只透视眼一样，能够比较方便的看透问题现象背后的本质。

当然，目前的智能诊断仅仅是为我们提供了一双透视眼，让我们能够更好的看数据，帮我们自动分析数据，其大脑目前还不够聪明，分析的最后一公里依然需要依靠人的判断，不过已经为我们的运维人员，特别是三线专家提供了很好的分析方向。

随着不断积累新的故障模型，优化知识体系，分析诊断的能力也会不断的提升。随后我们会在DBAIOPS社区开展SQL SERVER的智能诊断测试工作，也希望有兴趣的朋友参与测试，并给我们反馈测试结果，用于改善知识库。