DBA 2.0的时代
在2008~2009年,随着Oracle Database 10g的成熟与广泛应用,以及Oracle Database 11g的改进与推行,Oracle公司开始对DBA(即Database Admini-strator,数据库管理员)这个词进行了重新界定,进一步推出了DBA 2.0的概念。
当然DBA 2.0不仅仅是一个概念,更是对我们一直以来进行的长期思考的一个阶段性总结和升华。那么什么是DBA 2.0呢?
回忆起来,DBA这个职业从诞生、发展到成熟,其实时间是非常短的,记得2000年左右,DBA的从业人群还非常小,而到了2008、2009年,DBA的圈子已经越来越大,甚至传统意义上的DBA已经成熟得需要革新。这个行业的发展和变化如此之快,我们甚至举办过一个系列的高校巡回演讲活动,主题是如何成为一个Oracle DBA,类似的很多活动已经进一步将DBA这个词引入校园(Oracle公司已经在面向高校推进OCP认证),现在的学生能够接触到DBA这个概念的时间早得超乎我们当年的想象(很多人一毕业就可以加入到DBA行列)。
很多业界朋友都问过自己这样的问题,在数据库软件的自动化程度越来越高,应用越来越普及和简单之后,DBA当何以为生?实际上这也正是DBA 2.0时代我们要面对的问题。
说起来,DBA 2.0时代,直接同Oracle Database 10g引入的一个新产品表象相关,这个产品就是Grid/Database Control,这个工具将原来基于客户端的OEM通过Web形式来展现,并且基于后台众多新特性的支持,提供了强大的功能。
通过这个工具,以前要用SQL工具来追踪的SQL问题、性能问题等,现在使用新版的Database Control就可以通过Web页面清晰快速地展现和定位。
如图1-1的Oracle Database Control主页面清晰地展示了系统资源的使用情况及诊断概要信息等。
图1-1 Oracle Database Control主页面
而在SQL诊断部分自动数据库诊断监视器(Automatic Database Diagnostic Monitor,ADDM)更能够自动进行数据库问题的诊断,并且给出调整和优化的建议,图1-2来自一个真实的客户系统诊断,ADDM给出了存在显著性能问题SQL的调整建议(见图1-2)。
图1-2 Oracle ADDM给出的SQL调整建议
很多客户对于Database Control的感觉就是,这个工具真实地简化了用户对数据库的管理和监控工作,提高了用户的工作效率,改变就是如此简单。
而在传统的数据库层面,数据库的自动管理与自我维护性在不断提高,Database Control可以帮助我们更好地监控和管理数据库,AWR(自动工作负载信息库)使得信息的收集实现自动化,ADDM(自动数据库诊断监控程序)使得数据库可以根据AWR等信息自动地进行性能分析和诊断,SQL Advisor、SPM(SQL Plan Management)可以帮助我们进行SQL的调整和提供建议……
总体说来,Oracle更倾向于将新的数据库特性描述成一个具有主动性(Proactive)的产品,能够自主地、主动地发现数据库的问题,并提出优化和解决方案,这些功能在Oracle Database 11g中被进一步深化。实际上,Proactive这个词也正是2.0时代的DBA应该具备的素质。一个优秀的DBA,在数据库越来越完善的时代,应该拥有更多的主动性、预见性,应该能够对系统作出良好的规划和预期,将错误或故障消灭在萌芽阶段,从而使数据库环境拥有更佳的稳定性;更进一步,一个2.0时代的DBA,应该能够从企业的发展及大局出发,为企业规划更合理的数据管理方式、更有效的数据使用方式,从而不仅为企业节省投资,而且能够为企业创造更多的价值,DBA的发挥空间还远远不止于此!
然而一切并不如此简单,Oracle一方面在提高数据库软件的自动化水平,另一方面却将更多的知识、技术囊括入数据库的领域,在这个层面,实际上使得DBA需要了解的内容愈加广阔。比如,自动存储管理(Automated Storage Management,ASM)技术的引入使得DBA不得不更加深入地介入存储的管理和维护;集群软件(Clusterware)的引入,使得DBA不得不深入了解和维护Cluster软件;如果加上Oracle的OEL(Oracle Enterprise Linux)和2008年推出的Exadata及HP Oracle Database Machine,那么现在主机、操作系统、OS都要求一个Oracle DBA能深层次地介入和理解;2009年Oracle公司收购了SUN公司,并随之推出了Exadata V2和OLTP Database Machine,现在Oracle能够提供基于主机、存储甚至外加MySQL的整体解决方案。这一切都使得DBA们不断面临新的挑战。
总结一下那就是,在传统的数据库层面,Oracle不断在强化自动化管理,提高数据库的自我管理性,减少用户的干预和工作量;而在数据库之外,更后端,DBA需要不断向系统、存储甚至网络领域延伸,在前端,DBA则需要不断向应用层面进行扩展。而根据经验,不断向应用和业务方向延伸,是DBA职业发展的一个重要趋势。
DBA 2.0的使命大致可以概括为:在不断完善的数据库管理工作之外,向更广阔体系层面延伸,包括应用(Application)、系统(System)、存储(Storage)、网络(Network)、架构(Architecture)等方面,为企业提供更深远的架构与决策支持,促进企业向更全面合理的可持续性IT架构方向发展。以前,很多DBA是由开发转型过来的,现在,DBA向开发回溯必将为企业和个人带来更高的价值实现。
既然DBA 2.0意味着更广泛的层面介入、更深入的知识内涵,那么Oracle也不断在加强自己的产品,来降低DBA工作的复杂度,加强数据库的稳定性与可靠性等。实际上通过不断的收购以及长期的布局,Oracle已经打造了以数据库为核心的全系列DBA辅助工具与产品。
比如,Oracle最近推行的Real User Experience Insight产品,这是一款用于全方位监视实际系统运行性能的软件,用以确保基于Web的应用程序性能能够达到期望水平;在达不到期望水平时进行分析和通知,并提供用户应采取相关措施的软件。图1-3是其原理图,从Page request到请求返回,所有流程的响应都将被记录用于预警和评估。
图1-3 Oracle Uxinsight产品的逻辑图
这是Oracle在应用监控方面的软件,实际上这是在向前端、应用层、网络层迈进,这是Oracle的扩展策略之一。
而Oracle Enterprise Manager产品则是在数据库层面的巨大增强,Oracle一如既往不断在数据库层面加强其产品能力的体现。图1-4是Oracle在从开发到产品所有阶段自顶向下的应用管理示意图(摘自Oracle官方演示文档),其中数据库层面的Diagnostic and Tuning、Provisioning、Configuration Management等产品都是OEM产品的增强。
图1-4 Oracle自顶向下的管理产品结构
图1-4右侧的应用测试阶段,Oracle也有了很多新的产品,包括Real Application Testing(这是Oracle Database 11g中的功能,也整合在了Oracle 10.2.0.4及之后的版本中),而Data Masking(Data Masking组件在进行数据克隆时,可以对生产数据进行转换来保护原来的敏感信息,但是仍然能够保持数据的完整关系用于真实的应用测试)也是最新包含进OEM中的组件;另外Timesten内存数据库现在也打包进了Oracle Database 11g数据库产品中,Oracle In-Memory Database Cache现在可以作为数据库的一个组件销售。Oracle确实已经能够提供从前端到中端再到后端的全方位的数据库产品。而在2009年7月,Oracle又收购了数据同步复制领域的重要厂商GoldenGate,意图强化异构数据库之间的数据交换及迁移。Oracle以数据库为核心的产品战略布局已经发散到了各个角落。
如果深入体验一下新的OEM产品,可以发现其涵盖的范围越来越广,Oracle的意图是将OEM逐渐演进成为一个全面的系统管理、维护与监控工具,不仅涵盖数据库,还要涉及系统、网络、存储等方方面面。
现在我们能够透过OEM看到主机负载(见图1-5)、IO及ASM等全面的性能及负荷信息(见图1-6)。
图1-5 主机负载曲线
图1-6 ASM存储负载曲线
而在Grid Control中,更广泛的信息会被监控和收集,比如应用的响应与处理时间等(见图1-7),通过进一步的研究与分析,可以在不同层面对性能问题进行掌控和解读。
图1-7 Web Application的性能跟踪
虽然OEM还不能解决我们所有的问题,但是在日常工作方面,已经可以成为很好的助手。
OEM通过全面的监控部署,使原本需要手工处理的大量工作可自动进行,以前需要脚本编写处理的工作,现在OEM可以内置地自动完成,这部分增强对于DBA具有普遍的价值。
比如在监控方面,我们可以定义各种各样的度量条件(见图1-8),当达到特定阈值时,就触发报警。
图1-8 OEM的管理度量
如果配置了SMTP及邮件设置,数据库出现相关告警就可以自动发出告警邮件。通用功能的增强,是OEM中非常重要的部分,因为这部分增强可以将DBA普遍需要进行的工作简化,实现用户效率的提升。
OEM中的Diagnostic Pack和Tuning Package对于DBA具有更高的诊断与优化价值,通过这两个工具包,DBA可以很容易捕获并分析性能问题,并且可以参考数据库的建议进行改进。使用OEM进行问题SQL的捕获(注意,不要等待问题出现时才去关注,日常对于数据库的关注与监控尤为重要,也只有对数据库进行更全面的跟踪才能使DBA更具有预见性)与诊断变得非常快速与简便,这些变化甚至可以让对数据库仅有初步认识的人在解决数据库问题时也变得十分专业(见图1-9)。
图1-9 活动会话SQL诊断
而这些在OEM中可以快速完成的工作,在以前由于其复杂度可能会让很多对数据库了解不多的技术人员望而却步!Oracle在不断变革,DBA的世界也在不断改变,我们需要做的是跟上这些变化,继续出发。