想实现数字化诊断分析或者大家喜欢说的智能化诊断其实并不容易，早期的AIOPS从业者总是和客户说他们可以不需要数据库专家就能通过算法实现智能化运维，大概十年过去了，这个梦似乎快破灭了，专家知识依然是智能化运维中的关键。随着大语言模型的兴起，最近我总是听人说生成式AI可以解决以前AIOPS没有实现的一切，真的如此吗?

前几天我说过一个比较复杂的案例，如果用AIOPS来分析难度很大。今天我们通过复盘这个案例来看一看，如果一个故障能够实现全数字化的分析，自动化的诊断需要如何来完成?

DBA朋友大概对于复杂场景故障分析都有些心得，实现方法不外乎大胆推测，细心求证。大胆推测要基于丰富的知识和实践经验;而细心求证则要补全这些推断中间的各个环节，除了需要扎实的基本功之外，还需要利用可采集到的各种数据，包括指标，日志，TRACE等。通过这些已知的数据或者证据来进行推理和分析。

在专家的帮助下，这些分析工作可以根据专家所掌握的技巧与方法进行，但是如果我们想要通过完全自动化的方式来进行分析，该怎么做呢?

实际上专家如果想要完成故障分析，也必须依赖能够支撑完成分析所需要的所有数据或者证据。如果哪一个环节上的数据或者证据缺失，则需要依靠专家的推理能力来补全证据链条，或者根据推断再去补全证据数据。

而如果要实现自动化的诊断分析，则对数据的要求会更高一些。如果中间缺少明显的证据，那么推理可能无法顺利进行，因为算法无法像人一样利用历史经验和在自己脑子中的知识去进行比较跳跃的推理。

首先我们来回顾那个案例，用户在11月1日发现业务系统出现了数分钟的卡顿，导致了生产系统告警。通过AWR报告发现等待事件是library cache相关的 。

对于这个等待事件大家可能都不陌生。MOS上有一篇文章Troubleshooting 'library cache: mutex X' Waits. (Doc ID 1357946.1) 十分详尽地举出了一些引发此类等待的主要场景，大家根据这个文档一般就能够找到问题的根因。

'library cache：mutex X' 的等待类似于早期版本中的库缓存等待。'library cache：mutex X' 可能是由许多问题引起的(包括应用程序问题、SQL缺乏共享导致高版本数等)，但本质上是某些东西持有互斥锁 “太久” 以至于其他会话必须等待资源。如果保护库缓存结构的 latches/mutexs 存在争用，这意味着解析系统存在压力。解析 SQL 需要更长的时间，因为它无法获取所需的资源。这会延迟其他操作，并且通常会减慢系统速度。引发此类等待的 主要原因包括：

• 1)频繁的硬解析 - 如果硬解析的频率非常高，则此引脚上可能会发生争用。

• 2)高版本计数 - 当版本计数变得过多时，需要检查一长串版本，这可能会导致对此事件的争用

• 3)Invalidations (失效) - 失效是衡量缓存的游标因不再有效而从缓存中删除的次数的指标。游标无效，因为某些内容已更改，因此内存中的游标副本不再有效。例如，重新收集有关对象的统计信息或修改表定义足以使基于该对象的查询的游标失效。当游标失效时，任何想要使用该游标的会话都需要等待加载有效版本。如果存在过多或不必要的失效，则可以看到对 'library cache： mutex X' 的大量等待。

• 4)Reloads - Reload 是以前存在于缓存中的游标被搜索、发现不存在(因为它已经过期等)然后必须重新编译并重新加载到库缓存中的次数。很高的RRELOAD是很危险的，因为它们表明您正在执行的工作，如果缓存设置得当，则不必首先删除光标。如果正在重新加载游标，则session无法抓取它以进行工作，这可能导致等待 'library cache： mutex X'。

• 5)已知 Bug

前面两个问题很容易从AWR报告中被排除掉，系统的解析数量很高，不过硬解析不多。第五个问题就比较复杂了，因为已知BUG相当多。第三第四个原因在AWR报告中也是可以看到一些端倪的。

Library Cache Activity章节中我们看到了SQL AREA存在大量的Reload和Invalidations。因此很明确就是大量的CURSOR失效导致了此问题的发生。

