MOS中上千万BUG报告不是O记的污点,而是它最好的勋章

2024年 6月 4日 20.7k 0

对于用户该不该吐槽国产数据库的问题,是显而易见的。只要是个产品就必然会有缺陷,用户用得不爽了,就必然会吐槽,这是天经地义的事情。

对于数据库厂商而言,有人吐槽不仅不是坏事还是好事。如果一个数据库产品连吐槽的人都没有了,那并不说明它很完美了,而是说明它离死不远了。因为只有真正用这个数据库的人,才会发现其不足,才会去吐槽,只要用户吐槽得有道理,厂商就应该虚心接受。

ORACLE MOS上增长得最快就是BUG报告,这些报告只是用户SR中的精选而不是全部,这说明大量的用户在使用O记的产品的时候踩到了坑,遇到了麻烦。

这些BUG报告并不说明ORACLE数据库不行,反而是证明 Oracle太行了。不仅仅有那么多用户在不同场景中使用Oracle数据库,而且还用得花样百出,因此发现了那么多问题。而Oracle的售后服务部门更牛,居然把那么多BUG给定位出来并解决掉了。所以我说这些BUG报告不是Oracle的污点,反而是Oracle的光荣榜。

国产数据库就特别怕有人知道自己的产品存在BUG或者缺陷。数据库这种复杂度软件系统是成千上万人协同开发出来的,肯定是存在BUG的。没有任何BUG的国产数据库反而显得那么不真实,让人更加不敢相信了。

几年前我写过一篇发现某个数据库出现宕机的问题,通过分析发现不是数据库本身的问题,而是因为操作系统的行为导致误杀了数据库服务进程导致的。

本来这个案例是挺有代表性的,很多用户都遇到过,其中很大一部分用户并未及时定位到这个问题,从而导致频繁发生,这篇文章的分析方法可以供用户参考,我就写了篇文章发了出来。文章被数据库原厂的朋友看到了,就和我私聊说能否把这篇文章撤回,因为怕别有用心的友商用来攻击他们,说他们的数据库会莫名其妙宕机。

原本以为这是孤例,是那个数据库厂商太过于小心谨慎了。没想到今年又遇到了一个类似的事情,某个国产数据库性能突然变慢,利用这个数据库提供的各种性能视图等我终于定位了问题。

当时数据库原厂的朋友觉得这个案例十分典型,想要通过他们自己的公众号转发一下,我也同意了。没想到第二天朋友给我 道歉说:“他们老大不同意发,因为前阵子有个友商拿着一篇他们公众号上发的故障分析的文章去给客户的领导说他们的数据库有问题,自己官网都承认。

这件事造成了很坏的影响,因此领导决定暂停发布类似案例。这篇文章涉及到数据库性能问题,怕被友商再次利用”。

没想到国产数据库市场已经卷到如此地步,连写故障分析案例的文章都会被友商用于商业目的。如果国产数据库市场成为如此的市场,大家都不敢发布类似文章,那么用户通过什么方法去了解数据库故障的分析思路和解决方案呢?数据库就不允许出现个头疼脑热,发烧拉稀的状况,真的能永远健康吗?

这种不太符合科学的事为什么会在国产数据库市场上频频出现呢?连Oracle都有那么多BUG,难道不允许国产数据库存在问题吗?如果是某位甲方领导因为这个原因而选择不采购出现过故障的国产数据库,那么肯定不是这位领导的专业能力不行,也不是描写故障处理案例的文章让用户产生了错觉,而是另有隐情吧。

我觉得只有国产数据库也像Oracle那样,在自己的官网上公布上百万个BUG和补丁,那么我们的国产数据库才算真的成熟了,用户可以放心大胆地去购买了。Oracle上千万的BUG报告,是它最好的勋章。

相关文章

pt-kill工具的使用
pt-ioprofile工具包的使用
数据库管理-第216期 Oracle的高可用-01(20240703)
DBMS_REPAIR EXAMPLE SCRIPT WITH PARTITION
数据库事务的四大特性: ACID 
使用BBED修复损坏的SYSTEM文件头

发布评论