[转载]税务行业数据库管理问题探讨 （二）

眉柳

刚到新公司，一个从Windows 3.1阶段就开始编程序的老DBA跟我聊天的时候说，“看到一个新手简单地跑了一下ADDM报告，然后根据建议添加了几个索引，系统的性能就直线上升时，还真是挺恨这个工具的，这让我们在何处体现价值呢”，当然，“数据库工具的越来越智能化是否意味着DBA技术含量的越来越平民化”这个话题还可以更深入地讨论，只不过不是在本文范围内了。在这里提到这段聊天，仅仅是为了表明OEM10g早已不是之前OEM9i时候的那样一个食之无味弃之可惜的鸡肋产品了，它已经成功进化为一个极具竞争力的IT系统管理监控调优工具。而ADDM报告仅仅是OEM中的一小部分而已。


OEM10g目前最新版本是10.2.0.4，基本上的架构如下：





在一台服务器上安装OMS，然后其他需要被管理的数据库上安装OEM Agent，这样从任何一个能够连接到OMS服务器的浏览器中都可以直接管理所有安装了Agent的数据库，甚至是主机，应用服务器。


因为是Web界面形式，只需要浏览器就可以实施管理功能，不再像一些第三方产品那样必须要在管理终端上安装一个特定的客户端软件。这对于管理人员来说，是一个解放。





OEM10g在功能上包含6个Pack，分别是：


1. Data Masking Pack
数据遮蔽包用于对包含敏感信息的测试数据进行遮蔽，有多种规则可以制定，通过简单高效的操作可以生成大量具备真实数据效用的但是又不是真实数据的测试数据。

2. Diagnostic Pack
诊断包通过数据库内建的自我诊断引擎来定位系统的性能瓶颈所在，并且给出相应的优化建议。

3. Tuning Pack
调整包对于指定的SQL自动进行优化，使之符合系统的性能要求。而哪些SQL需要优化，则完全可以通过制定性能目标来由Oracle自动从当前系统中抓取出来。

4. Change Management Pack
在升级应用的时候，变更管理包可以实现对于数据库中元数据的“逆向工程”，并且提供对象和Shcema的比较以及同步。

5. Configuration Management Pack
配置管理包收集企业中所有指定主机系统的详细配置信息。系统信息清单存储在 Enterprise Manager 信息库中，是 Enterprise Manager 的配置管理系统的基础。允许管理员快速分析与其系统相关的信息。同时也提供历史变更追踪报告。

6. Provisioning Pack
提供对于操作系统，数据库，应用系统的自动升级或者打Patch服务。同时也提供在RAC环境中添加或者删除节点的便捷操作。


在10g企业版数据库中其实已经包含了其中的几个Pack，比如AWR，ADDM就是Diagnostic Pack中的内容，SQL Tuning Advisor就是Tuning Pack中的内容。就纯粹的License上来说，如果你没有购买OEM的相应Pack，仅仅是购买了企业版数据库的License的话，那么你是没有权力使用AWR或者ADDM或者SQL Tuning Advisor的，即使是它们确实已经包含在企业版软件中了。


回到税务行业，看看OEM10g的这6个Pack是否对于当前税务系统的现状有所帮助。


1. 目前看来，税务行业所有的测试环境仍然都是在使用真实数据的，所以在这个层面上来说，数据安全性几乎为零，而数据安全性对于税务行业来说，无疑是至关重要的。如何保证在测试数据库中不存在真实数据，而又能让测试数据库体现真实数据的分布状况和数据特性？这是正是Data Masking Pack的用武之处。
至于如何在产品环境中进一步保证数据的安全性，这就牵涉到Oracle在数据安全领域另外的产品，比如Database Valut和Audit Valut以及Advanced Security功能，这将会是另外一篇文章。


2. 其实在税务行业少数的几个10g数据库中，AWR报告和ADDM报告已经在使用了，只不过并没有成为一个通用的数据库诊断标准而已。我想，这方面不用多说了，谁用谁知道，AWR和ADDM的强大，让我们完全可以抛弃9i中的statspack。只需要几次点击，就会告诉你系统现在的性能瓶颈在何处，并且根据Oracle原厂对于自己数据库的理解和汇集了十数年的专家诊断经验提供出来的性能优化方案已经基本上可以解决大多数的问题了。


3. 我们知道，一个应用系统的性能有超过80%的可能性是由于不良SQL导致的，而在这之前SQL调优是一项很具有挑战性和技术性的工作，需要DBA丰富的经验同时也需要对于行业应用特性的深入了解。而且，对于税务行业，老实说，我并没有看到哪个省份有专门的DBA来负责SQL的调整，这些SQL的问题都是由各个系统的开发厂商自己去调整的，但是实际上在系统上线之后，开发厂商自己的DBA几乎都已经撤离现场，因此如何调整上线之后出现问题的SQL，不但在技术上，而且在工作流程上都是一件繁琐的事情。现在调整包的出现，极大地降低了DBA在这方面的工作强度。


4. 我亲自经历的案例，就是在某次关键应用升级之后，测试环境和产品环境索引结构不一致（升级人员在跑某个脚本的时候出错了，但是他并没有注意到）导致产品环境性能急剧下降，那次是一次痛苦的通宵加班找寻问题根源的经历。而税务行业应用的升级频率，却是可以用频繁这个词来形容的，难道我们不需要变更管理包吗？


5. 今天是HP Superdom，明天是IBM P570，后天可能又变成了P595；今天是64G内存，明天可能就是128G内存；今天打了一个操作系统的补丁，明天打了一个数据库补丁，后天又把那个补丁卸载了；调整的过程中，某人改了数据库这个参数，第二天又改了那个参数。这样的事情在税务行业并不少见。我也经常在现场听到IT部门的处长对底下的系统管理员再三强调，所有的修改都必须要有文档记载。但是，谁来监控这些配置的变更，谁来管理，文档又该是什么样的格式，又能保存多久？有了配置管理包，这些工作将变得简单很多。


6. 无需讳言，Oracle数据库的bug确实不少，给众多的数据库一一打patch也是极为头疼的事情，在现场，我仅仅是为一个两节点的RAC数据库打上所有的recommended patchset，就已经熬到两眼通红，精神也高度紧张。这还只是运行opatch而已，那么随着业务的发展，需要向现有的RAC环境中添加节点呢？我相信那大概只能由原厂商的工程师出马了，如果是全国所有省份的核心系统都要增加节点呢？恐怕计算一下成本的话，Provisioning Pack也并不是那么贵了。


之前我在OCM考试指南的文章中也屡次提到了Grid Control，Oracle最高等级的认证考试也将是否能够熟练使用OEM作为一个考核标准，由此可见Oracle对于OEM产品的重视，同时也体现了OEM10g的可用性，一个不那么优秀的产品怎么能去胜任Oracle最高等级的考试标准呢？


既然Grid Control是Oracle10g之后才推出的概念，那么利用Grid Control+OEM是否可以管理10g之前的数据库呢，比如税务系统，目前基本上仍然是Oracle9i数据库。答案是肯定的，而且不但能够管理9i数据库，甚至可以管理8.1.7.4版本的8i数据库。

[ 本帖最后由 doni 于 2009-3-19 16:08 编辑 ]