Yearly Archives: 2008

刚到新公司，一个从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…

这两年在客户那里接触最多的行业是税务，几乎跑遍了大江南北的国税和地税，结交了很多朋友，在跟他们一起探讨问题的同时，也对税务的业务系统有了大致的了解。 趁着这段还比较闲的时间，尝试总结一下对于税务行业数据库系统管理方面的了解和建议。 先声明一点，以下提到的任何“管理”词语均指业务系统的管理而非组织架构。 首先，税务行业是由国税总局垂直管理的，自上而下，基本上所有业务系统的规划，相关硬件的购置，软件技术的选型，服务厂商的选择，都由国税总局统一管理。之前，各省市地税还基本上处于自己管理自己的局面，但是本着“国地税不分家”的原则，近一年来，各省市地税也逐渐纳入国税总局的管理范围内。 因为各省市系统均由国税总局统一管理，因此在税务行业有个比较好的特点，就是基本上各省市的系统都是相差不多的，除了几个特殊省份（比如上海，天津，西藏等），对于税务行业来说，核心系统包括综合征管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）等。…