3.4 移植方案
达梦数据库是我公司推出的高性能数据库产品。它具有开放的、可扩展的体系结构，易于使用的事务处理系统，以及低廉的维护成本。达梦数据库是自主开发的产品，具有完全自主版权和较高的安全级别。达梦数据库可以跨越多种软硬件平台，具有大型数据的综合管理能力，是高效稳定的国产数据库管理系统。
不同的关系数据管理系统之间存在结构差异，Oracle、SQL Server和本产品都对SQL-92标准做了许多自有的扩展。系统移植过程中面临的最重要的问题是执行SQL-92语言标准和每一个关系数据管理系统提供的语言扩展。有一些开发人员只使用标准的SQL语法，喜欢尽可能的保持他们的程序代码的普遍性。通常，这种方法把程序代码限制在SQL-92标准的登录级别（Entry-Level）上，而这个级别是被许多的数据库产品实现了的，包括Oracle和本产品。
这种方法将会产生一些不必要的程序代码复杂性而且还会对程序的性能造成很大的影响。例如，Oracle、本产品的DECODE函数、CASE表达式是一个非标准的SQL扩展。私有开发接口的使用带来了新的问题。用Oracle OCI（Oracle Call Interface）进行程序转换通常需要很多资源。开发一个可能用到多个关系数据管理系统的应用程序，最好是考虑使用标准数据库接口如ODBC、OLEDB、JDBC等。
从应用程序开发的观点来看，Oracle和本产品是以相似的方法来管理数据的。在Oracle和本产品之间有着一定的内部区别，但是如果管理得当，可以把这些区别对移植的影响减到最小。
3.4.1 移植步骤
达梦数据库系统的移植通常采用以下几个步骤进行。 1、分析系统
分析系统的目的在于了解系统，判断系统移植的工作量及确定移植工作的重点和方案，主要包括以下一些内容：
(1) 后台操作系统是什么及其版本信息，Windows、Unix、Linux等。
(2) 后台数据库是什么及其版本信息，是SQL Server、Oracle、Informix还是其它。 (3) 前台开发工具是什么及其版本信息，是.NET、JBuilder、Delphi还是其它。 (4) 应用系统采用了什么开发模式，C/S还是B/S模式。
(5) 应用系统使用的接口，常用的如ODBC、OLEDB、JDBC；如果是采用通用的接口，重点将转向后台数据库的移植；如果是采用一些特别的专用接口如OCI、API或者自定义的接口标准，则需要进行相关接口的开发，这时候移植工作重点将转向接口的开发上面来。
(6) 相关的一些开发组件及其版本信息。
(7) 相关的运行环境及其版本信息，如Tomcat、.NET Framework等。 (8) 是否用到第三方的开发工具和平台，如SuperMap等。
46
(9) 数据库的相关信息，主要有几个库，这些库之间的关系。
(10) 涉及到的数据类型，常规的如CHAR、VARCHAR、INT等，这些各种数据库一般都支持，如果系统用到了如日期、时间、时间戳、文本、图像等类型，在移植的时候需要注意各种数据库之间的一些差异，主要是关注长度、精度、标度信息，有时候需要做些类型转换，如在Oracle中的VARCHAR(8000)，在本产品中可考虑将其转换成TEXT类型或采用16KB以上的建库模式加以解决。
(11) 注意表的定义信息，主要是关注自定义的数据类型、自定义的缺省值，因SQL Server等数据库可创建自定义的数据类型和自定义的缺省值，而使用本产品的DTS工具无法将这些信息转换出来，需要在原系统中查找。
(12) 是否使用到了视图、存储过程、存储函数、触发器、序列等；如果没有使用到这些，后台数据库的移植工作将主要是进行数据迁移；如果用到了这些，且数量较多，后台数据库的移植工作将是脚本的移植转换工作。
(13) 是否用到了后台数据库的系统字典，因各数据库的系统字典格式和内容均不一样，这时候需要分析原数据库的系统字典的涵义，只能根据使用的实际情况作相应的处理。
(14) 系统的运行规模和效率要求，如并发访问量，使用的频度，时间响应要求，主要是确定优化的方案，如果要求不高，优化的时候主要是采用创建索引的方法，如果要求较高，可考虑采用改写SQL语句的方法来进行，甚至考虑改写程序逻辑。
(15) 是否有其它的特别的要求，如安全控制、双机热备、数据同步等，如果有这些要求，移植工作的重点和难点将转向这些问题的解决。
2、确定方案
在分析了系统之后，应确定移植的重点和难点，并确定移植方案。
首先应确定系统移植工作的主承担方，即以应用软件开发商为主还是以数据库供应商为主；如以应用软件开发商为主，则数据库供应商应提供该数据库的技术支持服务，主要负责和承担数据库差异的解释工作；如以数据库供应商为主，则应用软件开发商则应提供对应用系统比较熟悉的技术人员配合移植工作。
一般来讲移植工作分为后台数据库的移植和前台应用系统的移植。
3.4.1.1 搭建环境
搭建环境包括搭建原系统运行环境和新系统环境，便于后续做功能和性能对比测试。
3.4.1.2 系统移植
数据库系统移植主要包括功能移植、功能测试和效率优化。在功能移植的过程中，保持一个原则就是不改变其应用逻辑，因为在功能移植的阶段重点是在解决系统差异上面，如果过多的考虑应用逻辑问题，移植工作的进度将会受到影响，也增加了移植工作的难度，同时如改变应用的程序逻辑，将存在功能修改错误的风险。
在进行后台数据库移植的时候，最好找一个比较方便操作，便于进行内容查找、内容
47
替换和差异对比的编辑工具，如使用Vc的编辑器，Beyond Compare等工具，也可以辅助使用版本控制工具，如CVS等，因为移植过程中需要经常进行修改，这些工具可起到一个很好的辅助作用。
后台数据库的移植工作主要是脚本的移植和数据迁移工作。一般采用的顺序是先进性脚本的移植，再进行数据的迁移，这样做的好处主要有以下的几点：
(1) 整理好脚本之后，便于快速搭建移植环境。
(2) 有了脚本文件，能够对系统有一个整体的了解，便于对系统的把握。 (3) 容易进行相应的特殊处理，如缺省值、类型、主键、外键等的处理。 (4) 便于存储模块的移植。 (5) 便于优化系统等。
当后台数据库中用到的存储模块、触发器等较多的时候，并且脚本长而复杂，这时候最好进行多人合作。
前台系统的移植主要是连接串的修改，一些差异的修改，如SQL参数的处理等，因应用系统千变万化，只能具体情况具体对待。
在移植的过程中注意做好修改记录，便于分析查找问题。 5、系统测试
功能移植完成之后，需要进行一个完整性测试，主要包括功能测试和性能测试，测试的目的如下：
(1) 测试功能是否正确，一是看程序能否执行，而是看结果是否正确，如果不对，可跟踪本产品日志，分析问题产生的原因进行相应的修改。
(2) 测试执行效率，将用户反映慢的地方记录下来，效率优化的时候进行处理。 功能测试一般采用黑盒测试的方式进行，按照系统的功能点进行逐一测试，并做好测试记录，测试主要考察功能测试点是否能够正常执行同时要考察测试结果数据是否正确。
在进行性能测试前，可使用自动化的测试工具，加大测试数据量。性能测试在于找出系统运行慢的地方，做好相关的记录，性能测试可以辅助采用一些自动化的工具，如Loadrunner等；根据需要，也可以编写一些有针对性的测试用例，加强系统性能测试。
6、错误修改
针对前面记录的功能问题进行修改，并进行回归测试。 7、性能调优
针对前面记录的性能问题，可跟踪系统实际运行的SQL语句，分析SQL语句组成、功能和相关的表，建立合适的索引一般能解决性能问题；如有必要，也可采用改写等价SQL语句的方法进行。
8、移植验收
提交功能、性能测试报告，提请系统移植验收。
48