自治数据库是我们这代DBA二十多年前就开始的一个梦，现在O记离我们那个梦想越来越近了，其实哪怕没有自治数据库技术的加持，O记的运维也越来越便捷，让人放心。为了提升客户使用体验，很多国产数据库也在学O记的经验，模仿出了国产版的AWR/ASH/ADDM，也在做自治数据库相关的组件。我使用过很多国产数据库的这方面的工具，总觉得学得还不太到位。

我运维过从ORACLE 5.1到19C的多个数据库版本，深深感受到O记这些年在运维便捷性上的巨大提升。从早期的黑盒子到6.x之后可以通过各种命中率来分析和优化数据库应用的性能;7.3的utlbstat/utlestat工具终于让我看到了数据库内部的一些详细数据;后来有了Oracle 8的statspack报告，DBA终于不用在黑暗中摸索了;Oracle 10g的AWR/ASH和ADDM则开创了深度分析平民化的道路，哪怕不太懂Oracle OWI和Time Model 的DBA也能快速从中找到一些有用的数据。

运维ORACLE数据库的时候，哪怕没有自治技术加持，有了强大的OWI，METRIC，Time Model 等数据和工具，加上MOS网站(Metalink)的加持，总是会让人很放心。因为只要问题可再现，发现根因只是时间问题，实在不行开个SR就OK了。

国产数据库虽然也在学着O记做类似的事情，但是效果往往不佳。虽然各个厂商都号称自己的可观测性能力以及自制数据库的能力都强大无比，但是在实际的用户场景中却很难看到真实的成功案例，用户遇到SQL以外的严重问题，基本上还是要靠原厂才能搞得定，这到底是怎么回事呢?

实际上自治数据库的自治能力并非一蹴而就的，而是要依赖于一层一层的基础能力，往上堆叠出来的。要想实现真正的自治，从底层能力而言，必须完成数据库全面的数字化建模，数据库本身的底层数据逻辑能够覆盖问题分析所需要的所有层面，而要完成数字化建模，又必须依赖于丰富并且准确的可观测性体系(指标、日志、跟踪)，要想有丰富而准确的可观测性体系，必须在数据库内核里构建出丰富而准确的数字化模型，并高效地完成相关数据的采样与处理，又不能影响数据库的性能。在上层，又必须构建起完善的知识库体系，对这些数据的解析与分析都是构建在知识体系之上的。

经过三十多年的发展，O记在此的技术积累已经十分丰富。而国产数据库在这方面还差之甚远，甚至在某些领域还处于空白阶段。很多国产数据库厂商根本不清楚，要想获得强大的数据库自治能力，不是开发几个工具就可以解决的，数字化基础是关键，首先要把能够准确描述数据库运行状态的各种指标体系建立起来才有可能实现数字化描述，最终实现自动化分析和故障自愈。不夯实基础这一切都是空中楼阁，无从实现的。哪怕在数据库内核上已经打牢了基础，缺乏上层的知识库体系，这些基础能力也无法构建起能够在用户侧发挥作用的高层能力，这方面又是需要花钱花精力去补缺的。

不幸的是我们的绝大多数国产数据库厂商并没有着手夯实基础，而是直接在沙地上盖起楼阁，于是眼见着起高楼，眼见着楼就塌了。我曾经和某个国产数据库厂商的朋友交流这个问题，看到他两眼茫然的样子，我就知道作为产品经理的他，其实对数据库运维没有太多的经验，对数据库的可观测性能力如何支撑上层的运维是没有概念的。连产品经理都搞不清这些问题，那么也就别指望数据库的研发人员能够在这个领域有所作为了。

这些年的技术发展可以看出，在数据库可观察性能力以及自治数据库方面，O记是一步一个脚印的走出来的，每上一个台阶都是踏着前面坚实的基础的。很多国产数据库的产品经理并没有理解上层能力是依托于底层能力构建起来的，只是把上层能力当成做一个数据库的功能来设计，这样的话，就只能做出一些花架子了。长此以往，在这个领域，国产数据库厂商被O记远远甩在后面，而且差距越来越大就很正常了。

今天的这个话题似乎很沉重，可能很多国产数据库厂商的朋友也不愿意接受，不过良药苦口利于行。自己分析一下，为什么你的数据库出问题之后那么难以定位?为什么你的指标体系，日志，等待事件并没有能够真实的反映出你数据库的运行状态和所发生的问题?这中间到底缺了些什么?参考O记的体系去仔细想一想。这中间缺的东西其实就是支撑上层分析能力所需的底层能力，也正是你的产品中需要加强的地方。这方面不是你们的研发能力不足，而是你们对数据库的理解还只停留在数据库产品的研发上，而没有把数据库与用户的应用场景深度融合在一起。