从我的理解来看，我会从下面的几个方面来进行说明DBA运维中的一些事儿。

每个部分都是非常关键的，缺一不可，而且每一部分都有很多的东西可以细化，我会逐一展开来说。

 

（一）环境篇

 

 

 

首先来说说环境篇。

 

DBA的角色及分工

对于DBA的分工，以前的公司对于DBA角色划分粒度还是很细的。

大体是按照核心和客户化定制层来划分的，核心层主要负责产品化，客户化层面主要负责定制。属于不同的产品线但又彼此紧密关联。

Physical DBA更多负责环境部署，搭建和数据恢复，补丁升级等，对于系统，存储网络等更为拿手。

Performance DBA一般都是从各个产品线逐渐衍生出来的高手，对于产品理解很深，当然工作重点是在性能调优上。一般都是产品级的优化，全球所有项目都会通用。

Dev DBA也有一个团队，负责运维产品的开发，其实内部的很多自动化的工具都是他们做出来的，当然开发功底要求也很了得。

Delivery DBA主要负责数据交付，一般的UT,UAT,PROD的数据交付，有的时候涉及的环境成百套，对于这些数据的交付管理非常重要，补丁管理，数据变更的基线管理，数据的同步，复制，业务环境搭建都会涉及。

Application DBA 主要和业务相关，一般和开发的联系较为紧密，一线的数据支持，对于系统的架构，业务情况要很熟悉。

最后是site DBA，所有产品，业务的事情都要考虑，最终的方案和实施落地。

然后来说说行业环境，以我为例，我也是从传统行业到了互联网行业，当然也需要作出一些改变。

从角色上是从乙方到甲方，很多的事情都需要考虑，对于技术方案和硬件选型，不仅仅是纯技术上的考量，需要更多的因素。这是一个全面的过程。

当然和传统行业来比，传统行业更为保守，稳定压倒一切。

以之前的电信客户为例，测试情况极为苛刻，UAT测试做了差不多一年。

对于产品和数据库的版本搭配，公司也有严格的认证制度，哪个产品适用的数据库子版本（比如11.2.0.2.x）都有要求，因为这些是实实在在做足了测试。

很多客户对于RAC的使用也是保守的active/passive方式，当然自11g的ADG之后，也在默默的开始替换BCV的方式。

从数据库的角度来看，为了保守，很多特性都会禁用。