对于数据库出现的复杂问题的分析往往是对DBA的严峻考验，哪怕在要求尽可能把问题在应用层面解决号称不怎么需要运维的MySQL数据库上也遇到过spinlock、网络延时不稳定、随机熵等十分棘手的问题。这些问题现在广为人知了，所以可能发现和解决起来也不觉得有多难了，早几年如果你遇到这些问题，还真的不知道该如何去分析。

自从去O以后，使用费Oracle数据库的用户可能觉得大多数问题都出在SQL上，因此让开发人员多优化优化应用就能解决数据库的问题了。今年年初的一个数据库大会上，我看到一个团队做了一个SQL与CPU资源关联分析的监控系统，在系统中计算CPU波动与SQL语句执行次数等指标的关联性，从而找出可能引发CPU问题的SQL语句。回来后，我也让公司的弟兄们做了一个类似的工具放在D-SMART里，不过似乎效果一般。因为在简单的情况下，TOP SQL预警可能更有效，而在复杂的情况下，引发系统问题的不是一条SQL或者甚至不是SQL。

复杂问题往往与SQL并不强相关，而分析SQL相关的问题的方法相对简单。实际上DBA需要掌握更多的分析非SQL引发问题的技巧。因为数据库系统极其复杂，找到分析问题的入口往往是最终定位问题的关键。在以前使用Oracle数据库的时候，因为Oracle强大的可观测性能力以及丰富的诊断工具与接口，让分析十分体系化，也相对简单。

上图是我梳理的Oracle数据库运维中的一些常用问题诊断入口，大部分可以从ALERT LOG、AWR、ASH或者v$session这几个常用工具进行分析。虽然一些复杂问题的分析依然需要较高的技术水平和丰富的经验，不过对于运维专家来说，入口相对是清晰的，十分便于开展问题分析。

再来看看非Oracle数据库，包括国产数据库和开源数据库。除了慢SQL这个问题诊断点比较清晰之外，其他的问题诊断似乎都比较麻烦。其主要原因是“等待事件”的丰富性与指向的准确性都十分不足。就像昨天我发的那个OB优化的例子，系统都出现十分严重的问题了，等待事件上好像看不到任何蛛丝马迹。虽然现在几乎所有的国产数据库都提供类似Oracle AWR报告的诊断报告，但是我看过的几乎所有的国产数据库的类AWR报告后，觉得除了慢SQL外，这分报告几乎没有任何用处。其主要原因有以下几点。

首先，等待事件的水平不足，导致等待事件这种最能体现出数据库当前运行状态的可观测性体系无法发挥作用。其中原因一方面是等待事件的数量不足，统计不准确，指向性也不明确。另外一方面是等待事件的含义十分模糊，DBA根本无从知道某个等待事件意味着什么。实际上Oracle的OWI刚刚开始提供的时候，DBA们也不大喜欢使用AWR的前身statspack报告的。其实二十多年前，我从Oracle 7.3.4开始就在使用statspack报告了，这个从Oracle 8.0才正式提供的功能可以backport到734中。这也让我对于分析Oracle数据库的性能问题上能比别人看到更多的东西。不过当时我给很多DBA推荐过这个工具，大家用了之后并没有觉得这个报告有什么用处，其中最主要的原因是大家对于等待事件和stats的含义并不了解。随着Oracle owi知识的不断推广，大家对这方面的认知也更加清晰了，再加上MOS上大量的NOTES可以提供很好的解释，AWR才变得越来越流行了。目前国产数据库也存在这样的问题，其知识的封闭性让大家无法理解等待事件和系统中的 STATS的含义，从而让他们提供的AWR报告变成了鸡肋。

其次是指标体系不完善，无法准确的反映出系统的性能、负载、故障、异常等情况。指标体系是用于分析数据库复杂问题的关键，如果某些数据库的问题都没有指标可以体现的时候，那么这些指标就无法用于分析了。目前的国产数据库的绝大多数指标都是体现负载的，缺少很多性能相关的指标，这也导致了指标无法在问题定位中发挥较大的作用。

第三是仅仅罗列数据，没有可参考的建议。Oracle的STATSPACK在734和8.0、8i的时候，主要也是罗列数据，和现在国产数据库提供的AWR报告类似。从Oracle 9i开始有了一些建议，到10g/11g其建议也越来越有价值，数据也更加明晰，也变得更加易用了。

少了AWR/ASH这些强大的问题分析入口，我们分析国产数据库的问题，只能首选数据库日志了。在分析昨天的那个OB问题的时候，OB的同学提供的日志分析方法也给了我们一定的帮助，让我们了解到某个MERGE任务是还在进行中的。只不过这些日志要在WDIAG级别才可以使用，在生产环境中我们是希望关闭DIAG级别的日志的。另外一个问题是，在缺乏原厂工程师支持的情况下，我们几乎无法阅读国产数据库提供的十分奇葩的日志信息。错误信息可能会与实际问题相差万里，或者不知所云，而且也没有类似Oracle MOS这样的平台可以查找，这些问题让我们把日志作为分析问题的入口也变得不那么靠谱。在Oracle运维的时代，我给公司的年轻人培训的第一堂课一定是“数据库问题分析，必须从ALERT LOG开始”，这句话恐怕得改改了。

说了半天，可能有朋友着急了：“那么国产数据库遇到复杂问题难道就没有分析手段了吗?”。也不完全如此，昨天我说的perf工具就是一个十分好的分析工具，昨天的那个案例最终也是perf最终帮助定位了问题。如果我刚开始的时候就使用了这个工具，可能问题早就被反推定位了。通过这个案例也给了我一个新的知识，针对一些国产数据库的复杂问题的分析，如果没有找到好的入口，那么一定要先用perf等OS工具去分析一下。“等工具”意味着还有其他一些工具，比如说pstack、top、ntop、netstat等。

使用这些数据库之外的OS工具做分析，对DBA的要求比较高，从一些更加难懂的数据中发现问题，这需要丰富的经验加持才行。因此我们还是希望国产数据库厂商能够在这些方面提升能力。一方面是把数据库自身的可观测性能力做好做强，另外一方面就是尽快构建起类似Oracle Mos能力的知识库。目前虽然已经有一些数据库厂商开始对外提供免费的知识库服务了，其形式也是学习了MOS，不过在知识库的内容上还有太大的差距。这是一个十分花钱也需要时间沉淀的工作，作为国产数据库的用户，是十分希望数据库厂商加大这方面的投入的。