DBA 2.0的时代与 Oracle促进的变革

izuoyan

浏览: 9221809 次
性别:
来自: 上海

最近访客更多访客>>

GDGZWQZ

morelily

eternal1025

devcang

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

2012-06 ( 32)
2012-05 ( 145)
2012-04 ( 50)
更多存档...

Oracle 企业应用网络应用配置管理 SQL

这几天看到Kamus和Piner分别写了一些关于OEM的文章。
Kamus探讨了OEM在税务行业的应用，Piner探讨了后9i时代的数据库优化。

前几天我讨论的关于DBA 2.0的话题，实际上也正是Oracle在后9i时代不断促进的变革，而变革的主要工具之一就正是全新的OEM（Grid/Database Control）。所以我尝试将这个话题做一个最后的总结。

既然我们开始了DBA 2.0的讨论，那么DBA 2.0是从何开始的，又可以如何界定呢？

普遍的认为，DBA 2.0开始于Oracle Database 10g的时代，由于Oracle 10g引入了大量的新特性，使得DBA的工作发生了质的变化。
比如，ASM的引入使得DBA不得不更加深入的介入存储的管理和维护；Clusterware的引入，使得DBA不得不深入了解和维护Cluster软件；如果在加上Oracle的OEL（Oracle Enterprise Linux）和最近推出的Exadata以及HP Oracle Database Machine，那么现在主机、操作系统、OS都需要一个Oracle DBA深层次的介入和管理。
而在传统的数据库层面，数据库的自动管理与自我维护性则不断提高。Grid Control/Database Control可以帮助我们更好的监控和管理数据库，AWR（自动工作负载信息库）使得信息的收集实现自动化，ADDM（自动数据库诊断监控程序）使得数据库可以根据AWR等信息进行自动的性能分析和诊断，SQL Advisor、SPM（SQL Plan Management）可以帮助我们进行SQL的调整和建议。。。。

总结一下那就是，在传统的数据库层面，Oracle不断在强化自动化管理，提高数据库的自我管理性，减少用户的干预和工作量；而在数据库之外，更后端，DBA需要不断向系统、存储甚至网络领域延伸，在前端，DBA则需要不断向应用层面进行扩展。

那么DBA 2.0的使命大致就可以概括为：在不断完善的数据库管理工作之外，向更广阔体系层面延伸，包括应用（Application）、系统（System）、存储（Storage）、网络（Network）、架构（Architecture）等方面，为企业提供更深远的架构与决策支持，促进企业向更全面合理的可持续性IT架构方向发展。

这里所说的"不断完善的数据库管理工作"实际上是对DBA 2.0的一个深入要求，如果要延伸更广阔的领域，那么就必然要将数据库管理工作处理的游刃有余，我之前提到过的Proactive一词就是最核心的要求，只有更加主动的、具有预见性的对数据库进行维护和管理，才能将很多故障消弭于无形，也才能够达到数据库管理上的提高。

既然DBA 2.0意味着更广泛的层面介入，更深入的知识了解，那么Oracle也不断在加强自己的产品，来降低DBA工作的复杂度，加强数据库的稳定性与可靠性等。实际上通过不断的收购以及长期的布局，Oracle已经打造了以数据库为核心的全系列DBA辅助工具与产品。

比如，在最近的一次会议上，我了解到的Real User Experience Insight 产品，这是一款用于全方位监视实际用户活动的软件，用以确保基于 web 的应用程序性能能够达到期望水平；在达不到期望水平时进行分析和通知，并提供用户应采取相关措施的软件。下图是其原理图，从Page request到请求返回，所有流程的响应都将被记录用于预警和评估：

发件人 Oblog

这是我第一次了解到Oracle在应用监控方面的软件，实际上这是在前端、应用层向前迈进，这是Oracle的扩展策略之一。

而我此前曾经提到的Oracle Enterprise Manager产品（也即新版的Grid Control / Database Control）则是在数据库层面的巨大增强，Oracle一如既往不断在数据库层面加强其产品能力。下图是Oracle在从开发到产品所有阶段自顶向下的应用管理示意图（摘自Oracle官方演示文档），其中数据库层面的Diagnostic and Tuning产品，Provisioning，Configuration Management等产品都是来自OEM产品中的增强。

发件人 Oblog

而右侧关于应用测试阶段，Oracle也有了很多新的产品，这包括Real Application Testing（这是Oracle Database 11g中的功能，也整合在Oracle 10.2.0.4及之后的版本中），而Data Masking也是最新包含进OEM中的组件。
Data Masking我也是刚刚了解，这个组件在进行数据克隆时，可以对于生产数据进行转换来保护原来的敏感信息，但是仍然能够保持数据的完整关系用于真实的应用测试。这的确是一个不错的功能及组件。
在前几天召开的2008 北京甲骨文开发者大会上，我还了解到，现在Timesten居然也打包进了数据库产品，Oracle In-Memory Database Cache现在可以作为数据库的一个组件销售。

