DBA 1.0与DBA眼中的DBA 2.0时代


 今天我们都在谈DBA 2.0,而此前的模式就被归结为DBA 1.0,那么DBA 1.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.itpub.net/viewthread.php?tid=1098284在我的网站上,也有很多有价值的讨论:http://www.eygle.com/archives/2008/12/dba20_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更好的管理数据库,从繁杂的日常事务中解脱出来,更关注于发掘系统中需要改进的地方,从更高的层次来看待数据库,为企业创造价值。

    那么面对新的时代的新的要求,你准备好了新的工具和知识储备以应对变化么?


« 
» 
快速导航

Copyright © 2016 phpStudy | 豫ICP备2021030365号-3