最近我们准备把BIC-QA的AWR智能解析的功能推广到国产数据库上，所以近期我和很多国产数据库厂商都做了交流。一圈交流下来，让我感到有些诧异，好像大家对如何使用AWR报告的看法并不一致。

　　Oracle DBA肯定十分熟悉AWR报告，对于Oracle DBA来说，AWR报告最入门的看法就是用来找存在问题的 TOP SQL，不管系统存在什么问题，绝大多数问题都是SQL引起的，解决几条SQL，哪怕不能真正解决问题，也不会让系统变得更差。水平稍微高一点的，除了会看TOP SQL，还能看TOP TIMED EVENT，通过等待事件，再辅以MOS网站，又可以解决一大部分问题。水平再高一点的，可以把TOP EVENT、LOAD PROFILE、命中率、Time Model、等待事件明细等数据综合在一起分析问题，同时还可以利用后面的一些章节的数据来辅助定位问题。

　　不管你阅读AWR的能力如何，总是能够以自己的经验和能力从中找到所需要的数据。并且随着DBA自身能力的提升，就能够从AWR中获得更多的信息。

　　通过我对国产数据库的AWR报告的分析，十分惊讶地发现，他们对AWR报告的态度并不是十分认真的，甚至有些数据库中的AWR报告只是为了有这个功能而已，几乎所有的国产数据库AWR都具备的功能是从中查看TOP SQL这个Oracle最为初级的用途。而除此之外，其他数据就十分鸡肋了。

　　几乎所有的国产数据库产品中都做了等待事件，但是没有一家国产数据库厂商公开公布了每个等待事件到底是什么含义，如果遇到问题，可能遇到了哪方面的问题。当然Oracle的官方文档里也没有对此的定义，不过Oracle通过MOS给出了更有价值的文档。并非是我们的国产数据库厂商不愿意公布这些信息，而是在他们内部根本就没有这个知识库。数据库原厂都没有内部知识库说明了国产数据库厂商的售后人员可能在使用AWR的时候也仅仅把它当成了一个TOP SQL的采集器而已。

　　我看过的国产数据库的AWR报告中，电科金仓的KWR报告是相对质量比较好的，这也是BIC-QA支持的第一种国产数据库我们选择了金仓的主要原因。KWR的Time Model做得还不错，这也让智能解读成为了可能。不过在我和金仓的交流中，他们对等待事件知识也没有做好梳理，形成固化的知识库。研究一个等待事件的时候，他们都需要与研发的同学沟通，才能给出相对准确的答案。没有知识库，那就说明KWR的等待事件并没有在目前KES的售后服务中发挥很大的作用。

　　现在国产数据库应用已经进入深水区了，到明年，大量的核心应用都用上了国产数据库。用户想要用好某种数据库，没有几样趁手的工具是不行的。我说的工具并非某个做数据库服务的厂商自己搞的那种私有使用的工具，而是像AWR这样能够被广泛使用的，大家都看得懂，会使用的工具。国产数据库厂商把AWR报告做好意义重大。

　　可能有朋友会说，为啥非要做AWR报告，国产数据库的内核与Oracle不同，AWR报告对Oracle有用，对国产数据库不一定有用。如果你真的懂AWR报告，那么你可能就不会说这种话了，AWR是数据库可观测性能力的集中体现，国产数据库的内核原理不同，因此国产数据库的AWR报告中的内容可能会不同，甚至某些章节和数据会差异很大，不过这种展现形式是十分友好的。Time Model和Wait Event这种数据模型能够被广大的国产数据库厂商接受，说明国产数据库也并未完全脱离这种框架，构成AWR的主体数据模型在国产数据库中依然是存在的。

　　目前国产数据库厂商没有把AWR做好，最主要的原因是他们还没有搞清楚用户该如何运维他们的数据库产品，AWR报告的数据就是用户日常运维中发现问题，分析问题所必须的，而不是开发人员在办公室里想出来的。AWR报告应该是给用户的运维人员提供帮助的，而不是给他们出试卷的。

　　还有一点我不是特别理解的是，我交流了很多厂商的AWR相关的研发人员，无一例外的是，他们对Oracle的AWR的了解都不深。难道Oracle 的AWR不值得他们去研究吗？也不尽然，我和一个国产数据库大厂的朋友分享了我对AWR的理解后，他们觉得Oracle的AWR考虑得确实很实用，同时他们也发现，大部分Oracle的报告内容他们也可以做。