事件的起因是因为一封类似于公关稿的邮件，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的兼容能力就不奇怪了，但是对在这么短时间内就出现了成功迁移的案例，记者首先还是采取了怀疑的态度。
　　案例中进行后台数据库迁移的是一个名为“住房公积金信息系统”的项目，产品由江苏富深协通数码技术有限公司负责开发(http://www.finstone.com.cn/appmain.do)。此前，该项目已经在在江苏、湖南、青海、山东、安徽、湖北、宁夏等省的许多城市住房公积金管理中心成功应用，产品的用户规模已经达到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函数,在字符串里查找子串:
　　fl.dm like tb.dm 需要修改为
　　locate(tb.dm,fl.dm,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语句，对每个软件公司都是个很好的实力见证。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。