这是一个去年的案例，正值疫情期间，我刚刚从机场出来，因为48小时核酸的问题，我被迫从上海绕道去南京。飞机落地后打开手机就看到一个网友给我在微信上的留言，是一个客户的系统有点问题。
客户那边反馈是系统有点慢，维保服务厂商搞不定找到他了。他上去看了看，发现除了活跃会话数多了一些，和平时差别并不大，做了AWR报告才发现似乎系统的IO有问题，因为log file parallel write和db file parallel write都比较差，不过db file sequential read等读IO的指标好像还是正常的。从发来的AWR的ADDM信息看，似乎也抓不到什么有用的信息。
19C的自动诊断也发现了活跃会话数的问题，不过定位的结论不是很准确，发现了提交与回滚较多，SGA配置问题，会话存在短链接以及因为invaliation导致的硬解析比较多这几个问题。
很多经验不足的DBA往往会根据数据库ADDM等自动诊断的结论去分析问题，而一个稍微有些经验的DBA很容易从下面的Load profile中的信息就把这些问题排除掉了。
因为每秒12.2个提交，0.1个rollback,1300+的执行，5.1的硬解析，无论如何都是谈不上多的，甚至每秒31M+的读写IO，也算不得大IO。ADDM的智能化诊断实际上只是针对time model的一个解读，从中找出TOP n的因素而已，对于实际问题的定位往往是不准确的。
不过这个案例并不复杂，在飞机滑行的这几分钟里，我已经初步定位了问题。虽然在廊桥那里耽搁了几分钟，十几分钟后，坐上网约车后，我就给和朋友通了电话，把我的分析结果告诉了他。
我的初步判断是，如果客户存在存储同步复制，那么问题应该出在同步复制的链路上了，应该是有一条复制链路不稳定，导致写IO延时很大，而读IO因为不涉及远程复制链路的问题，因此没有受到影响。
实际上此类问题如果你以前遇到过，那么还是很快会找到诊断方向的，如果你没有遇到过，就比较难于定位问题了。因为对于此类问题有较丰富的经验，因此我可以在几分钟内就完成问题的定位。这个经验不仅仅是读IO是好的，写IO是不好的这么简单。
从TOP 10 前台等待事件上看，日志同步，直接路径写，BBW，cursor: pin S wait on X等的等待事件平均延时都很高，而以往常见的db file sequential read等都已经在TOP 10里消失了。这还不足以定位为存储存在问题。在如此小的负载下出现此类问题，还有好几种可能性，比如最为典型的numa导致的问题，没有使用hugepage导致的问题，共享池导致的问题等，都可能出现类似的现象。因此需要首先排除掉这样的问题，才能做出较为准确的定位。
这种分析对于遇到过此类问题的专家来说十分简单，而对于没有遇到过问题的人来说，可能会一筹莫展，主要原因是里面涉及了十分复杂的逻辑。
我们首先要通过user_time和sys_time的比例关系等OS层面的情况来排除NUMA以及HUGEPAGE引起的问题。其次要通过详细的前台进程等待事件中关于共享池的事件的平均等待延时来排除共享池导致的问题。
这个排除工作相对会比较麻烦，因为IO延时的异常反过来也会影响共享池的相关指标，需要多看几个，综合来考虑才能做出正确的判断。
从柱状图中，我们可以看出db file parallel write的大多数IO都小于2ms，不过还是有3.3%的IO是异常的，而且是大于32毫秒的。
再仔细看一下就会发现，这3.3%的IO都是大于4秒钟延时的，如果分析到这里，存储复制链路存在抖动的结论成立的可能性就超过8成了。正是因为这个原因，我才能在几分钟内做出那个判断。和朋友通过电话40分钟后，这个判断被确认了。
似乎大家看完这个案例觉得并不复杂，只要有过这样的经验，下回就能够分析这个问题了。确实是的，遇到过类似问题的DBA下回你遇到这个问题的时候就多了一条诊断路径，这就是运维经验的积累。做到这一点还不够，因为对于水平高的DBA，看了我今天的文章后，下回遇到类似问题就可以进行分析了。而对于大多数人来说，下回遇到此类问题也不一定就能处理的好。这种运维经验需要固化下来，形成自动化诊断分析的模型，才能更好的积累。
说实在的，这类十分复杂的问题，使用深度学习构建模型是最好的，因为这上千个指标里面的复杂的关系，可能专家也不一定都能够总结和分析的清楚。不过理论上的最好实际上不一定能够实现。此类问题，我最近的5/6年里也不过遇到过四五次，没有足够的样本，深度学习也好，人工智能也好，都无法构建出模型出来。
此类小概率发生的问题的知识积累还有另外一种方法，那就是依靠专家根据有限的样本去进行抽象分析，构建出知识图谱，并通过知识图谱来勾画出一个故障模型了。
如果我们对数据库的内部原理有了充分的了解后，这种抽象就变得可行了。虽然抽象出来的故障模型的精确性可能还无法一下子达到很高的水准，不过一个故障模型刚刚开始构建的时候达到70-80%的准确性还是可以达到的，随着在实际生产环境中的磨合，通过调参或者添加关系等方式，还可以进一步优化模型。
这个故障模型的简图，有兴趣的朋友可以研究研究，这些因素是不是能够定义这个故障了。这些分析，人脑去分析，也就几分钟就可以完成的。而要让这个模型变成自动化模型，还是需要继续花点心思的。
在企业的运维自动化系统中，如果能够把梳理抽象的结果变成自动化发现的模型，那么下回类似问题出现的时候，哪怕分析过此类问题的专家不在现场，稍微有点经验的DBA也能够很快发现问题，并根据系统的提示正确地进行问题分析了。这种故障模型或者运维经验的积累，可以让运维知识真正成为企业IT部门的核心资产。
