其实一开始我想把今天的话题写成“国产数据库，最想吐槽的”，但是我怕太伤广大国产数据库产品朋友的心，所以把标题改得软一点。近年来，国内数据库的发展非常迅速。在外部需求的拉动下，技术、市场、服务等方面都取得了长足的进步。但遗憾的是，我们的数据库行业并不是从0开始的，眼前还有Oracle这样的巨头。几天前，我参加了一个活动。活动中有一个环节，大家可以讨论国内数据库最值得吐槽的地方。因为是闭门会议，所以没有录音，也没有会议纪要。因此，与会的国内数据库厂商代表、外商、产业界、学术界代表都对国产数据库提出了吐槽。有朋友看到这里可能就知道我今天想说什么了，因为目前国产数据库和Oracle的差距是全方位的，在技术、性能、可靠性等方面都有不小的差距。如果要吐槽，有确实有很多话题要谈。其实单纯的抱怨是没有意义的，无助于我们国内数据库行业的发展，所以今天我就来说说一些大家容易改进，但基本上被忽视的问题。首先是文档。文档是我们的用户可以从国内数据库中获得的最全面、最完整的技术资料。国外的商业数据库在这方面做得很好。国内的数据库文件，我们吐槽的主要有三个方面。一方面，种类太少，内容覆盖不全。很多数据库厂商除了白皮书等小文档外，只有管理手册和开发者指南，其他资料非常少。这些资料虽然涵盖了大部分与数据库产品相关的内容，但很多地方都非常模糊，一般只解释了一个概念，很多实际操作的细节不够全面。实际内容等同于Oracle官方概念和2DAYS系列的内容。事实上，用户要用好数据库，还有很多文档需要进一步完善。深度不够。我说的其实是上面那个问题的问题。因为我没有展开，不仅广度不够，深度肯定也不够。我没有把问题解释的很清楚。通过文档来了解数据库产品，对运维人员没有帮助。第三点不准确完全是我们态度的问题。很多文档中描述的内容不够准确，甚至一些官方文档中的一些命令的参数也和现在的版本不一样。对于Oracle，这称为文档错误。如果这样的bug很多，说明我们数据库厂商对文档的重视程度不高。也有一些数据库厂商手上有很好的文档，但是在任何公共场所都无法获取。我们只能通过一些人际关系线下获取。其实大可不必。能够以非常开放的方式为客户和第三方服务商提供他们所能提供的所有技术信息，对于构建一个良好的国内数据库应用服务生态圈非常重要。与我们的朋友相比，我们在这方面做得还不够。比如Oracle，除了正式的官方文档外，还提供了大量的最佳实践文档，可以在Oracle.com和metalink上找到。此外，Oracle还提供了大量的MAA（MaximumAvailableArchitecture）来实现高可用性。实用文档。对此，IBM也提供了大量的红皮书供客户参考。以下页面是十多年前的数据库产品Oracle11g的官方文档，目的是让用户快速掌握11.2产品的文档列表。这只是11.2这个版本的产品文档的一部分，已经很丰富了：整个文档近400M，尤其是Oracle概念文档，从初学者到高手都能受益匪浅。它可以让OracleDBA们了解Oracle各个组件的技术思想，了解一些监控指标和等待事件的内部原理。我认为国产数据库在技术上可以迅速缩小与Oracle的差距，要实现全面超越还是非常困难的。我们在技术上能做的还是在一些小的领域、小的功能上，尤其是在Oracle里面，和Oracle一起。典型的国内应用场景非常适合弯道超车。但是，与Oracle相比，我们国产的数据库有着全面的差距。在文档等一些环节，我们需要改进的地方很多，可以改进的地方很多。首先，我们能不能学好Oracle，也把自己的数据库的概念也出一个文档，从自己的数据库的架构、原理、功能等技术核心出发，把自己的数据库介绍的很透彻，而不是遮遮掩掩。可能有些厂商担心自己的Concepts出来后，自己公司的核心机密会被泄露，其实大可不必担心。国内数据库厂商的最大标杆——Oracle，每个版本的Concepts都能解释的这么清楚，有什么核心秘密还怕别人看到？第二个我们非常需要国内数据库厂商能够在文档中解释清楚的是参数和监控指标的含义。现在我们遇到一些数据库参数调整，调整后会产生什么样的效果或影响，会影响数据库的哪些行为，有哪些调整建议。在这些方面，很难在官方文档中看到一些蛛丝马迹。很多时候只能通过参数名来猜测，这对国内数据库的稳定运维非常不利。一些监控指标和报错信息的含义也是如此。我们的数据库厂商能否对自己数据库的一些监控指标进行详细的描述，包括这些指标变化的特点，以及与一些主要数据库特性的关系？这个能不能写在文档里面，比如《运维优化手册》更详细的描述怎么样？即使不能对所有指标进行详细描述，是否可以为一些常见的、比较重要的指标提供参考？哪怕只是《Oracle Reference》的程度，也不错。说到文档，我们更羡慕Oracle的Metalink。这个宝库我用了20多年，到现在还经常用。我们国内的数据库是否也可以丰富我们的知识库，或者服务支持网站？事实上，Oracle的Metalink中的大部分信息都来自单个服务请求(SR)。一个典型的服务请求处理完成后，会有专门的团队进行梳理，将具有代表性的服务请求整理成MOS。笔记，发布在Metalink上，所以经过多年的积累，Metalink的内容非常丰富。购买Oracle标准服务器的客户可以得到MOSSR的快速响应，可以在Metalink上找到自己想要的信息，下载补丁。看到一些东西。我们国内的数据库是否也可以借鉴Metalink，建立一个知识库丰富的服务支持网站呢？其实，一方面要做的是快速响应客户的各种服务请求，另一方面要有专人对SR进行梳理，从中提炼出典型知识和典型案例。我觉得只要坚持做下去，两三年后，你和国内合作伙伴在服务水平上的差距就会得到很好的体现，你自己的数据库产品的市场竞争力也会有很大的提升。我们今天讲的文档相关的话题，其实我们国内的数据库厂商都可以做的很好，只是没花多少精力在这上面。其实这件事不是我们厂家不愿意做，而是这方面的人才不够。要想做好这样的事情，必须要有懂自己的数据库，懂朋友的数据库，懂数据库运维、优化等的人才，这个领域没有人有这样的能力。但是不管怎么样，还是希望我们国产的数据库一天比一天好，也希望国内的数据库厂商能够加大在这方面的投入。
