3天完成数据库迁移的真实性调查

摘要：Enterprise DB的山寨Oracle产品的数据库，大体上只落后甲骨文公司Oracle数据库主流版本约两年的时间，并且产品已经达到了用户所要求的所有主要功能。这就是IBM能看中这家公司并入股的主要原

关键词：数据库数据库迁移

事件的起因是因为一封类似于公关稿的邮件，7月底，一封标题为“3天完成迁移 富深协通公积金管理系统从Oracle数据库迁移到DB2 9.7”躺在记者的邮箱里。按照平时的习惯，记者可能随手就将其删除至垃圾箱，并将发信人作黑名单处理。

但碰巧的是，记者刚刚在6月底参加了DB2数据库最新版本9.7的发布会，尽管知道该产品有着诸多改进，特别是在对Oracle数据库的兼容性方面，采取了新的所谓“enable”的策略，而这些都源于IBM和开源的数据库厂商Enterprise DB的“亲密”合作。

搞数据库的朋友对Enterprise DB并不陌生，EnterpriseDB公司有两种版本的数据库，基本是从开源PostgreSQL数据库建立起来的。它们的口号是，将“山寨Oracle数据库进行到底”。

Enterprise DB公司的Postgres Plus Standard Server虽然是开源代码的硬件版本，但Advanced Server版不是开源项目，而是与甲骨文数据库兼容的版本。今年6月份，它们已经发布了与甲骨文兼容的第五个版，使得Postgres Plus Advanced Server可以模仿甲骨文的数据库，因此说它是山寨Oracle产品也毫不为过。

这个数据库究竟能“山寨”Oracle数据库到什么程度呢?说出來大部分人都不会相信，尽管他们对Oracle数据库的某些特殊版本不会去模仿，但对其兼容涉及的不仅是特性，而且还有数据库活动的方式，甲骨文数据库的外部交易控制以及错误条件都被仿效。因此不仅程序员不知道其中的差别，而且数据库管理员也不知道有何不同。

据记者了解，Enterprise DB的山寨Oracle产品的数据库，大体上只落后甲骨文公司Oracle数据库主流版本约两年的时间，并且产品已经达到了用户所要求的所有主要功能。这就是IBM能看中这家公司并入股的主要原因，也就是说，IBM公司能够完全获得Enterprise DB对Oracle数据库兼容层的代码，并使之纳入到DB2产品线中去。

迁移的原因

有了这样的合作背景，你可能会觉得DB2 9.7对Oracle的兼容能力就不奇怪了，但是对在这么短时间内就出现了成功迁移的案例，记者首先还是采取了怀疑的态度。

