记得我在1999年在某网站第一次担任DBA工作后不久，公司一位新来的财务总监（CFO）看到我的一份述职报告之后问我：“请问DBA代表什么意思？”

我想现在别说CFO了，整个IT界都应该无人不知数据库管理员（DBA）这个职位了，更深深理解这个岗位对企业的重要性。DBA，即企业最重要的数据资源管理者！俗称“裤头”啊，呵呵。

相比应用开发人员一般承担具体应用模块开发，工作职责、工作范围比较明确，而DBA却给人感觉好像平时无所事事，而只有数据库系统出问题了，才看到DBA救火的身影，给人一种“养兵千日，用兵一时”的感觉。“DBA究竟应该干什么呢？”身为Oracle原厂服务团队，也是为广大DBA提供服务、共同合作最多的我们，经常面临客户领导、技术人员这样的问题。

以下就是我摘录Oracle官方联机文档之一，也是DBA应该最常备的手册《Oracle® Database Administrator's Guide11g Release 2 (11.2)》第一章中描述的DBA的11大职责：

我想上述11大职责是老外根据国外DBA经验总结归纳而来，不仅体现了国外IT行业分工明确、细致的特点，而且也有一定的学究气。而国内IT行业DBA们都在干什么呢？可能有的国内DBA对上述11大职责不以为然：“我的工作内容比这还要多得多，不仅管数据库，还管中间件和应用，甚至管硬件、操作系统、网络、存储呢。”也有的DBA会感到汗颜：“我们在数据库管理方面还真没有这11大职责这么细致，比如我们可能从来不打补丁。”

以本人的感觉，无论是前者一样面面俱到的通才，还是后者菜鸟一样的初级入行者，其实就DBA本身工作职责而言，国内DBA们都或多或少有缺失，而最大的缺失就是DBA们对应用的缺失，甚至完全不关注。也许原因很多：有国内企业运维和开发两大部门分工和职责过于明确的因素，也有DBA们自身认识偏差的因素。

总之以我的观察，国内绝大多数DBA更专著于数据库系统层面、甚至硬件等，而忽略了对应用的关注。换言之，国内各企业的DBA们其实更多扮演了系统级DBA角色，各企业明显缺乏应用级DBA。我想这也是导致国内IT系统应用级和系统级脱节、IT系统整体质量不高的重要原因。

再介绍一个案例：在我们Oracle服务团队为某外企提供应用优化和架构优化等服务过程中，我发现与国内大多数企业DBA一样，该外企DBA也是一个标准的系统级DBA，因为他明显缺乏对应用的深入了解，这种状况在一定程度上影响了整个项目的实施质量和实施进度。于是，我感慨和建议道：“你们公司其实非常需要设置一个应用级DBA岗位。”

没想到这条建议当天就被汇报到该企业的CTO，CTO深受启发，第二天就给我反馈：“请罗老师告诉我们应用级DBA岗位的资质、工作职责、工作范围，我们企业应该如何培养一名合格的应用级DBA？如果我们暂时培养不了，请你们原厂提供有资质的应用DBA专家。”

是啊，应用级DBA究竟做什么？其实多年来，我也一直只是有这种感觉和建议而已，并没有深入思考过这些问题。国内企业也鲜有这种角色可供参考，而且无论系统级还是应用级DBA的工作职责和范围都是需要结合各企业、各单位具体情况进行定制的。尽管如此，本人今天还是斗胆提出如下一些拙见，抛砖引玉，供大家参考。

• 应用级DBA一定要有多年应用开发经验

首先，应用级DBA一定要有多年应用开发经验，我想这一条大家一定苟同。否则，他无法从应用层面，尤其从IT系统整体视野去看待问题。多年的应用开发经验，更能让他/她能以易于理解的语言与广大应用开发人员沟通。

• 应用级DBA也一定要具有系统级DBA能力

其次，应用级DBA也一定要具有系统级DBA能力甚至实战经验，我想这一条大家也一定不会有疑义。当然，他/她可能不如一个真正系统级DBA那样对系统层面的细节如此精通。但他/她至少应懂得RAC、Data Guard等技术原理，更能结合应用去看待系统层面的关键问题。

例如他/她应该知道在RAC环境下确保高性能、高扩展性的关键点是尽量减少RAC之间的数据访问冲突，合理的应用部署和数据访问分离是RAC实施成功的重要策略。他/她也应该知道Data Guard的关键因素是日志文件的产生量，他/她考虑的不仅是网络带宽、主机和存储对日志文件的传输和处理能力，他/她更应该考虑如何通过应用优化降低日志文件产生量，从而从源头就确保Data Guard的成功实施。

• 应用级DBA = 系统架构师 + 数据库设计师 + 应用设计开发专家 + 应用质量控制师

这一条实际上更细化了应用级DBA的工作范围和定位。

从架构层面而言，他/她的确是数据库采用集中式还是分布式架构的重要决策者，他/她还是RAC、Extended RAC、Data Guard、Active Data Guard、Golden Gate等技术架构方案的决策者和总体方案设计者。

