前阵子和一个客户交流数据库智能运维的时候，他说出问题后，把系统中的一些关键指标喂给大模型不就行了，随着模型能力的提升，它会做得越来越好，你们还费劲吧啦地去搞什么运维知识图谱。其实无论是专家分析还是AI分析，第一步都是筛选需要看的数据。

实际上在一个故障发生的时候，数据库可观测性的数据对于所需要分析的 任务而言是太多了而不是太少了。对于一些国产数据库而言，很可能会缺少一些关键的数据(指标、日志等)，但是其指标数据的总量依然不少。如果把这些数据都交给专家去分析，专家会利用自己的经验和知识去过滤掉与本问题毫不相干的数据，然后再去做分析推理。因为不管是数据库系统还是其他It基础设施，亦或是应用系统，往往都会处于亚健康状态，一些与本问题无关的指标和数据可能也会处于异常状态，如果一股脑交给AI，很大概率会增加问题分析的不确定性，降低获得稳定准确结论的几率。

有人说随着大模型的能力提升，这些过滤是不是就不必要了呢?也许是，也许不是，大模型的推理链十分强大，发现隐性联系的能力很强，但是对于运维场景的理解其实是十分不足的，因此比较困难的是排除不可能项。对于与本问题无关的异常，专家可以通过自己的以往经验，凭着经验甚至感觉去做排除，而对于AI来说，难度相当大。因此寻找解决问题的根因，必须将太多的数据做精准的筛选，才更容易准确达成目标。

昨天有个朋友发来一个医院HIS系统的AWR报告，其实那个案例是一个十分典型的，就是因为几条SQL语句缺索引引发的系统变慢的问题。我用我们的BIC-QA分析了一下。

AWR分析发现了两个主要原因，首要问题是TOP SQL引发的逻辑读与执行次数双重压力,另外还发现了一些次要问题，比如RAC GCS，临时表空间访问过于频繁的问题。其实后面的问题都是首要问题的次生问题。

因为数据库是19C，因此本报告中带有ASH数据，BIC-QA能够针对AWR自带的ASH数据进行独立分析(不参考AWR的数据)，对于这种因为SQL性能引发CPU爆掉的问题，其实ASH报告里有更强的指向性，其数据也更为简单，因此使用 ASH这种“简单数据”分析得出的结论比有成千上万指标的AWR报告更加直接和准确：本ASH报告揭示了一个典型的“SQL级CPU过载”场景。解决路径清晰——聚焦TOP 5 SQL的执行计划优化与应用层解析治理，即可在数小时内显著缓解性能压力。

因为没有了复杂的AWR数据的干扰，这回AI分析的指向性十分强，给出的建议也是一针见血，根据这个指示解决问题的思路清晰多了，效率也大大提高了。

从上面的这个案例可以看出，在做数据库AI分析的时候，解决数据过多的问题是十分重要的。我们的解决方案是对故障场景的数据进行初筛，去掉不可能相关的数据，然后把关联性较强的数据送给AI去分析。哪怕是同一个故障场景，多次发生这个场景的时候，AI看到的数据都是不同的，都是与本次故障相关联的，这样AI才能做出更加精准的判断。