第二个问题我们一般可以通过检查解析较高和执行较多的SQL来进行分析定位。在这里我们遇到了一个十分容易引起误导的问题，就是排在前面的SQL执行数量为0，但是解析数量很高，这大概率是应用程序存在BUG导致的，比如有一条SQL写错了，解析失败，因此每次解析后都没有执行。

通过比对以前的AWR报告，客户确认这个问题一直存在，不过以前为什么不出问题呢?这个问题也许很容易用“压垮骆驼的最后一根稻草”来搪塞，不过事实真的如此吗?

根据我对Oracle共享池的理解，很可能是某个DDL操作或者其他什么特殊的操作引发了大量的RELOAD产生。如果负载并无太大变化，那么SGA RESIZE等也可能引发类似问题。

第二个可能干扰本次故障分析的问题产生了，AWR报告中真的看到了存在SGA RESIZE现象。不过幸运的是实例并未重启过，因此我们可以观察SGA RESIZE事件产生的时间，与ASH中的数据进行比对，找出先后顺序，从而排除掉这个可能性。经过分析，我们发现SGA RESIZE滞后于Library Cache发生问题 。因此SGA RESIZE是果不是因。

零点刚过就发生问题，不大可能是与人为操作有关，那么就需要去检查定时任务了。同时需要检查的是10月1号和9月1号是否有类似问题发生。数据库的数据很难找到了，不过业务系统日志还是可供分析的。通过分析，发现每个月1号凌晨都会有类似情况存在，不过时间并不固定，但是有一个特点，都是0点过后的几十秒到一两分钟内。

通过ASH分析发现相关的等待与某张分区表相关，这张分区表是月分区的。而故障发生的 时段与这个分区写入第一条记录的时间完全吻合。那么问题就很清晰了，分区表的段延时分配是引发本故障的主要原因。因为段延时分配导致了相关的Invalidations，从而引发了业务卡顿。如果要避免这些问题 ，那么提前对分区表做空间分配就可以了。

通过上面的分析，大家大致了解了本故障的发生的原因和规避方法了。但是此类问题如何能够通过自动化分析的手段来提前发现或者自动化诊断呢?

首先我们整个分析和预警所需的数据都需要指标化。library cache : mute X的平均等待次数和平均等待事件要作为指标存在在系统中。一旦这些指标出现异常，则立即发起告警。这里首先需要解决一个问题，那就是什么叫“异常”?简单地通过阈值设置超过某个数就是异常是不合适的，因为不同的系统，这个值很难设定好。最好通过AI算法来判别异常。

其次是如果发现了异常，要进行自动分析，如何去发现可能的路径?Oracle的官方文档虽然提供了一些分析路径，但是并不完整，比如说分区表的延时段创建的问题，在此文档中就没有提及，因此这些分析路径还是要依靠专家经验和用户自己的积累。

第三个问题是如何在众多路径中找到 正确的一条，也就是如何排除不可能的路径?这一点要自动化也十分困难，本案例中的执行数为0的SQL问题是很难被自动排除的，依赖于用户对系统的历史的了解，才很快排除掉了。如果想要自动完成，则需要对历史数据进行采集和自动特征提取才行，要实现这一点并不容易。

通过ASH数据我们可以发现产生问题的表是哪一张，也可能发现不了，因为ASH数据里依然有大量的干扰因素。如果我们能够找到哪张表引发了故障，那么我们需要去分析表的元数据。如果找准了某张表，而且我们拥有这个运维经验，那么自动化定位问题也不算太难了。

大家可以看到，要想实现自动化分析，运维经验与数据是关键，而要采集到那么丰富的数据，远不是传统的监控系统能够完成的 ，数据的采集是目标导向的，是基于运维知识的，这样才能够在对系统影响最小的情况下完成所需数据的采集。

在推理的全过程中，完全依靠传统的方法也十分困难，大模型应该是补全推理过程中缺失能力的关键，不过通识大模型不够用，必须有高质量的专业大模型才可以。专业大模型如何训练?其中所需的十分专业的知识，恐怕也只有专家 才能提供。问题又回来了，干技术的活，离开了专家，真的不行。