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

01引言
数据库管理员(DBA)承担着保障生产数据库稳定运行的职责,在完成生产变更、事件处置等工作的同时,还应该在哪些方面持续提升自身能力呢?本文从银行DBA的视角,谈一谈“DBA的自我修养” 。
02看山是山
 
 
看山是山,就是干一行研究一行 。DBA每天在做什么?以G行的经验,大概有五个方面的工作:日常维护、环境搭建、升级迁移、开发支持、故障处置 。既然做DBA,就得研究怎么把这些工作做好 。 
日常巡检靠人工做,耗时耗力容易遗漏 。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参与故障处置,无论是不是数据库的问题,首先应该让自己进入战时状态,一切行动听指挥,严格执行指令,主动报告发现;牢记降低业务影响是故障处置第一目标,快速响应,沟通表达清晰简洁,当断则断 。

我们一起聊聊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之间的区别就大了 。


推荐阅读