作者 | 祁国辉
责编 | 韩 楠
01
从一个DBA的日常谈起
昨晚应用系统新版本发布， 为保证系统正常上线， DBA 老张忙了一个晚上。
本来以为是打酱油的一个晚上， 但是谁成想， 上线前才发现，应用的新版本因为增加了新的业务需求，对数据库表结构做了很多改动， 所以上半夜一直在倒数、 对数、改脚本， 再倒数的过程中度过。
好不容易应用部署完成了， 已经是早上5点多了。
老张好不容易打个盹， 但是很快就被叫醒了。睁眼一看， 八点半， 马上早上业务高峰要到了， 但是这时候发现系统出现阻塞，出现大量的等待事件， 可是系统响应时间是平常的好几倍。等9点之后， 业务高峰来了， 系统还不死给你看？完 蛋了， 八成是新应用的问题？
好在老张 也是个老炮， 心里迅速盘算了一下。
首先从索引看起， 发现果然是新增的业务模块， 在原来的超大表上做搜索， 但 是没有索引， 导致每次的查询都走了全表扫描， 从而导致系统性能急剧下降。在解决了类似的几个问题之后， 系统性能终于提起来了， 不用上线第一天就回退。
接下来的一上午， 都是一些鸡毛蒜皮的事情， 有个部门要求部署一套新的数据库；另一个部门说数据库突然不工作了， 数据录入不了， 去检查之后发现原来是表空间满了。
下午一上班，又紧急处理了一个数据库故障， 查问题， 开SR， 然后和数据库厂家支持部门来回多次， 上传了所有相关日志之后， 终于有了结论 。
幸 运的是， 这碰到一个已知的bug， 厂家已经有了补丁， 需要尽快打上这个补丁 ， 以避免该问题重现。然后问题又来了，因为是生产环境， 生产环境不能有任何闪失， 到底怎么打补丁， 有一堆功课要做：
这些问题都需要准备一份报告提交给经理。看来今晚又注定是一个不眠之夜。
相信像老张这样的DBA 生活， 大家都不陌生， 各个企业的DBA 主要工作大多数都变成了救火。DBA 不是正在救火， 就是在去救火的路上。
甚至在各种DBA的技术论坛上， 大家都热衷于分享各种故障的快速处理技巧， 或者共享自己常用的数据库优化方法。甚至有些大神还会有一些秘而不宣的隐含参数， 以及一些特殊问题的work around方法， 作为行走江湖的必杀技。
许多DBA耗费大量的时间和精力，来救火或修补问题，没有时间做计划和预防工作，从而导致越来越多的加班和越来越疲惫的心态。
进一步说，更糟糕的是， 业务部门和领导认为他不具备必要的专业知识来胜任DBA的工作。什么时候数据库运维能够简单再简单， 变成完全自动化， 那么DBA就可以从繁重的救火工作中解放出来了。
02
数据库自治和Alops,是不是DBA工作的终结
Oracle 19c（Oracle Database 19c）就推出了自治数据库的概念， 主要讲的就是自动化的数据库资源供应， 自动化的数据安全保护， 自动化的数据库运维和优化。Oracle的愿景就是让数据库走下神坛， 完全实现自治， 用户可以把精力更多地投向业务本身， 让企业专注于业务创新。
另外，最近几年随着人工智能和机器学习的快速发展， 很多创新企业开始把目光投向这个领域， 比如通过自动的日志分析， 就可以定位某个故障发生时到底系统处于什么状态， 到底是什么原因触发了这个问题。
有两个场景。
第一个 ， 应该大家都常见 。
新业务上线之后， 某个SQL 因为少写一个条件， 导致数据库连接变成笛卡尔积， 结果大量结果集冲击了整个IO系统， 最终影响整个系统的性能。
这就是典型的一个老鼠坏了一锅汤， 以前的DBA 经常处理的大SQL阻塞系统的故障就是这一 类。
在目前的人工智能场景中， 这种情况就可以得到比较好的控制， 以Oracle为例， 自动SQL隔离功能在出现这一类问题的时候， 会首先自动把这个SQL 停下来， 以免这个坏SQL影响整个系统；然后通知DBA和开发，后续对这个SQL进行分析和处理。
第二个场景，就是开头故事中说的索引问题。
还是拿Oracle来举例， 在自治数据库中提供一种自动化索引的功能， 就是系统会自动判断表上是否需要索引， 现有的索引是否需要保留等等。
在自动化索引功能打开的时候， 系统会自动优化现有的索引， 然后使数据库效能达到最大化， 当然它还很贴心地提供了多种选择， 比如仅仅做索引建议， 或者仅仅自动增加索引， 而最终级别就是自动增加、自动删除， 用户完全不用关心索引。
看到这里， 或许大家就自然而然地有了一个想法， 是不是以后不需要DBA 了呢？各个业务系统自己Devops， 然后加上数 据库的自动化运维，使得各种数据库的异常情况越来越少。最终直接导致DBA 无事可做呢？
03
DBA不救火之后可以干什么
说 到这里，我们可以暂时回头再梳理一下DBA 的日常职责， 传统的DBA 的主要工作：
• 首先是确保数据库随时可用；
• 其次是数据库的日常监控与预警；
• 进行数据库的用户和权限管理， 防止系统被滥用 ；
• 确保数据库的高可用配置， 以应对意外事件带来的系统不可用；
• 确保和验证数据库的备份随时可用，数据备份是最后一道安全屏障；
• 确保数据库的安全性， 防止出现数据泄露；
• 对数据库发生的突发事情进行处理；
• 对数据库相关的硬件/存储/网络，进行必要的管理；
•
除此之外， 还可能需要参与应用上线保障， 应用升级保障。
我们看到，传统DBA的日常工作核心，就是保证数据库随时可用。围绕着这个核心， 做了大量的工作， 如果数据库自治之后， 其实还是有不少工作是需要DBA继续投入的。
另外， 当DBA从被动救火中解脱出来之后， 还有更多更有价值的工作可以去做。
我们简单从以下的几个方面来看看，DBA 下一步的发展方向。
第一个方向，多视角理解业务。
可以尝试花更多的时间去做业务创新。不想做将军的士兵不是好士兵， 当然不想做CIO的DBA 也不会是一个好的DBA。
从CIO的角度去思考问题， 就会发现世界焕然一新， 从理解业务的角度再次重新审视业务部门提出来的业务需求， 自然也 会有更多的理解和判断。
例如， 能够从理解业务的角度， 重新考虑数据库的优化方法，比如设计表分区， 来提升数据库的处理效率。比如通过对业务的理解，来对数据库中的作业进行优先级的设计， 以确保重要的工作能够优先分配资源， 优先完成。
甚至可以介入应用设计， 把很多后期可能会出现的性能问题在设计期间就解决掉。
第二个方向， 数据架构设计。
作为DBA ， 往往是企业中资历较久的人员， 对企业的数据了如指掌。有了这个先决条件， DBA自然是对企业数据架构最为了解的人， 那么整个企业的数据流转， 数据治理，甚至数据分析的架构设计，都是题中应有之义。
第三个方向，沟通与项目管理。
我们经常发现，很多DBA醉心于技术无法自拔， 但是在与开发部门的沟通上一直都没有突破。
最终的结果，就变成开发与运维对立：
DBA 每次都说， 你看看开发写得什么烂程序， 不管三七二十一都放在数据库里做嵌套循环，导致性能极其低下； 而开 发又会反 过来说DBA水平不行， 数据库性能不好， 也不会做性能优化。
其实在人员快速流动的当下， 往往会有入职的新人，一上手就开始写代码， 但是由于之前的经验不足， 或者涉及数据量不大， 可能往往会有这样的情况：滥用数据库或者使用不当。
我曾经见到一个系统， 开发人员为了查系统时间， 短短一个小时， 利用数据库语句查询了几十万次Sysdate。
作为DBA， 其实应当多去做沟通， 做一些技术交流和培训， 让开发人员对数据库有一个正确的认识。做过数据库调优的人都知道， 调优效率最高的时间实际上是在设计阶段， 设计做歪了， 后面要花几十倍的精力来弥补。
放下技术人员的矜持和自尊心， 主动走出去， 多沟通，多交流， 自然可以事半功倍。
第四， 多种数据库的适配和学习。
现在的数据库替换热潮下， 几乎每个企业都会有多种数据库并存， 那么不同数据库的性能监控和优化方法，可能不尽相同。
这个需要对比学习， 另外在数据库迁移的时候， 也一定会发现， 在原来数据库上运行得好好的SQL， 突然在新数据库上跑不出来了。这种差异的对比， 以及对应的SQL 改写方法， 也是有很大工作量的。
另外，随着开源技术的快速发展， 出现了很多与数据库紧密结合的周边产品， 比如Redis；比如分布式数据库；再比如列式数据库。
这些数据库相关产品， 也都带来了管理、使用和运维上的 不同 ，尽快学习新的数据库技术， 跟上企业技术路线演进的步伐， 是当今DBA 必须面对的挑战。
第五， 学学新技术。
现在的IT行业， 已经进入了快车道， 一方面硬件性能突飞猛进， 另一方面，开源技术的发展也是日新月异， 加上云技术的快速发展， 摆在DBA面前的， 是一个崭新的世界， 是一个每半年就有知识替代的时代。
我 觉得，DBA 需要时刻保持以饥饿的心态来学习新的知识， 比如各种新型数据库；比如容器化和虚拟化， 比如CD/CI， 比如微K服务， 比如Kafka；了解新的开发语言， 比如Python、Go， 需要学习IaaS、PaaS。
04
广阔天地，大有作为
就像前面说的， 作为DBA ， 从繁重的救火工作中解脱出来之后， 还有大量的工作可做。积极拥抱变化， 不停留在现有的成绩中， 积极主动， 不断学习提升和进步。
数据库自治之后， DBA 有了更多的时间来做规划和学习。也有了更多的新的发展方向，紧跟技术发展的大潮，DBA面前又千万条金光大道。最后大家也可以评论区里说说，你觉得DBA的未来如何。 凡事预则立， 不预则废， 与大家共勉。
▼
作者介绍
祁国辉
前 Oracle 云平台事业部电信行业技术总监
【作者介绍】网名"atiger"，前 Oracle 云平台事业部电信行业技术总监。拥有超过25年数据库和数据仓库HK经验。曾创办著名数据仓库网站： (数据仓库之路）。