如果不能正常显示,请查看原文 , 或返回

为国产数据库做一个AWR报告很难吗

为国产数据库做一个AWR报告很难吗

白鳝 白鳝的洞穴
收录于话题

Oracle 的DBA都十分喜欢使用AWR来分析数据库的问题,经过了7.3时代的bstat/estat报告,到8.0开始支持的statspack报告,再到10g的AWR报告,12g的Active awr报告,Oracle的AWR功能越来越完善,使用门槛越来越低,大家也越来越喜欢用。

现在搞国产数据库的朋友很多都接触过Oracle,因此他们也很希望自己使用的国产数据库也能用上AWR报告。而我们的国产数据库厂商也在做着这方面的努力。我第一个看到的类似AWR报告的是达梦的AWR报告。

报告的格式有着浓浓的Oracle的味道,刚开始的几节也和Oracle很相近,让我这个Oracle DBA感到很亲切。

第二个看到类似AWR报告的是华为Gaussdb 100的WSR报告,这个数据库虽然现在已经停止商业销售了,不过这个数据库也曾经是我比较期待的国产数据库产品之一。

后来我又看到了瀚高数据库的PDR报告,前阵子Polardb的一个朋友又发来了他们正在做的Polardb负载分析报告的测试版本。

我想国产数据库都希望通过专业的负载分析报告来帮助DBA更好的运维数据库,这个努力绝对是值得肯定的。只有在监控分析能力上,我们能够达到一定的水准,运维国产数据库才会变得更便捷。

不过要做好AWR报告并不简单。目前我们看到的一些类似AWR报告的各种数据库负载分析报告,虽然从形式上和Oracle的AWR报告很类似了,大家已经学到了其行,但是从内容的丰富程度以及对运维可以提供的帮助来看,还差距甚远。甚至在某些AWR报告中,还存在数据不准确的情况,我们根据报告中的内容去做优化分析的时候,发现被报告的内容带偏了。

为什么会这样呢?实际上,不管AWR报告的格式如何相近,内容如何模仿,有一点是模仿不了的,那就是丰富的,准确的基础数据。我们去年也遇到过一些用户,他们对我们的基于健康模型的智能化诊断工具十分感兴趣,不过他们也提出来,自己已经有很多监控数据了,能不能不再使用我们采集的监控指标,直接使用他们的监控数据去做模型和分析。我们分析了他们的数据,发现指标数量、覆盖面、质量、采集周期都存在很大的问题,用这种低质量的数据去做分析是做不出好效果的。

不过客户不这么认为,他们觉得宝马夏利都是车,都能到达目的地,只是舒适程度不同,速度不同而已。于是我们只能硬着头皮做下去,最后的效果可想而知。客户最后的结论是,你们这个工具不行。

AWR报告也是如此,只有有了十分扎实的数据基础,才能做出有很好效果的AWR报告出来。在AWR报告的前身STATSPACK报告还没出来之前,Oracle首先推出了OWI。最初OWI想要实现的目的是让开发人员和维护人员能够了解在Oracle的每个模块和OS中消耗了多少时间,其实最初在7.3版本中推出OWI的最初目的是为Oracle RDBMS的开发人员提供优化代码的工具,后来这个工具逐渐成熟了,才开放为一个运维分析的接口。实际上最初的OWI只有三张视图:v$system_event 、 v$session_event和v$session_wait。这三张视图以及v$sysstat为statspack报告提供了最为基础的数据。后来在10g里面,owi的接口进一步扩容,同时Oracle提供了一系列metric指标:v$metric、v$sysmetric、v$sessmetric、v$iofuncmetric、v$filemetric、v$eventmetric。有了这些基础数据,Oracle AWR报告所需的基础数据都完备了。Statspack报告的超级升级版本AWR报告就应运而生了。而且这个报告成为了Oracle数据库的标准组件,默认启动采集的数据。

从Oracle AWR发展的简单历程上,我们想为国产数据库提供AWR报告功能的朋友可能也能学到一些东西。要想让你的数据库的AWR更为准确,更加有用,必须从底层的数据上先下苦功。获得这些指标数据的最佳途径是在数据库的内核代码中嵌入探针来实现,实际上,目前不少开源数据库和国产数据库都会统计很多等待事件,不过统计这些等待事件的次数很容易,而要统计每次等待的时长却很难,在PG/MYSQL等数据库中,都没有针对具体时间的统计。记得几年前和一个国产数据库厂商交流这方面的问题的时候,他们也觉得十分困惑。如果要统计每次等待的时间,那么数据库的性能会受到很大的影响。实际上Oracle实现较为精确的等待时间也是花了极深的心思的。早期的一些OWI的等待时间是通过resource manager中的CPU周期来估算的。实际上很多统计数据,不需要百分之百的精准,而是有一套统一的计算规则,能够线性的表示其状态好坏就可以了。

所有的功能模块如果都根据公告板上的一个统一的指示器来计算自己的消耗时间,那么这个数据库总的所有操作的等待时间算出来哪怕和现实情况有偏差也不怕,因为如果整体的偏差是一个统一计数器的投影,那么反映出的状态依然没有偏差。

高效、低成本的获取每个功能操作中消耗的时间,是实现ORACLE OWI的关键,对于目前我们想要让数据库的AWR报告变得更为精准,更为有用,实际上首先还是要解决这个问题。先优化好自己数据库的WAIT INTERFACE,让METRIC足够丰富,足够准确,是做好一个AWR的第一步。OWI中需要些什么内容,这个问题其实已经比较简单了,我们的友商Oracle已经给了我们一个十分好的样板了。

赞赏二维码微信扫一扫赞赏作者 赞赏

发送给作者

最多40字,当前共

 

赞赏二维码
返回