案例中进行后台数据库迁移的是一个名为“住房公积金信息系统”的项目，产品由江苏富深协通数码技术有限公司负责开发(。此前，该项目已经在在江苏、湖南、青海、山东、安徽、湖北、宁夏等省的许多城市住房公积金管理中心成功应用，产品的用户规模已经达到40余家地级市和10余家行业用户。

据了解，富深协通数码技术有限公司在住房公积金管理行业大约有15年的开发经验和背景,从94年推出FoxPro版本，97年推出基于Sybase、Sql Server版本，99年推出基于Sybase、SQL Server、Oracle版本，一直在不断扩展和改进，使得系统能符合在多种平台部署的要求，这次转换数据库平台部分原因正是基于此因素考虑的。

数据库平台的迁移，对现有的生产系统有着巨大的风险并会带来成本的压力，对此DBA和业务人员无不闻之生畏。那究竟是哪些因素促使富深协通要迁移自己的后台数据库平台呢?

该公司开发经理陈胜在接受记者采访时表示，随着业务量、数据量的上升，服务器由windows系统发展到Unix环境，数据库由sql到sybase，再到oracle，再有移植至DB2,主要因素由以下几点：第一，为了进一步提升公积金软件产品在住房公积金领域的核心竞争力，增强产品功能;第二，为适应最新的市场的需求，按照用户的具体要求及硬件环境，提供更贴近用户实际要求的解决方案;第三， DB2数据库的不断发展，新特性功能，跨不同数据库的移植才有了底层支持，通过公司与IBM的合作可以进一步推动其数据库产品在公积金行业上使用。

另外，记者采访中了解到，行业的IT部门包括政府也意识到，后台数据库架构进行平衡和分散部署，也有利于降低风险和节省服务成本。原先核心系统如果是基于Oralce数据库的，开发其它业务应用时，就会考虑部署在DB2，或者SQL Server甚至时开源的数据库平台上。

迁移 有时就是这么简单

记者采访中了解到，该系统最新的B/S结构版本中有300多个存储过程，代码量接近10万行。另外还有大量嵌入在应用程序中的SQL语句，也在1万个左右。难道在迁移过程中就没遇到兼容性问题?又是如何解决的?

“DB2 9.7能兼容95% Oracle语法，大多数情况下原来的ORACLE SQL无需改变即可使用。这一点出乎我们意料之外，也给我们的迁移工作带来惊喜。” 陈胜告诉记者。

“不过，我们还是发现了大约5%的兼容性问题，主要体现在SQL及特性用法上的迥异。相对而言,Oracle原生PLSQL的语法相对灵活点，DB2 PLSQL兼容性语法相对要严格点。”他说

为帮助其它有迁移需求的技术人员，记者将他们在迁移过程中出现问题的SQL语法列出。问题对照Oracle使用情况汇总如下：

1、 Like 语句：

DB2 ：like操作的第二个表达式不能包含列名

对于程序中有这样操作的SQL语句需要进行调整

解决方法:使用locate函数,在字符串里查找子串:

like 需要修改为

locate(,,1) =1,如果两边都有%,判断条件改为 > 0

2、Having 、GroupBy 、SubSelect 语句:

DB2 规定：使用Having语句前， Group By 必须放其之前;

GroupBy 前的数据列必须要有对照的分组表达式;

在update 语句中，子查询只能返回一个列;

3、Function :

DB2 ：参数中不能允许有 out 类型的参数;除表函数以外的函数体中不允许对数据 进行新增、修改、删除操作;谨慎的使用递归调用

4、Trigger

DB2 : 行级触发动作条件UPDATE 及 INSERT,必须单独使用即需要新建各自的触发器，不能写在一起;如在触发动作中有对其他表的DML操作,必须指定为AFTER触发,不能指定BEFORE前触发

“由于用的DB2 9.7的新特性，迁移工作相当的顺利，3天之内便完成了表结构移植和存储过程编译，之后主要的时间都用在功能测试和个别代码调整。”

根据陈胜的介绍，公积金管理系统总计3周时间已经形成稳定版本。移植到最新版DB29.7相比移植至DB2 9.5而言，效率有几十倍的提高。

“显然，能这样快速低成本的迁移，肯定能为我们公司赢得更多的市场时间，为我们的业务拓展了更广阔的空间，带来了更多的机遇，也使我们的产品更具有竞争力。”

数据库选型建议及经验分享

当记者问到，作为有着迁移经验的技术主管，您对其它有意迁移的客户有哪些技术方面的建议?

陈胜：对于新开发的系统而言，需要充分考虑自身应用与各数据库兼容性问题，不能绑定到特定的数据库，应用程序中，尽量避免SQL分散至应用系统各个角落，对SQL语句统一进行管理，在满足系统性能的前提下，尽量使用ORM工具, 来屏蔽不同的数据库原生SQL的实现。能快速的按照用户需求,进行配置，以完成数据库迁移，就能有效的减少这个项目具体实施时间，大大的提高效率。

对于已有系统尽量不要使用特定数据库的专有特性，尽量使用标准的SQL写法。从Oracle迁移至DB2 9.7，已经没什么大的障碍，在满足数据库性能的前提下，系统只需进行少量的微调,就可顺利完成两种数据库之间的迁移工作,DB2 9.7还有很多别的新特性，还是很值得Oracle用户去尝试体验的。

记者：作为在一线的ISV，您认为软件项目和产品开发，在后台数据库系统技术选型时，必须考虑那些因素?为什么?

陈胜：后台数据库的选型,一般需要考虑以下几个问题：

1、数据库平台要求，数据的处理性能如何？

要看具体的用户场景，就拿我们的公积金行业来说，一般都是Unix或者Linux环境下的，这就要求数据库运行环境，必要要支持这样的操作系统。对于几百万的基础数据，上千万的流水数据，这样的数据在规定时间内完成检索及返回，这就对数据库IO读写能力提出很高的要求。

2、数据库厂商的支持程度如何，发展及升级前景如何？

我们不能保证，各个数据库产品都是完美的，没有瑕疵，往往数据库厂商自己也不能保证，推出新的产品，我们希望在数据库出现意外情况时，厂商的能尽早的提出解决方案。

3、我们相关的开发人员，熟悉程度如何？

这点就不用多说的，要是我们每个开发人员，闭眼就能写好SQL语句，对每个软件公司都是个很好的实力见证。

责编：

济宁西服制做

做服装

青岛防静电工服定制