前两天发了两篇分析GaussDB WDR报告的文章，实际上几乎所有的国产数据库都推出了类似GaussDB WDR报告的工作负载诊断报告，作为对Oracle的学习与致敬。我读过很多中数据库的AWR报告，在这些报告中我只看到了它们向Oracle虔诚的致敬，看不到太多有用的东西。

不同的数据库产品，其内在实现架构，存储与SQL引擎的设计思想不同，指标与等待事件的含义也相差甚远，Time Model结构更是千差万别，运维诊断的思路更是差之千里。因此哪怕国产数据库想要做AWR报告，那也应该根据自己数据库的自身特点、指标体系、Time Model的组成结构去设计自己的AWR报告的数据内容与报告体结构，而不应该一味地去套用Oracle这个模板。在Oracle数据库上可以反映出问题的数据，在国产数据库上并不一定有用。

拿国产数据库的AWR报告的SUMMARY章节中的等待事件来看，国产数据库也模仿了Oracle的等待事件，但是大多数国产数据库的等待事件并不准确，基于PG开发的数据库的等待事件既不明细，又大多数缺乏等待时长的数据，无法计算平均等待时间(部分国产数据库在此做了增强)，WAIT CLASS划分又过于粗略，等待事件种类也过于粗线条。因此我见到过的绝大多数国产数据库的等待事件过于粗略，也不够准确，其问题指向性与Oracle相比相差甚远，在绝大多数分析场景中基本上没啥用处。但是这并不影响我们的国产数据库把它作为整个报告的核心内容。

事实上，作为与Oracle完全不同的数据库产品，其工作负载、性能等方面的报告的关键数据组成以及问题分析的方法是完全不同的，因此这份报告的结构也应该是完全不同的，是从数据库内部原理出发，利用数据库的关键指标生成出来的分析报告，那么它们之间应该是完全不同的。我感觉这些报告做得有点敷衍了，厂商完全没有在这么重要的一份报告上走心，PG的某些一个人搞出来的 仿Oracle AWR的开源项目也不见得比这些报告做得差。

实际上Oracle的AWR报告也不是一天就长成这样的，而是随着OWI和Time Model的日益成熟逐渐变成这样的。

上图的报告是Oracle AWR报告，甚至是Statspack报告的前身，为了能让朋友们多看到一些内容，我对指标作了删减。当Oracle的Wait Events还不够成熟的时候，Wait Events也不在报告的C位。那时候共享池的性能是决定数据库性能的最为关键的问题，因此这个现在在AWR报告中十分靠后的数据被放在了最优先的位置。这一点十分重要，那就是最重要的数据要放在最显眼的位置上。

作为一份DBA最常用的报告，我们的国产数据库厂商还是应该真正的下点功夫，安排公司里的真正懂数据库内核和运维的高手，从自己的数据库的架构特点，运维要点，性能分析要点入手去独立设计自己的工作负载诊断报告，而不要找份AWR报告，把自己能做的章节抄袭一下就算完工了。