从数据库设计角度而言，他/她应该精通数据库逻辑设计基本原则和规范化设计理论，甚至对PowerDesigner、E-R Win、Oracle Date Modeler等模型设计工具都非常熟诣。在数据库物理设计方面，他/她更是对不同数据库平台的物理细节非常熟悉，例如深入了解Oracle表空间、表、索引、Sequence、物化视图等各种类型数据对象的原理和物理属性，还需要了解ASM事例、ASM参数、ASM磁盘组、ASM磁盘文件等诸多系统层面细节。

在应用设计开发和质量控制方面，更应该是他/她的老本行。虽然他/她可能已经不再承担具体应用模块开发工作了，也就是不再是烹制美味佳肴的厨师了，但他一定是位美食家，对各种SQL分析和诊断工具轻车熟路，并能准确定位各类SQL质量问题。更进一步，他/她还应该是应用设计开发规范的编制者和执行者。总之，他/她应该是最关系到IT系统质量的应用设计开发专家和质量控制师。

• 极强的组织、协调和沟通能力

应用DBA不仅应具备上述全面的知识架构和技能，更应具备极强的组织、协调和沟通能力。他/她不仅是应用开发团队的领导者、组织者，而且也是与客户、测试、运维等不同层面和角色的协调和沟通者，他/她的职责不是只考虑局部利益，而是真正能站在IT系统整体和全局高度，去组织和协调IT系统建设、运维等各阶段的工作，有效处理各阶段、各部门存在的问题、矛盾和纷争。

“罗老师，你这么描述应用级DBA的资质和职责，这样的人太难找了，你们原厂恐怕都没有这样完美的人吧？”是的，世界上很难找到具有这么完美知识结构的通才，那我们还是要从实际出发，特别是从应用级DBA与系统级DBA的分工和合作角度出发，去追求IT 系统更高的目标和境界。

• 开发和运维是个整体

无论是国企还是外企，无论职责如何划分，我们的确发现大多数企业的开发和运维两个部门都存在着一定矛盾，甚至在某些企业达到了剑拔弩张的程度。这种局面对整个企业的IT系统建设是非常不利的，相互指责、相互推卸责任，甚至相互拆墙无济于事，更是置企业IT系统整体质量于不顾。

• 应用级DBA与系统级DBA紧密合作的场景

我想还是举几个应用级DBA与系统级DBA紧密合作的具体场景，来加深大家对这种合作重要性的理解吧，也是为各企业开发和运维两大部门如何进行具体合作提供一些参考。

在数据库设计领域，如果系统级DBA也能参与其中，或者至少让系统级DBA知晓数据库逻辑设计和物理设计结果，一定可以充分发挥他/她的技术优势和经验。例如，系统级DBA非常熟悉磁盘系统的划分情况，他/她就可以根据应用情况，提出ASM磁盘组划分原则和实施建议，比如将最主要的交易表存储在性能最好的磁盘组里面，甚至根据ASM最佳实践经验，将这些交易表数据存储在ASM磁盘的最外道，从而更充分满足对这些最核心交易数据的访问性能需求。

如果系统级DBA更能了解应用特征，对他/她的各项运维工作也一定是大有帮助的。例如，当他/她知道主要业务表的访问特征，他/她就可以合理制定分级数据压缩方案了，比如，当月频繁访问数据不压缩；2-3个月访问频度比较低的数据采取OLTP压缩算法；更久远的几乎不访问的数据采取归档压缩算法等。

再比如，当他/她了解了数据变更情况，就可以为数据碎片整理、历史数据迁移和管理、数据备份/恢复等制定出更有针对性、更经济合理、投入产出比更高的技术方案了。例如，我们就会发现国内Oracle系统不会都采取最简单的“全库备份+归档日志备份”策略了，不仅会有“全量 + 增量”，而且还会有快速增量备份（FIB），甚至不仅在库级，而且会根据业务数据分布情况在表空间级、数据文件级设计备份方案了。

反过来，应用级DBA如果能更深入了解系统层面的知识和技术，特别是掌握IT行业最新发展趋势，就更有助于他/她设计更完美的IT技术架构，让应用软件设计更充分发挥新技术的特点和优势了。比如，若他/她了解Oracle 12c推出了In-Memory Option技术了，他/她就可以指导其统计分析和报表开发团队去深入了解这种技术并合理加以运用。若他/她了解Oracle 12.2即将推出水平分布式的Oracle Sharding技术，也知道这种技术主要适合于OLTP交易系统，因此他/她就可以指导其团队将核心交易表设计为Sharded表，并通过Sharding Key进行水平分库了。

其实写到这儿，我自己都有点写晕了，因为虽然各有侧重，但是应用级DBA和系统级DBA其实是你中有我、我中有你的关系。也许在一个企业内部设置两种DBA职位不尽合理，也不一定适合中国国情，但重要的是设计、开发、测试、运维等各阶段和各部门的确是一个整体，只要各个部门、各种角色真正协调合作、良性循环起来了，IT系统整体质量就一定有保障了。