大语言模型与数据库故障诊断

​上周五客户那边出现了一个很奇怪的故障，刚开始我们以为很简单，一个用户环境的Oracle 11g数据库报了一个ORA-4030错误，对于DBA来说，这个错误太常见了，马上联想到物理内存不足了。

不过D-SMART的监控并未产生物理内存不足的告警，从监控指标上看，也没有出现物理内存突然下降的时点。

D-SMART的诊断工具中也没有发现任何物理内存不足的情况，从ULIMIT上看也没有看到任何异常，和内存相关的限制都是unlimited。当时有点一头雾水的感觉，这肯定是一个我们以前比较少遇到的场景，并且在我们的运维知识图谱中并没有收录这个故障模型。

于是我们再次研究了错误信息，发现OS报错的errno和普通的系统物理内存耗尽导致的ORA-4030不同，而是errno=12，无法mmap进程内存。随后通过分析发现这是因为vm.max_map_count参数不足，导致进程的内存映射表溢出而无法分配进程内存，并不是OS真的没有内存可分配了。

这个数据库的硬件配置很高，物理内存有1.5TB，SGA就分配了1TB，所以在这种环境下，默认的CENTOS的max_map_count（65530）不够用了。实际上在一些Oracle官方文档上对于这个参数也有建议，在物理内存较大的环境下，至少应该设置为20万以上，Oracle 12C的典型设置为262144。

周六早上没事的时候，我又想起了这个案例，想和CHATGPT聊聊这件事。活见鬼了，CHATGPT秒回的处置方案与我们折腾了小半天得到的居然是完全相同的。从这个案例中我又想到了如果经过训练，让CHATGPT来帮助我们分析日志是否可行呢。于是我找了一个以前的ora-01555报错的案例输入CHATGPT来分析。

这个回答中规中矩，不算太出彩，不过也大体上没问题，大多数DBA对于ORA-01555的认知也差不多如此。

我输入了另外一条SQL，这里有一个小变化，Query Duratinotallow=0,这种ORA-01555错误是另外一个原因导致的，并不是UNDO RETENTION不足，不过CHATGPT的回答还是老一套，并没有能够区分出这个小小的不同。

于是我把相关的BUG报告输入，继续训练CHATGPT，训练完成之后，再来问这个问题。可以看出，CHATGPT已经能够发现Query Duration的问题了，看样子我刚才的训练是有效的。当然回答并不完美，这和我刚才的训练比较简单有关。

通过这几个案例，我们也看出了大语言模型在运维上的一个前景，那就是只要有足够的并且相对准确的语料训练，大语言模型可以在智能运维中发挥很大的作用。起码在日志分析方面，目前CHATGPT在基础能力上已经相当不错了。下面我们再来看几个例子，这些例子输入之前，我并没有做针对性的语料训练，完全是依靠CHATGPT原有的模型完成的。

我想一个不是很资深的DBA很可能都没法回答的如此到位，这个回答虽然达不到专家的水平，已经远超出一般的高级DBA了。

这个对Oracle State object数据的解读也十分到位，通过代码要解析这样的数据还是需要花点时间的。

我们再来看一些稍微复杂一些的，这段reconfiguration的解释也十分到位了，虽然从回答上看还没有包含太多的Oracle RAC的内部原理，不过对日志的解读已经十分细致了。如果我们用一些关于reconfiguration的内部实现的技术资料来训练一下，我想分析的会更为深入。

周日晚上我和几个搞智能化运维算法的朋友交流了一下这个问题，他们都觉得这个方向值得研究。裴丹老师认为粗略而言，模型都是概率，包括条件概率；只要答案相对确定，模型就会获得大概率，回答就会相对靠谱。否则不行。这是从算法层面对这个问题的比较准确的总结，答案的唯一性越高，回答的准确性就会越高。

对于日志智能分析来说，有上述的保证已经是足够了，如果我们能收集到大量的案例，提高训练的语料质量也有助于提高模型的准确性。从这个方面来看，利用预训练的大语言模型来做智能运维中的日志分析，应该是完全可行的。这给我们做智能化日志分析提供了一个新的路线图。

不过要完成这个工作也并不简单，首先需要用正确的知识去做训练，其次需要大量的训练，从而确保从概率上，正确的回答会占据优势。在现实工作中，要实现这两点都需要大量的成本。从目前CHATGPT的回答看，它学习的都是大量的常规知识，所以对一般性的问题的回答中规中矩。其水平无法替代一个高级DBA，更无法替代专家了。因为这些训练中缺乏专家所拥有的在常规知识基础上的细节和深度知识，要想让CHATGPT具有专家的能力，必须要让专家来训练它，或者利用大量已知的专项知识点来训练它。比如把Oracle Mos的大量note和bug报告输入训练。因为训练所需要的素材（包括经验、知识、案例、BUG报告等）十分庞大，因此这项工作仅仅依靠某个团队或者某个企业是很难完成的，必须通过社区化的运作才更容易成功。

第二个方面是知识的准确性问题，如果大量的错误的知识被用来训练，那么基于概率，错误的答案会将正确的模型驱逐出答案中。而判断知识的正确性是个十分困难的问题，对于同一个问题，甚至不同的专家都会有歧义。因此模型的训练必须有大量的专家参与。

今天我仅仅看到了大语言模型用于数据库故障诊断，日志分析，系统优化等方面的一种可能性，而并没有找到真正实现它的路径。要想实现它，除了技术，更重要的是资本的参与。不过既然可行，那么总有一天，我们能看到它。​