国产数据库的AWR差在哪了？

白鳝的洞穴 2025-06-19

528

昨天我发了篇文章，是因为一大早看到有个客户发来让我帮忙分析的一份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记的成长历程，我们应该给国产数据库一些时间来提升这方方面的能力，不过如果国产数据库的研发者不理解数据库运维需要什么，那么再给多少年时间也都是白搭。国产数据库需要完善的地方太多了，运维方面的功能的优先级是不是比较低呢？

大数据数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

文章被以下合辑收录

老白洞见：数据库国产化之旅（共127篇）

本合辑汇集了资深专家徐戟老师（笔名“白鳝的洞穴”）的深刻洞察，深入分析国产数据库在国产化浪潮中的发展机遇与面临的挑战。内容丰富、观点独到，旨在为业界同仁和关注者提供一份全面、深入的指南。

国产数据库的AWR差在哪了？

文章被以下合辑收录

评论