​其实刚开始我今天的题目想写为“国产数据库，最想吐槽的问题”，不过怕太伤了广大搞国产数据库产品的朋友的心，于是，把题目改的柔和一点。这些年国产数据库的发展十分迅猛，在外部需求的推动下，技术、市场、服务等各方面都取得了较大的提升。不过不幸的是，我们的数据库产业不是从0起步，前面还有Oracle这样的巨头在给我们打着样子。

(资料图)

前几天参加了一个活动，活动中有个环节，大家可以针对国产数据库最值得吐槽的地方展开讨论，因为是闭门会议，不录象不写会议纪要，因此参会的国产数据库厂商代表、国外友商代表、产业界、学术界的代表都对国产数据库进行了一番吐槽。可能有朋友看到这里就知道我今天想要说些什么了，因为目前国产数据库和Oracle的差距是全方位的，在技术上、性能上、可靠性等方面都存在不小的差距，想要吐槽，确实有很多话题可以讲。其实纯粹的吐槽没有意义，也无法帮助我们的国产数据库产业发展，所以今天我还是聊几点大家很容易改进，但是被大大忽视的问题吧。

首先是文档，文档是我们的用户能够获得的国产数据库最为全面和完善的技术资料，国外商用数据库在这方面做的很好。

我们吐槽的国产数据库的文档主要有三个方面，一方面是种类太少，内容覆盖不全。很多数据库厂商对外资料，除了白皮书等小文档外，只有一份管理手册，一份开发人员指南，其他的资料就很少了。这些资料里面虽然覆盖了绝大多数的和数据库产品相关的内容，但是很多地方写的都十分模糊，大体上只是交代了一个概念，很多实际操作部分的细节都不够全面。实际内容和Oracle官方的concept以及2 DAYS系列的内容相当。实际上，如果要让用户把数据库用好，很多文档都需要进一步展开。

深度不够，说的和上面的问题其实是一个问题，因为没有展开说，所以不仅广度不够，深度肯定也不够，没有把问题说的很清楚很明晰，因此对运维中遇到的问题，以及运维人员通过文档理解数据库产品都帮助不大。

第三点不准确就完全是我们的态度问题了，很多文档里描述的内容不够准确，甚至有些官方文档里某些命令的参数都和当前版本存在差距。这种对于Oracle来说， 被成为文档bug，这种BUG如果多了，就说明我们的数据库厂商对文档不是很重视了。

还有些数据库厂商手头是有不错的文档的，但是在任何公开的场合都拿不到，我们只能通过一些私人关系，从线下获得。实际上也大可不必，能够十分开放的把自己能提供的技术资料都提供给客户以及第三方服务厂商，对于建设一个良好的国产数据库应用服务生态十分关键。

和我们的友商，相比，在这方面我们做的确实还很不够。比如Oracle，除了正式的官方文档外，还提供了大量的最佳实践文档，这些文档在Oracle.com和metalink上都可以找到，此外Oracle还针对高可用提供了大量的MAA（最大可用架构）的实践性的文档。这方面，IBM也提供了大量的redbook，供客户参考。下面几页是Oracle11g这个十多年前的数据库产品的官方文档中为了让用户快速掌握11.2产品的文档清单,这仅仅是11.2这个版本产品文档中的一部分，就已经如此丰富了：

整个文档近400M，特别是Oracle Concepts这份文档，可以让从初学者到大师都受益匪浅。可以让Oracle DBA们理解Oracle的每个组件的技术思想，理解一些监控指标和等待事件的内在原理。

我想，国产数据库在技术上很快缩短与Oracle的差距，实现全面超越还是很困难的，我们在技术等方面目前能够做的跟多的还是在某些小领域、小功能上，特别是在和国内典型应用场景紧密适配上的弯道超车。不过我们的国产数据库和Oracle相比，其差距是全面的，在文档这样的一些环节上，我们要提升的地方，我们可以提升的地方就十分多。

首先是，我们能不能学习Oracle，也出一份自己数据库的concepts的文档，能从自己数据库的架构、原理、功能的技术核心说起，把自己的数据库介绍透，而不要遮遮掩掩的。可能有些厂家怕自己的Concepts出来后会泄露自己企业的核心机密，其实大家也大可不必担心。国产数据库厂商最大的对标对象-Oracle都可以把每一个版本的Concepts讲的如此清晰，我们还有啥核心机密怕别人看到呢？

第二个我们十分需要国产数据库厂商能够在文档中讲清楚的是参数和监控指标的含义。现在我们遇到一些数据库参数的调整，调整后会产生什么样的效果或影响，会对数据库的哪些行为产生影响，调整的建议是什么，这些方面，在官方的文档中很难看到一些蛛丝马迹，很多时候只能通过参数名称来进行猜测，这对于国产数据库的稳定运行与运维，是十分不利的。

对于一些监控指标、出错信息的含义也是如此。我们的数据库厂家能不能针对自己的数据库的一些监控指标走出详细的描述，包括这些指标的变化特点，以及和一些主要的数据库特性之间的关系，这方面能不能在《运维优化手册》这样的文档中做出较为详细的描述呢？哪怕我们无法对所有的指标都做出很详细的描述，那么能不能针对一些常见的，较为重要的指标，提供一份参考呢？哪怕只是做到《Oracle Reference》这样的程度也是好的。

谈到文档，我们更羡慕Oracle的Metalink，这个宝库我已经使用了20多年了，至今还经常会用到。我们的国产数据库能不能也丰富一下我们的知识库，或者说服务支持网站呢？实际上Oracle的Metalink中的大多数资料都来自于一个个的服务请求（SR），一个典型的服务请求处理完之后，就有专门的团队复杂整理，把有代表性的服务请求整理成MOS的Notes，发布在Metalink上，这样经过多年的积累，Metalink的内容就十分丰富了。客户买Oracle的标服，能够获得MOS的SR的快速响应，能够在Metalink上查找自己想要的资料、下载补丁，虽然花钱renew的时候有点心疼，不过总的来说，花了钱还是能见到东西的。

我们的国产数据库是不是也能够学习Metalink，建设一个带有丰富知识库的服务支持网站呢？其实要做的事情一方面是快速响应客户的各种服务请求，另外一方面是有专门的人员来整理SR，从中抽象出典型的知识和典型的案例。我想只要坚持做下去，有两三年时间，你们和国内友商之间的服务水平的差距就能很好的体现出来了，自己的数据库产品的市场竞争力也会大幅提高了。

今天谈的这个和文档相关的话题，实际上是我们的国产数据库厂商完全能够做好，但是并没有花精力区做的事情。这个事情实际上也不是我们的厂商不愿意去做，而是缺乏这方面的人才。要想做好这样的事情，必须是有懂自己的数据库，懂友商的数据库，懂数据库运维、优化等方面的人才参与进来才能做好的，而恐怕在我们的国产数据库厂商中，做这方面的人都不具备这样的能力。不过不管怎样，我们希望我们的国产数据库一天天好起来，也希望有国产数据库厂商能够在这方面加大投入。​

关键词： 服务请求 只能通过 大可不必 技术资料