税务行业数据库管理问题探讨 (二)

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

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

From Drop Box

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

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

From Drop Box

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数据库。

后面一篇文章将继续介绍如何利用OEM10g管理Oracle9i数据库,并且更详细地,如何将9i的statspack报告整合到OEM10g中去。

税务行业数据库管理问题探讨 (一)

这两年在客户那里接触最多的行业是税务,几乎跑遍了大江南北的国税和地税,结交了很多朋友,在跟他们一起探讨问题的同时,也对税务的业务系统有了大致的了解。

趁着这段还比较闲的时间,尝试总结一下对于税务行业数据库系统管理方面的了解和建议。

先声明一点,以下提到的任何“管理”词语均指业务系统的管理而非组织架构。

首先,税务行业是由国税总局垂直管理的,自上而下,基本上所有业务系统的规划,相关硬件的购置,软件技术的选型,服务厂商的选择,都由国税总局统一管理。之前,各省市地税还基本上处于自己管理自己的局面,但是本着“国地税不分家”的原则,近一年来,各省市地税也逐渐纳入国税总局的管理范围内。

因为各省市系统均由国税总局统一管理,因此在税务行业有个比较好的特点,就是基本上各省市的系统都是相差不多的,除了几个特殊省份(比如上海,天津,西藏等),对于税务行业来说,核心系统包括综合征管CTAIS、稽核、协查、车购税、货运发票等,另外外围系统如网上报税等。由于系统架构的相同和统一规划之后的系统实施(比如所有由Oracle原厂商安装的数据库系统在各个省市安装路径,数据库实例名称均是完全相同的),因此在各省市帮助解决问题的时候,经验是互通的,大大减少了问题诊断的时间,也提高了解决问题的效率。

当然,目前税务系统在数据库层面也同样存在着不足。

1. 数据库实例过多,资源浪费
目前的状况是,这些系统后台均是单独的数据库实例,基本上都是Oracle9i RAC,即使是如同车购税这样负载很小的系统也同样运行在单独的一套RAC中。多套RAC的同时运行无疑很大地增加了数据库管理员的工作量,曾经在某个省市见过系统管理员每天上班要做的事情是,将各个机器的terminal终端依次打开,然后运行检查的脚本,满屏幕的终端窗口,密密麻麻的脚本输出结果,管理员挨个检查一遍,确认所有数据库服务器都没有问题之后,再去检查应用服务器,而每套数据库服务器前端通常接着3到5套Weblogic Server,这项工作极为繁琐,同时也很容易产生检查的遗漏,甚至会由于疏忽产生不可预知的误操作。作为甲方的IT系统管理人员其实应该更加深入业务层面而非过多地被局限在纯技术方面,这样才能有时间去考虑怎样以更大的灵活性、更好的服务质量以及更低的运营成本来获得更安全的系统质量。

之前我们一直建议尽量缩减数据库实例数,综合征管CTAIS作为最核心的系统可以享用一个双节点RAC,其它的系统可以全部放入一个多节点(比如三节点或者四节点)的RAC中,以数据库Schema来区分各个应用需要的数据。这样做的好处,是减少了多份单独实例的管理工作,同时由于实例数的减少,也同时减少了数据库服务器硬件的投资,绝对是值得尝试的方法。

但是,由于各个应用厂商之间协调的问题,每个应用厂商都怕其它厂商的应用跟自己跑在一个数据库中,可能会产生自己无法完全控制的问题,多次会议也仍然没有结果。税务系统还是保持着目前的现状。

2. 使用的技术及产品趋于保守
由于总局统一管理,自上而下的推行系统实施,不可避免地会考虑更多,也就更趋向于保守,因此目前基本上所有省份的关键应用也都仍然运行在9i版本的数据库上,并且近期内也还没有看到有升级到10g的计划,这在获得Oracle原厂商的技术支持方面也存在着隐患。

另外由于历史原因,应用中存在着大量通过物化视图刷新来获得其它数据库实例中数据的方法,在较复杂的情况下,一个产品库将应对两到三个物化视图站点的大数据量表的增量刷新。

当然,也知道,全国所有系统的升级并不是简单的事情,需要从长计议。

那么,对于这两项弊端,如何在不冒更大风险的前提下,又能达到方便、快捷、有效管理所有数据库的目的呢?单靠数据库管理员或者系统管理员的个人能力去管理,恐怕对于税务系统这种人员众多,技术高下参差不齐的政府行业来说有些强人所难。我们需要一个工具,而这份工具最好应该具备以下这些特点。

1. 可以在统一的界面中管理多个数据库,甚至是多个版本的Oracle数据库,从8i一直到11g。
2. 除了管理之外还有实时监控的功能。
3. 除了监控之外还有智能分析系统瓶颈并且给出优化建议的功能。
4. 应该能够从任何机器上远程登陆,而不是需要在某台机器上安装一个臃肿的客户端才能使用。
5. 除了管理Oracle数据库之外,还可以管理整个IT系统中其它的多项资源,比如系统主机(Unix),其它数据库(SQL Server),应用服务器(Weblogic),网络(F5)等。
6. 应该拥有良好的架构,可以通过插件的形式方便地扩展管理内容。

好吧,现在我们有这样一个备选的产品,它不但满足以上所有需求并且是Oracle原厂出品 – Oracle Enterprise Manager。谁更了解oracle数据库,谁更能在管理oracle数据库上给出建议,无疑是Oracle公司自己,让其它的产品都见鬼去吧。我很喜欢这样的风格。:) 实际上,正是拥有了OEM10g的这部分功能,Oracle10g数据库才被宣传为一个self-managing database。

Grid Control + OEM不但能够带来管理oracle数据库的便利,同时又能在同样的界面内管理整个IT环境中的其它资源,eygle有说一个DBA 2.0概念,其中提到了Database Control,我们可以认为Database Control是Grid Control的单机版,每个Database Control只可以管理本机的这个数据库实例,而Grid Control则作为单独的服务存在,能够管理企业内部几乎所有的数据库系统和其它IT资源。这就是Manage many as one的理念。同时,在Grid时代,Oracle还有一个Proactive management的理念,更主动,更具有预见性地管理IT系统的资源,这不仅仅是对于Oracle数据库管理员的要求,同样是对于管理现今越来越复杂的整体IT系统环境的要求。

我们可以认为Grid Control是一个概念或者说一个理念 – 网格控制,体现在真正的产品上则是Oracle Enterprise Manager,就是OEM,目前的版本是10g,因此又称为OEM10g或者EM10g。当然,有时候我们又会直接称呼EM10g的OMS(Oracle Management Server)为Grid Control,因此在下文中出现的Grid Control或者OEM10g,如果没有特殊说明,都指的是OEM这个产品。

下一部分将结合税务行业的现状分析一下能够从OEM10g中获益的部分。

BTW:欢迎各位在税务行业IT部门供职的技术人员提出自己的意见和看法。