昨天我发了篇文章，是因为一大早看到有个客户发来让我帮忙分析的一份AWR报告。几分钟看完，就基本上抓住了主要问题。整个过程行云流水，点点深入，用来分析问题十分顺畅。而阅读国产数据库的所谓的“AWR报告”则完全没有这种感受。主要问题是虽然国产数据库的报告也罗列了一些数据，但是好像这些数据都是相互割裂的，不同章节之间的可参考性不强，甚至有很多章节之间的数据都是矛盾的，无法像Oracle AWR一样通过相互印证，相互补充来定位一些深层次的问题。

目前国产数据库的“AWR”报告中 ，只有TOP SQL一节是有点用的，不过依然缺少了类似Oracle的awrsqrpt的详细报告功能，因此TOP SQL用起来也不是很顺手，还需要花费DBA不少时间去额外分析某些SQL。

除了TOP SQL外，其他章节的内容对DBA来说帮助就十分有限了。究其根源，主要是两方面的原因，一方面是国产数据库的可观测性能力面向复杂分析依然不够。这里面的原因有内核本身不够强健，无法在不影响性能的前提下输出一些指标。比如说某基于PG研发的国产数据库，居然连SQL执行总数这样的指标都没有。主要原因是原生态的PG是没有这个指标的，而且PG的SQL是完全在BACKEND中独立执行的，并无共享CURSOR机制，因此统计这样的指标可能会对SQL并发执行性能有所影响，所以不敢设计这样的指标。

另外一方面的原因是国产数据库的产品经理不太懂数据库运维，他们不了解运维人员需要什么样的指标，会用这些指标来干什么。上个月我和一个 国产数据库的核心研发人员交流可观测性指标的事情。他问我一个问题，O记的等待事件直方图有啥用？他说有些售后人员反馈说希望他们能提供等待事件直方图数据，他组织团队分析了一下，认为这个直方图在运维的时候没啥用，因此把优先级往后放了。可能正在看这篇文章的朋友有些用直方图分析过性能问题，有些朋友从来没有使用过awr中这个章节的数据。用过的朋友一定能够理解直方图的作用。有些时候平均值不错不等于系统没有问题，要分析60分钟的AWR统计周期中的1-2分钟或者其他因素的少量抖动，直方图就太有用了。研发人员和产品经理不了解运维人员需要什么，那么也就无法做出运维人员需要的AWR报告了。

第三个方面是因为运维知识的缺乏，我原本以为是因为数据库原厂不愿意开放这些运维知识给大众，也多次和国产数据库厂商索要过这方面的资料。没想到，真实的原因是原厂也没有这方面的资料，甚至原厂的研发和产品经理都没有思考过这方面的问题，他们遇到某个指标异常或者等待事件问题，也还是要依靠trace手段去分析问题，而无法直接形成一系列的分析方案。这些知识需要在大量的用户实践中不断被发现，并且数据库原厂需要投入巨大的资源，找一些专家级的大佬去分析，才能够形成类似O记OS这样的知识库。

其实O记的AWR的成长也不是一天两天的，awr的爷爷是BSTAT/ESTAT，这个工具现在依然存在于Oracle的新版本中，到rdbms/admin目录下还能找到这两个脚本。那时候数据也不丰富，阅读起来也是挺费劲的。后来7.3.4开始有了statspack报告，不过那时候的报告也很垃圾。实际上到了9.2之后的statspack报告的完整性才算上了一个台阶。10g改名为awr报告了，不过实际上10g的awr和statspack报告比起来，也就是换了个名字而已，能力提升并不大。到了11g awr才算是真正成熟了。

基于O记的成长历程，我们应该给国产数据库一些时间来提升这方方面的能力，不过如果国产数据库的研发者不理解数据库运维需要什么，那么再给多少年时间也都是白搭。国产数据库需要完善的地方太多了，运维方面的功能的优先级是不是比较低呢？