我们一起聊聊DBA的自我修养

01引言

数据库管理员(DBA)承担着保障生产数据库稳定运行的职责，在完成生产变更、事件处置等工作的同时，还应该在哪些方面持续提升自身能力呢？本文从银行DBA的视角，谈一谈“DBA的自我修养”。

02看山是山

日常巡检靠人工做，耗时耗力容易遗漏。G行的经验是从标准化到脚本化、再到工具化。巡检做到位，就有了解决潜在的故障和容量风险的提前量，按标准的变更流程和变更工艺执行更加从容，也就不易出错。“备份天天做，恢复一时难”，G行有句话“不以恢复为目的的备份都是耍流氓”，恢复测试是写进G行科技管理制度的强制要求，每年进行检查考核。

环境搭建效率的提升，在G行一样是经历了从标准化到自动化过程。通过软件的Golden Image加上PaaS平台的自动化交付，标准一致，快捷高效。

至于升级迁移，不仅仅是升级操作本身，还有升级前各种测试，选择最佳的升级窗口、千方百计将对业务的影响最小化，升级后组织保障，桩桩件件都得考虑周详。当我们历尽艰辛终于把成百上千的数据库升级最新版本之后，就会惊喜地发现：最早升级的那个数据库又该升级了...好吧，我们的经验有3点：

1、首先选择合适的软件版本，就是所谓的LTS（Long Time Support）版本，不仅仅是数据库软件，还包括中间件、操作系统乃至硬件，最好保持基本一致的生命周期，避免“你方唱罢我登场”。

2、统筹规划，与应用系统的架构改造、功能升级的计划相结合，提升测试效率，避免资源重复投入。

3、针对不同数据量、不同重要程度和不同停机窗口要求的系统，总结对应的升级实施工艺，分类施法，有标准可依。此外，作为“高效能人士”的DBA，在版本升级这件事情上，还是尽早养成“以终为始”的好习惯吧...

支持开发和测试，是G行DBA的日常工作中时间占比最多的部分。高效数据库真的是设计出来的，而80%的数据库性能问题都是SQL问题。G行一方面将SQL编写和数据库设计的最佳实践写入科技开发规范，同时引入了SQL审核工具进行实际检查。这里要特别提到的执行计划和统计信息收集这两个近乎玄学的东西了。G行根据自身实际需求，定制开发了统计信息收集工具，可以根据表的大小、分区与否、业务运行的时间规律以及表内数据变化的特性，分别收集、复制乃至直接设置统计信息，目的就是保持SQL性能的稳定。即便如此，Hint和SQL Profile / Baseline仍然是必不可少（这里必须给O记加个鸡腿，其他兄弟继续努力吧）。

前面说了日常运维、环境搭建、升级迁移、支持开发四个方面的工作，如果这四个方面做好了，数据库的故障自然会少。但不是说故障处置的工作不重要，相比其他方面的技术问题，这里我们更想说的是的DBA在故障处置中行动标准。DBA参与故障处置，无论是不是数据库的问题，首先应该让自己进入战时状态，一切行动听指挥，严格执行指令，主动报告发现；牢记降低业务影响是故障处置第一目标，快速响应，沟通表达清晰简洁，当断则断。

 图1 

03看山不是山

DBA往往聚焦具体的某个数据库产品的运维和研究，有时候会把一个产品的概念和特性等同于数据库这个技术门类的概念和特性。其实这也不算大问题，DBA本身就是个具体的工作，必须对一个数据库产品学习透彻，不仅仅是操作，更要深入了解原理。只不过在这个数据库产品百家争鸣的时代，如果我们入戏太深，在接受新产品的时候会有些额外的困扰。

例如，PostgreSQL是典型的学院派，遵循中Database Cluster-Databases-Tables的经典关系数据库概念。如果我们把PostgreSQL里的Database Cluster与Oracle里的Cluster（Real Application Cluster）去对照理解，难免不知所云。即便是最基本的“Database”这个词，不同的数据库产品中定义也不尽相同。MySQL里的Database的范围大致与Oracle/DB2中的Tablespace相当，尽管MySQL自己也有Tablespace这个概念；再有，Oracle的同学往往不怎么区分Schema和User，因为在Oracle里面这两个东西实际使用起来没什么区别。而在DB2、MySQL之类其他数据库中，用于认证和权限管理的User和用来组织对象的Schema之间的区别就大了。

看山不是山，这里讨论的不是哲学里共相与殊相的深奥问题，只是想建议DBA跳出某一个产品的范畴，一专多能。可以尝试一下用下面的结构梳理一下不同的数据产品。

图2 

如果想了解数据库内部的原理，推荐学习这些材料:

1、MySQL:MySQL Internal （dev.mysql.com/doc/internals/en/ ，目前MySQL官网上是8.0版本的源代码指南，实际上5.7版本的Internal手册更加适合DBA）。

2、PostgreSQL:The Internals of PostgreSQL (www.interdb.jp/pg/)，作者铃木启修，有中文版。

3、Oracle:Oracle Core Essential Internals for DBA，作者Jonathan Lewis（Oracle领域的大神，出自牛津数学系），有中文版。

04看山还是山

“庐山烟雨浙江潮，未至千般恨不消。到得还来别无事，庐山烟雨浙江潮。”苏东坡说的是人生，技术又何尝不是如此。

KV数据库、文档数据库、图数据库、时序数据库...乱花渐欲迷人眼。我们这里想下一个判断，且看验与不验：未来10年甚至更长，关系数据库仍是不可撼动的主流。原因在于：其他数据库解决的是技术问题，而关系数据库尤其是它背后的关系模型可以定义世界。让我再次致敬伟大的Codd博士吧！

只要是关系数据库，就一定有三个必须的功能组建：SQL解析、事务管理和存储引擎。集中式数据库将三个功能做在一起，而分布式数据库往往将三个功能分散在不同节点来提升扩展性。

看山还是山，希望DBA能够从深入到浅出，从本质上理解数据库，对数据库技术发展的趋势形成自己看法。

05总结

如果问到我们的看法，或许可以参考这段对话:

问：“他们认为分布式数据库是未来”。

答：“这是对的。”

问：“那我该怎么办？”

答：“要多想。”

问：“想了以后呢？”

答：“我只能告诉你，那以前要多想。”