今天继续介绍GaussDB的WDR报告，我们今天分析一下CN/DN节点的报告。昨天分析集群报告的时候发现集群报告里缺乏一些DBA分析问题所需要的数据，今天我们来看看是否在节点的报告里能够找到它们。GaussDB的节点报告格式都差不多，只不过CN/DN节点的功能有所不同，CN节点主要负责会话接入、SQL解析、数据汇总等工作，而DN节点负责执行计划子任务的执行和表数据的管理，因此报告中的数据会差别较大。
Summary中的实例命中率依然只有buffer hit这个对于GaussDB·来说并不是特别需要关注的命中率指标。随后是Top 10 Events，等待事件。等待事件是Oracle DBA习惯用来分析问题的常用工具。虽然GaussDB的等待事件种类没有Oracle上千种那么多，不过400多种等待事件在国产数据库中也算是比较丰富了。特别值得注意的是GaussDB的等待事件统计信息比较完备，不需要像一些开源或者国产数据库一样，只能通过会话信息的瞬间值来采集等待事件。因此WDR中的等待事件的参考价值就比较大。
对于GaussDB的等待事件，目前DBA比较困惑的是如何进行解读，不像Oracle已经在MOS上对各种等待事件提供了十分丰富的知识库，GaussDB的等待事件相关的知识十分欠缺。
为此，我们在D-SMART中针对GaussDB的等待事件构建了一个知识图谱，利用知识图谱对等待事件情况进行分析。
是不是看着这个分析内容就舒服多了。对于Oracle的等待事件，因为MOS丰富的知识库的存在，DBA可以很方便地从中找到相关的资料，从而继续自己的问题分析，找到答案。哪怕找不到答案，也可以通过开SR的方法获得Oracle的线上售后服务支持，从而完成分析。目前GaussDB还没有构建起完善的知识库体系和线上服务体系，因此仅仅列出等待事件对DBA的帮助不大，因为大部分DBA看不懂这些东西，甚至可能GaussDB的原厂工程师都很难解读这些数据。在报告里如果能够增加一些等待事件说明甚至自动生成一些分析结论，会对DBA更有价值。
紧跟在后面的是Wait Classes，GaussDB的Wait Classes是PG Wait Classes的延续，分类太少导致这些指标的指向性不足，很少有DBA能从GaussDB的Wait Classes中发现问题。其实Oracle的Wait Classes的分类也不算特别出色，不过比起GaussDB还是要好不少，起码能够对IO，负载，并发，CPU等有个起码的分类。
后面的几项，Host CPU中规中矩，IO PROFILE参考价值有限，内存情况也很粗略，不过这属于summary信息，可能有价值的信息在后面。
详情中的Time Model是个亮点，在国产数据库的AWR报告中，我也经常会看到Time Model的内容，这是从Oracle学习来的一个反映数据库负载与性能特征的特征数据集。可能很多DBA不太关注这些数据，不过在Oracle开始提供Time Model后，我就开始关注它了。虽然对于不同的数据库，Time Model差别很大，甚至同一个数据库在不同的负载下Time Model也截然不同，但是Time Model是可以反映出数据库系统的负载与性能情况的十分好的指标集。利用智能化分析的算法处理Time Model会有很好的效果。不过Time Model的数据只有十分准确才有使用价值，很多数据库虽然有Time Model，但是数据不准确，那就只是一个样子货。
CN节点的TOP SQL和Cache IO Stats、Object Stats等章节和集群类似，这里就不多说了。等待事件详情也算是中规中矩吧，缺点是没有计算百分比，看上去不够直观。优点是有最大等待时长的字段。只不过不大了解这个最大等待时长是在报告期间的还是数据库启动以来的。从我对基础指标数据的理解，这个值应该是数据库启动以来的。
最后是参数设置，这个参数设置的显示章节可读性一般，因为GaussDB参数数量太多了，如果把重要参数、非默认参数，以及在报告期间有过变化的参数分别列一个列表，那么易读性就好多了。
看完了三份WDR报告，可以看出与O记的AWR报告相比，WDR报告还缺失很多内容。1）ADDM和ASH分析，实际上GaussDB有类似Oracle ASH的ASP数据，因此ASH分析实现起来并不困难。GaussDB也有Time Model，因此做ADDM报告难度也并不大，这两个内容完全可以提供出来；2）CHECKPOINT详情；3）共享内存详细分析；4）锁/分布式事务分析；5）LWLOCK性能分析。
前面大家可能跟着我大致了解了GaussDB WDR报告的大致情况。作为一个看过数千份甚至更多AWR报告的老DBA，对WDR报告的评价是有用，但是不好用，或者说用途有限。对于了解GaussDB的DBA来说，等待事件、指标数据、TOP SQL等可以为他们提供一些有价值的数据，用于问题分析。但是GaussDB的WDR报告和其他几乎所有的国产数据库的“AWR报告”一样，仅仅是对Oracle AWR的模仿，而并非真正能够帮助DBA诊断疑难杂症的好工具。我想WDR报告的产品经理恐怕也无法使用这份报告远程帮用户定位复杂的性能问题或者定位BUG吧。
其实现在大家能够很好地利用Oracle AWR报告分析问题一方面是Oracle的AWR报告做得越来越好，在每个版本出来的时候，易读性都有大幅提升。另外一方面是MOS网站的存在让分析AWR报告变得更加方便。而国产数据库的“AWR报告”在内容上大多数仅仅达到了Oracle 8I的水平，甚至数据的详细程度还大不到Oracle 8i STATSPACK报告水平，又缺乏MOS这样的知识库可供搜索，那么这些报告的作用就十分有限了。
另外一个方面，国产数据库，特别是分布式数据库，在架构上和技术路线上都有巨大的不同，因此O记“AWR报告”并不一定是好的模仿对象。国产数据库的AWR报告照抄O记并不一定是个好的路数。分布式数据库在集群健康状态、集群稳定性、网络稳定性、选主决策健康度、集群节点负载均衡性等方面都需要认真关注，这些内容都是Oracle AWR报告中看不到的。
以今天分析的GaussDB为例，要想让WDR报告能够给DBA帮助，那么还是要从GaussDB的运维角度出发来设计WDR报告的内容。GaussDB在各种运行负载中会有哪些需要关注的指标和统计数据？GaussDB的一些典型故障场景中会有哪些典型的表现？GaussDB DBA关注哪些指标数据？GaussDB DBA能够利用GaussDB的可观测性能力分析哪方面的数据库问题？那么我们就应该提供这些数据给他们。如果WDR报告这么去设计，才真正会对DBA有价值。
最后一点，因为国产数据库还没有建立起Oracle MOS这样的知识库，因此在自己的AWR报告中能够对一些等待事件、指标做一一些标注，让阅读报告的人哪怕没有看过数据库的官方文档也能够很快理解某些异常的指标和等待事件，这种报告就更易读了。在你没有MOS这样的知识库之前，别和我说Oracle的AWR报告里也不提供这些内容。
