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

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

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

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

因为各省市系统均由国税总局统一管理，因此在税务行业有个比较好的特点，就是基本上各省市的系统都是相差不多的，除了几个特殊省份（比如上海，天津，西藏等），对于税务行业来说，核心系统包括综合征管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部门供职的技术人员提出自己的意见和看法。