自治数据库是咱们这代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记的体系去细心想一想。这两边缺的物品其实就是撑持下层剖析才干所需的底层才干，也正是你的产品中须要增强的中央。这方面不是你们的研发才干无余，而是你们对数据库的了解还只逗留在数据库产品的研发上，而没有把数据库与用户的运行场景深度融合在一同。