浅谈DBA的角色以及与业务的关系

--本文的内容来源于我和赵元杰老师的一次聊天，赵老师是非常资深的Oracle专家，对Oracle的根本原理以及对既有数据库的优化有非常深的造诣和非常丰富的经验，他对于技术的钻研精神，非常值得我们这些后辈学习。

当前，在很多公司中，不管是IT公司还是非IT的企业，都会配备DBA这样一个职位，负责管理相关的数据库。然而，很多时候，DBA这个职位的位置却有些尴尬。

一般，一个企业的IT团队会分为两个部分，一部分我们可以称之为基础设施或者基础架构（Infrastructure）团队，他们会负责管理企业的计算机硬件、服务器、网络设备、电话等等；而另一部分一般称为应用开发，负责与软件开发相关的工作。

那么DBA应该归属于哪个团队呢？从程序员的角度来看，DBA当然应该归属于应用开发团队。然而，实际情况并非如此，因为DBA要负责管理数据库服务器，所以很多时候都会被划分到基础架构团队。而且，一般来说，数据库的结构设计工作，都是由应用开发团队来完成的。DBA并不会根据应用开发的需要来对数据库服务器进行规划，而只是简单地保证有足够的数据库空间供应用开发团队使用就好了。

同时，开发团队也不一定认可DBA称为开发团队的一员，当前很多企业都在搞EA（Enterprise Architecture），也就是企业架构，期望IT的架构能够和业务架构相互匹配，从而让IT能够更好地为业务服务。在这里，IT的架构研究更多着重在企业的各种应用服务器，重点也在于应用开发方面，而并没有把数据库的架构那纳入进来，或者说没有把它提到一个足够高的位置上来。

另外，现在有了云技术，越来越多的企业会把数据放在云存储上，从而降低公司的成本，如果真的把所有的数据都放到云端的话，那么DBA这个角色就没有在企业中存在的必要了。

然而，我们是否认真的考虑过，数据库的架构是否要和业务的架构匹配呢？或者说，DBA是否需要了解业务，才能够更好地完成自己的工作呢？

如果深入了解数据库的运行原理之后，我们会发现DBA了解业务是非常必要的，不妨举例说明：

大家都知道，在Oracle数据库中可以设置很多表空间，而不同的表空间可以放置在性能不同的存储设备上，那么在哪里放置什么样的表空间，而在表空间里存储什么样的数据就有讲究了。

比方说对于经常会用到的数据，像一些基础数据，就需要放在性能高的地方，而不会经常使用的数据，像日志、备份数据，就可以放在性能低的地方。

比方说有时效性的数据，对于最近的数据或者说今年的数据，就应该放在性能高的地方，而十年前的数据，可能需要归档了，就可以放在性能低的地方。

再比方说各种数据存储的问题，各个部门所要使用的数据表之间都会有很多关系，而把这些数据存储在相近的位置，那么在获取数据的时候就会比较快，而如果散落在各个角落，那在获取数据的时候就比较麻烦，性能也低。

另外，还有一些Oracle专有的技术，像各种类型的索引，对于各种不同的数据，采用不同的索引，最终的性能也不同；还有对数据表的分片（partition）技术，也必须在了解了业务之后才能够作出比较合理的选择。

由上面的内容，我们可以看出来，想要真正保证数据库的设计和运行的性能，DBA非常有必要了解业务的一些信息。

而当前的很多DBA的工作方式却很无奈，对于表空间，他们可能只会建立一个非常大的表空间，然后把所有的应用数据都放在一起；在开始的时候，也没有办法对数据库的存储设备等进行有效合理的规划，根本的原因还在于他们无法了解到业务的信息。

综上所述，作为DBA，需要更多地参与到系统的建设中来，而不是单纯地对服务器进行管理，而且需要了解更多的业务知识。

你的观点如何？