DBA 1.0与DBA眼中的DBA 2.0时代
我简单做了如下一幅图示，将DBA的工作分为三个部分：Pre-DBA、DBA、Post-DBA
DBA 1.0也许是我们都熟悉的模样，结合上图回想一下曾经我们的工作：在Pre-DBA阶段，可能我们需要进行数据库的安装部署工作，然后为了监控数据库的运行状况，我们需要编写一系列的脚本来监控数据库的运行，监控的内容有很多，包括ORA-错误信息、警告信息、空间使用情况、负载信息等，当然如果是我们自己来进行这些开发工作，你会发现甚至每个企业每个数据库的监控脚本都全然不同，我们的DBA在不停的发明重复的轮子，而且直至今天，这样的脚本开发工作仍然在不停进行。
这些监控信息或者可以通过邮件的方式发送的DBA的邮箱，或者通过短信直接发送到DBA的手机或其他终端，又或者集中到一个统一的故障管理平台进行统一调度，总之这套监控体现要能够保证故障得以及时发现和处理。
完成了监控工作，首先解决了最重要的稳定性问题，然后需要来解决数据安全性问题，这就是要备份。实际上备份一直被我列为DBA的第一要义：备份重于一切。
解决备份问题稍微容易了一些，首先当然也要编写一些脚本，通过Oracle提供的标准工具RMAN、EXP、EXPDP等来完成备份即可。
完成了安装部署、监控和备份工作，接下来要为性能、诊断做准备工作，这就需要我们设计收集数据库运行数据的方式，通过Statspack或者自己开发的程序来采样都是常用的方法。
以上几大类工作，我姑且称之为Pre-DBA的工作，也就是一个企业DBA在开始正常的日常工作之前需要完成的工作，所谓兵马未动，粮草先行，这些工作就是DBA的基础与装备。
关于这部分工作，我曾经想建立一套共享的系统（类似Wiki），由大家共同维护一套程序或脚本，这样可以为全国的DBA节省很多的劳动，可惜这个想法至今未能实现。
那么DBA的日常工作是什么呢？
我想每个DBA都会有很多答案列出来，但是总可以找到很多共同的内容。很多例行的数据库维护工作，比如用户的管理、空间的管理、监控内容的检查，数据的加载和卸载、批处理任务的执行等等。
如果规划得当，这些工作将是例行和规范化的，所以不需要消耗太多的时间和精力，如果处理得当，DBA的日常工作可能会相当迅速的完成。
当然除了这些，我觉得DBA还有一个非常重要的日常工作，那就是：学习！
DBA应当不断学习，掌握新的知识与技能，了解数据库技术的变化与更新，这样才能不断跟上技术的变革，并且在出现问题的时候能够快速诊断和处理。
那么第三部分工作，也就是我们认为最重要的工作，那就是异常处理（请允许我用这四个字来概括这纷繁复杂的DBA工作）。
如果数据库运行的非常稳定，那么你会发现DBA的工作表现出来将是非常轻松和清闲的，可能数月甚至经年都没有故障处理，这也就是很多企业并不设立DBA职位的原因。
但是这种理想情况并不会保持太久，如果企业的数据规模、应用规模逐渐扩大，那么数据库将不可避免的面对很多问题，最经常展现出来的是性能问题，一个不良的SQL可能就会导致数据库的服务质量严重衰减，甚至停顿；此外，数据库还要面对种种不可预见的故障，DBA的职责之一就是快速从这些故障中恢复服务。
想一想是不是每个DBA都遇到过这种情况：数据库忽然变慢，客户投诉电话不断，然后老板不断的给DBA施加压力，快点解决数据库的问题……
那么DBA此时该如何操作？如何精准的找到原因、快速的解决问题？这决定了DBA的成败。
好吧，我们一起来看一下DBA 1.0的时代，我们是如何面对和解决这些问题的。
忘记手忙脚乱，镇定下来，我们开始检查系统负荷、资源使用情况，看看瓶颈出现在何处，诊断数据库问题，找找是否SQL性能低下、是否查询执行计划错误、是否没有合适的索引……
更复杂一点的，我们可能要检查很多日志和文件、检查数据库的性能数据，进行深入的分析以发现问题的根本原因……
也许我们能够找到故障的原因，也许我们能够快速的解决问题，而更有可能的是，我们需要更多的时间来进行分析和排查，也许问题会相当复杂……
如果系统环境复杂、规划不当，那么一个DBA可能周而复始的被埋没在这样的工作当中……
这就是我能够想到的DBA 1.0的时代，你的DBA 1.0时代又是什么样子的？
在ITPUB上很多DBA发表了对于DBA 2.0的观点。具体链接参考：http://www.uplook.cn/?a=index&m=index&c=iframe&url=http%3A%2F%2Fwww.itpub.net%2Fviewthread.php？tid=1098284在我的网站上，也有很多有价值的讨论：http://www.uplook.cn/?a=index&m=index&c=iframe&url=http%3A%2F%2Fwww.eygle.com%2Farchives%2F2008%2F12%2Fdba20_road.html我试着引用和总结一下大家的观点，看看DBA朋友们对于DBA 2.0概念的理解。
弦乐之花的观点：dba2.0不是对dba1.0的否定，不是技术与管理的选择，或者可以说，dba2.0是dba1.0的升级，如果你不是合格的dba1.0，没有扎实的数据库理论和oracle基本功，dba2.0谈不上，dba2.0不是对技术要求的降低，而是提高，对思维层次的提高，对于技术把握的提高，哪些是需要掌握的，哪些是需要了解的，做到什么层次，在实际应用中如何应用取舍。
「Eygle」以上这段话说的非常的好：dba2.0不是对技术要求的降低，而是提高，对思维层次的提高，对于技术把握的提高。 只有不断提高，才能够满足时代变化和技术进步的需要。
我觉得最近这些年，由于网络的普及，沟通的便捷，DBA的成长变得更加迅速，Oracle数据库的自动化增强以及大量管理工具的推出更简化了DBA的工作，这一切都要求DBA要能够更上一层楼！
Owlstudio的观点：DBA在不同的公司地位不一样啊，受重视的程度不一样，希望所有的DBA努力做出更大的贡献，这样才能为我们自己争取更高的地位，有更多的话语权，更受人敬重！
「Eygle」这也是类似的观点，DBA只有更好更快的成长，为企业创造更多的价值，才能更好的实现自我价值，获得更合适的地位与话语权。
bluemoon0083 的观点：DBA就是要去学很多东西，恨不得有关联的都去学一下，优秀的就是所有这些东西不仅会用而且能够用的好能够融会贯通。只是现在越发觉得，IT技术很多都是别人定好了规则，在这些规则之下要能够玩得好玩得转，而且随着时间的推移会不断冒出新规则，一些老规则可能被代替或者需要修改来适应新规则。
DBA就是如何来利用好技术而不是创造技术，当然这是两个范畴，会创造技术的不一定能够利用的好技术……
「Eygle」融会贯通也许真的是对于DBA 2.0的一个本质要求，越来越多的知识涉猎，需要DBA站到更高的层面，为企业考虑更多，甚至直接为企业创造利润。有人说DBA为企业创造直接的价值是很难的，难到几乎不可能，DBA从来都是一个成本单位，而同利润无关。也许很难，但是也许很多人已经走出了好的道路。
在DBA之外，今年流行的云计算领域，Amazon推出的S3、EC2等AWS服务，实际上就是该公司最初基于IT设备合理利用考虑而构架的平台，再到对外服务、到今天能够为Amazon带来1亿美元年收入的云计算服务，这个创举已经创造了一个新的技术趋势。
那么DBA这个领域是不是可以借鉴别人的创新并且有所突破呢？
muzijiang 的观点：其实这个话题很早以前就开始讨论了，数据库越来越智能，人工干预越来越少。但也这对dba来说不见得就是坏事，这意味着DBA可以从繁杂的监控事务中解脱出来，更关注于发掘系统中需要改进的地方。
2.0时代的dba，我感觉即像是集成，但应该超越集成，或者说更像是系统架构，跳出Oracle的范畴，从更高的层次来理解数据库
「Eygle」没错，DBA 2.0的时代，要求DBA跳出传统DBA的范畴，从更高的层次来理解数据库，管理数据库，使用数据库。
而国内领先的阿里巴巴系的DBA们已经走的更远，据biti透露，他们在未来的规划是：……2009 年……一个长期计划是提高资本使用率（3－5年规划）
1.长期目标为 业务增长率 > 资源增长率 > 成本增长率 ，与各部门在这个方向上达成共识，寻找切入点执行2.跟踪量化现有资源使用率，促进应用优化，优化单位资源成本，探讨容量模型
「Eygle」Biti的身份和考虑的事情已经超出了常规DBA的范畴，但是实际上也正是一个技术人员发展到更高阶段的真实展现。他们已经跳出数据库的范畴，从更高的层面开始考虑资源的利用与成本。而Amazon也正是经历了这样的思考之后，发展出了今天名闻天下的AWS服务。
总结一下，其实大家的观点都一致的认为，2.0时代对DBA的要求实质上是更高了，要求DBA更好的管理数据库，从繁杂的日常事务中解脱出来，更关注于发掘系统中需要改进的地方，从更高的层次来看待数据库，为企业创造价值。
那么面对新的时代的新的要求，你准备好了新的工具和知识储备以应对变化么？