那么回过头来，DBA 2.0的时代，我们希望不再面临以前的情况：
数据库忽然变慢，客户投诉电话不断，DBA如同消防队员一样不断四处来扑灭冒起的火焰。。。。

DBA 2.0的时代，我们希望能够预见系统的变化，将问题消弭与无形。这就要求我们能够全面掌握数据库运行状况，作为一个DBA，我在团队中不断强调"数据库的全信息管理"模式，也就是要全面深入掌握数据库的运行状况，比如并发数量、负载概要、逻辑读与物理读变化等等，全面掌握这些信息并且适时监控，就能够见微知著的了解数据库的变化，并及早预测和解决可能出现的性能问题。
在这方面AWR的历史数据收集和记录给了我很大的帮助，OEM的诊断和SQL捕获为系统调优提供了便利，Oracle也在2.0的方向不断为我们解决难题。

在DBA 2.0的时代，Oracle的变化一如既往的非常快，要不断学习才能跟上Oracle与时代的要求！

在最初的文章里，我曾经提到过Grid/Database Control这个工具，这是Oracle Database 10g开始引进的基于浏览器的数据库管理、维护与监控工具，是OEM（Oracle Enterprise Manager）发展的一个新阶段。
不知道Oracle是基于怎样的考虑和讨论开始废除/舍弃了Oracle Database 9i年代的基于JAVA开发的客户端OEM工具（这个幕后的故事可能会非常有意思），也许是顺应B/S的潮流，也许是大势所趋。但是总之，Grid /Database Control的出现让人眼前一亮（也让很多第三方数据库管理工具厂商大感压力）。
新的OEM功能越来越强大，涵盖的范围也越来越广，Oracle的意图是将OEM逐渐演进成为一个全面的系统管理、维护与监控工具，不仅涵盖数据库，还要涉及系统、网络、存储等方方面面。
最近在使用11g的OEM过程中，发现关于主机方面的信息与监控越来越完善起来，比如关于负载、IO等信息的监控：

发件人 Oblog

而在Grid Control中，更广泛的信息会被监控和收集，比如应用的响应与处理时间等，通过进一步的下钻与分析，可以在不同层面对于性能问题进行分析和解读：

发件人 Oblog

虽然OEM还不能解决我们所有的问题，但是在日常工作方面，已经可以成为我们很好的助手。
我曾经在我的《循序渐进Oracle》一书中用了很大篇幅来介绍新版OEM的使用。OEM通过全面的监控部署，可以将曾经需要我们进行大量手工处理的工作自动来进行，以前需要很多脚本编写处理的工作，现在OEM可以内置的自动完成，我要说的是，这部分增强对于DBA具有普遍的价值。
比如在监控方面，我们可以定义各种各样的度量条件，当特定阈值达到时，触发报警：

发件人 Oblog

当然还要配置一些SMTP及邮件设置，此后如果数据库出现相关告警，我们的信箱就可以收到告警邮件，以下是几个邮件示例，当警告日志中出现错误或者设置的空间使用达到，自动邮件告警信息就会发出。

关于通用功能的增强，是OEM中非常重要的部分，因为这部分增强可以将DBA普遍需要进行的工作进行简化，实现用户效率的提升。
当然，OEM对于很多高级DBA的帮助也许有限，但是如果90%的Oracle数据库应用企业能够将OEM作为数据库的管理监控工作，那么数据库的管理和维护效率一定能够大大提高。我这里所说的90%的企业，也许根本没有专职的DBA，那么OEM将会是非常重要的助力。
OEM中很多特性也可以显著缩减资深DBA的工作量，我觉得OEM众多的PACK包中，对DBA价值最高的是以下两个：
1. Diagnostic Pack
诊断包通过数据库内建的自我诊断引擎来定位系统的性能瓶颈所在，并且给出相应的优化建议。
2. Tuning Pack
调整包对于指定的SQL自动进行优化，使之符合系统的性能要求。而哪些SQL需要优化，则完全可以通过制定性能目标来由Oracle自动从当前系统中抓取出来。

在OEM中，通过这两个工具包，DBA可以很容易的捕获并分析性能问题，并且可以参考数据库的建议进行改进！使用OEM进行问题SQL的捕获（注意，不要等待问题出现时才去关注，日常对于数据库的关注与监控尤为重要，也只有对数据库进行更全面的跟踪才能使DBA更具有预见性）与诊断变得非常快速与简便，这些变化甚至可以让对数据库仅有初步认识的人在解决数据库问题时也变得十分专业：