ORACLE 数据库向 DM 的移植
达梦数据库有限公司
1
www.dameng.com
目 录
ORACLE 数据库向
DM 的移植............................................................................................................1
1. 数据库系统移植概述..........................................................................................................3
2. 系统移植的基本步骤...........................................................................................................3
2.1 分析系统....................................................................................................................3
2.2 确定方案....................................................................................................................5
2.3 搭建环境....................................................................................................................5
2.4 系统移植....................................................................................................................5
2.5 系统测试....................................................................................................................6
2.6 错误修改....................................................................................................................6
2.7 性能调优....................................................................................................................7
2.8 移植验收....................................................................................................................7
3. Oracle 到 DM
的 SQL 移植要点............................................................................................7
3.1 数据类型的对比........................................................................................................7
3.2 临时表的对比............................................................................................................7
3.3 游标定义的对比........................................................................................................8
3.4 视图的定义的对比....................................................................................................9
3.5 过程以及函数的定义的对比..................................................................................10
3.6 引用变量方面的对比..............................................................................................12
3.7 系统函数的对比......................................................................................................12
3.8 关于在移植过程中要注意的细节问题
..................................................................12
武汉 上海 北京 广州 海南 南宁 合肥 江西 |
2
技术服务电话：400 648 9899
1. 数据库系统移植概述
不同的关系数据管理系统之间存在结构差异，Oracle、SQL Server 和 DM 都对
SQL-92
标准做了许多自有的扩展。系统移植过程中面临的最重要的问题是执行 SQL-92 语言标
准和每一个关系数据管理系统提供的语言扩展。有一些开发人员只使用标准的 SQL语法，
喜欢尽可能的保持他们的程序代码的普遍性。通常，这种方法把程序代码限制在
SQL-92
标准的入门级别（Entry-Level）上，而这个级别是被许多的数据库产品实现了的，包
括 Oracle 和 DM。
这种方法将会产生一些不必要的程序代码复杂性而且还会对程序的性能造成很大
的影响。例如，Oracle、DM
的 DECODE 函数、CASE 表达式是一个非标准的 SQL 扩展。私
有开发接口的使用带来了新的问题。用 Oracle OCI（Oracle Call Interface）进行程
序转换通常需要很多资源。开发一个可能用到多个关系数据管理系统的应用程序，最好
是考虑使用标准数据库接口如 ODBC、OLEDB、JDBC 等。
从应用程序开发的观点来看，Oracle 和 DM 是以相似的方法来管理数据的。在 Oracle
和 DM 之间有着一定的内部区别，但是如果管理得当，可以把这些区别对移植的影响减
到最小。
2. 系统移植的基本步骤
数据库系统的移植通常采用以下几个步骤进行。
2.1 分析系统
分析系统的目的在于了解系统，判断系统移植的工作量及确定移植工作的重点和方
案，主要包括以下一些内容：
1) 后台操作系统是什么及其版本信息，Windows、Unix、Linux 等。
2) 后台数据库是什么及其版本信息，是 SQL Server、Oracle、Informix
还是其它。
3) 前台开发工具是什么及其版本信息，是.NET、JBuilder、Delphi
还是其它。
4) 应用系统采用了什么开发模式，C/S 还是 B/S 模式。
www.dameng.com
5) 应用系统使用的接口，常用的如 ODBC、OLEDB、JDBC；如果是采用通用的接口，
重点将转向后台数据库的移植；如果是采用一些特别的专用接口如 OCI、API 或者自定
义的接口标准，则需要进行相关接口的开发，这时候移植工作重点将转向接口的开发上
面来。
6) 相关的一些开发组件及其版本信息。
7) 相关的运行环境及其版本信息，如 Tomcat、.NET Framework 等。
8) 是否用到第三方的开发工具和平台，如 SuperMap 等。
9) 数据库的相关信息，主要有几个库，这些库之间的关系。
10) 涉及到的数据类型，常规的如 CHAR、VARCHAR、INT 等，这些各种数据库一般
都支持，如果系统用到了如日期、时间、时间戳、文本、图像等类型，在移植的时候需
要注意各种数据库之间的一些差异，主要是关注长度、精度、标度信息，有时候需要做
些类型转换，如在 Oracle 中的 VARCHAR(8000)，在达梦数据库中可考虑将其转换成 TEXT
类型或采用 16KB 以上的建库模式加以解决。
11) 注意表的定义信息，主要是关注自定义的数据类型、自定义的缺省值，因 SQL
Server 等数据库可创建自定义的数据类型和自定义的缺省值，而使用达梦的 JDTS 工具
无法将这些信息转换出来，需要在原系统中查找。
12) 是否使用到了视图、存储过程、存储函数、触发器、序列等；如果没有使用到
这些，后台数据库的移植工作将主要是进行数据迁移；如果用到了这些，且数量较多，
后台数据库的移植工作将是脚本的移植转换工作。
13) 是否用到了后台数据库的系统字典，因各数据库的系统字典格式和内容均不一
样，这时候需要分析原数据库的系统字典的涵义，只能根据使用的实际情况作相应的处
理。
14) 系统的运行规模和效率要求，如并发访问量，使用的频度，时间响应要求，主
要是确定优化的方案，如果要求不高，优化的时候主要是采用创建索引的方法，如果要
求较高，可考虑采用改写 SQL 语句的方法来进行，甚至考虑改写程序逻辑。
15) 是否有其它的特别的要求，如安全控制、双机热备、数据同步等，如果有这些
技术服务电话：400 648 9899
要求，移植工作的重点和难点将转向这些问题的解决。
2.2 确定方案
在分析了系统之后，应确定移植的重点和难点，并确定移植方案。
首先应确定系统移植工作的主承担方，即以应用软件开发商为主还是以数据库供应
商为主；如以应用软件开发商为主，则数据库供应商应提供该数据库的技术支持服务，
主要负责和承担数据库差异的解释工作；如以数据库供应商为主，则应用软件开发商则
应提供对应用系统比较熟悉的技术人员配合移植工作。
一般来讲移植工作分为后台数据库的移植和前台应用系统的移植。
2.3 搭建环境
搭建环境包括搭建原系统运行环境和新系统环境，便于后续做功能和性能对比测
试。
2.4 系统移植
数据库系统移植主要包括功能移植、功能测试和效率优化。在功能移植的过程中，
保持一个原则就是不改变其应用逻辑，因为在功能移植的阶段重点是在解决系统差异上
面，如果过多的考虑应用逻辑问题，移植工作的进度将会受到影响，也增加了移植工作
的难度，同时如改变应用的程序逻辑，将存在功能修改错误的风险。
在进行后台数据库移植的时候，最好找一个比较方便操作，便于进行内容查找、内
容替换和差异对比的编辑工具，如使用 Vc 的编辑器，Beyond Compare 等工具，也可以
辅助使用版本控制工具，如 CVS 等，因为移植过程中需要经常进行修改，这些工具可起
到一个很好的辅助作用。
后台数据库的移植工作主要是脚本的移植和数据迁移工作。一般采用的顺序是先进
性脚本的移植，再进行数据的迁移，这样做的好处主要有以下的几点：
1) 整理好脚本之后，便于快速搭建移植环境。
2) 有了脚本文件，能够对系统有一个整体的了解，便于对系统的把握。
www.dameng.com
3) 容易进行相应的特殊处理，如缺省值、类型、主键、外键等的处理。
4) 便于存储模块的移植。
5) 便于优化系统等。
当后台数据库中用到的存储模块、触发器等较多的时候，并且脚本长而复杂，这时
候最好进行多人合作。
前台系统的移植主要是连接串的修改，一些差异的修改，如 SQL 参数的处理等，因
应用系统千变万化，只能具体情况具体对待。
在移植的过程中注意做好修改记录，便于分析查找问题。
2.5 系统测试
功能移植完成之后，需要进行一个完整性测试，主要包括功能测试和性能测试，测
试的目的如下：
1) 测试功能是否正确，一是看程序能否执行，而是看结果是否正确，如果不对，
可跟踪达梦日志，分析问题产生的原因进行相应的修改。
2) 测试执行效率，将用户反映慢的地方记录下来，效率优化的时候进行处理。
功能测试一般采用黑盒测试的方式进行，按照系统的功能点进行逐一测试，并做好
测试记录，测试主要考察功能测试点是否能够正常执行同时要考察测试结果数据是否正
确。
在进行性能测试前，可使用自动化的测试工具，加大测试数据量。性能测试在于找
出系统运行慢的地方，做好相关的记录，性能测试可以辅助采用一些自动化的工具，如
Loadrunner 等；根据需要，也可以编写一些有针对性的测试用例，加强系统性能测试。
2.6 错误修改
针对前面记录的功能问题进行修改，并进行回归测试。
武汉 上海 北京 广州 海南 南宁 合肥 江西 |
6
技术服务电话：400 648 9899
2.7 性能调优
针对前面记录的性能问题，可跟踪系统实际运行的 SQL 语句，分析 SQL 语句组成、
功能和相关的表，建立合适的索引一般能解决性能问题；如有必要，也可采用改写等价
SQL 语句的方法进行。
SQL 优化主要包括以下几个方面：
l
l
l
l
l
在合适的地方建立适当的索引
IN，NOT IN，<> 等操作符的转换
OR 的优化
IN 到 EXISTS 的转换
只查询用的的列等等
2.8 移植验收
提交功能、性能测试报告，提请系统移植验收。
3. Oracle 到 DM 的 SQL 移植要点
3.1 数据类型的对比
找出 ORACLE 数据库常用数据类型和 DM 数据库之间的对应关系，一般在从 ORACLE
迁移数据到达梦数据库时，达梦的数据迁移工具会自动把 oracle 的数据类型映射成达
梦对应的数据类型
3.2 临时表的对比
DM 不支持表类型定义，需要改用创建临时表的方式间接实现
TYPE
TTable IS TABLE OF VARCHAR2(4000) INDEX BY
BINARY_INTEGER;
SourceTable
7
TTable;
| 武汉
上海 北京 广州 海南 南宁 合肥 江西
table
#SourceTable (skey int unique, a
varchar(4000))
3.3 游标定义的对比
DM 的游标定义必须在 as(is)之后 begin 之前，基本格式为：
CREATE OR REPLACE PROCEDURE 存储过程名(参数 1 in 参数 1 类型，参数 2 out 参
数 2 类型)
as
参数定义部分
游标定义部分(游标名
curcor for 游标定义语句)
begin
open 游标名；
fetch 游标名
into 变量名；
close 游标名；
end；
只需更换游标定义时候的游标名的位置即可，对于后面用 for 还是 is 则看个人习
惯，DM 都支持的。
由于 DM 现在是不支持带参数和返回的游标定义。因此这里不仅要变换游标定义中
的游标名的位置，尤其注意的是怎么把参数去掉。如例子中所示，注意把 open 处的实
际参数去掉并用实际参数替换游标定义中的相关参数。
这里有另外一种情况，就是带参数的游标可以多次 open 而带不同的参数，这在 DM
中其实相当于定义多个不同的游标。如果打开同一个游标次数过多必定造成迁移工作量
技术服务电话：400 648 9899
很大。DM 是用游标变量来解决这个问题的。
定义游标变量即先定义一个游标变量（游标名 curcor）具体的游标定义可以在 open
时候定义（open 游标名
for 游标具体定义；）这样就可以实现定义一个游标变量名多次
open 了。
DM 不支持带返回值的游标定义，去掉原 ORACLE 中的参数返回即可。
3.4 视图的定义的对比
CREATE [OR RELPACE] VIEW
[<数据库名>.][<模式名>.]<视图名>{(<列名>{,<列名>})}
AS <查询说明>
[WITH CHECK OPTION];
如果出现以下三种情况之一,<视图名>后的<列名>不能省：
<查询说明>中 SELECT 后的<值表达式>不是单纯的列名，而包含集函数或运算表达
式
<查询说明>包含了多表连接，使得 SELECT 后出现了几个不同表中的同名列作为视
图列
需要在视图中为某列取与<查询说明>中 SELECT 后<列名>不同的名字
最后要强调的是：<视图名>后的<列名>只能全部省或全部不省，没有中间选择。
为了防止用户通过视图更新基表数据时，有意或无意更新了不属于视图范围内的基
表数据，在视图定义语句的子查询后提供了可选项 WITH CHECK OPTION，如选择，表示
往该视图中插入或修改数据时，要保证插入行或更新行的数据满足视图定义中<查询说
明>所指定的条件，不选则可不满足。
9
| 武汉
上海 北京 广州 海南 南宁 合肥 江西
www.dameng.com
如果视图查询中包含下列结构：连接、集合运算符、GROUP BY 子句，则在视图上
不能进行插入、修改和删除操作。
视图是一个逻辑表，它自己不包含任何数据。
CREATE [OR REPLACE] [FORCE|NOFORCE] VIEW
[schema.]view [(alias,...)]
AS subquery options
其中 ALLAS 是要创建的视图名，subquery options 是构成该视图代码的查询块。
3.5 过程以及函数的定义的对比
存储过程：
CREATE [OR REPLACE ] PROCEDURE <存储过程名>
[(<参数名>
<参数模式> <参数类型>
{,<参数名> <参数模式> <参数类型>})]
AS | IS
[<说明部分>]
<执行部分>
[<异常处理部分>]
END;
存储函数和存储过程很相似，它们的区别在于：
存储过程没有返回值，而存储函数有；
存储过程中可以没有返回语句，而存储函数必须通过返回语句结束；
存储过程的返回语句中不能带表达式，而存储函数必须带表达式；
技术服务电话：400 648 9899
存储过程不能出现在一个表达式中，而存储函数只能出现在表达式中；
存储函数：
CREATE [OR REPLACE ] FUNCTION <存储函数名>
[(<参数名>
<参数模式> <参数类型>{,<参数名> <参数模式> <参数类型>})]
RETURN <返回数据类型>
AS | IS
[<说明部分>]
<执行部分>
[<异常处理部分>]
END;
在存储函数中必须使用 RETURN 语句向函数的调用环境返回一个值。
存储函数不能用 CALL 语句调用，它只能出现在表达式中。
存储过程：
CREATE [OR REPLACE] PROCEDURE
procedure_name
[ ( argument[{IN | OUT | IN OUT}] type,
...
argument[{IN | OUT | IN OUT}] type) ] {IS
| AS}
procedure_body
其中 procedure_name 是要创建的过程名，argument 是过程的参数名，type 是关联
参数的类型，procedure_body 是构成该过程代码的 PL/SQL 块。
IN,OUT,和 IN
OUT 是参数的模式，如果没有为参数指定模式，则参数缺省的模式是
www.dameng.com
IN。
存储函数：
CREATE [OR REPLACE] FUNCTION function_name
[( argument[{IN | OUT | IN OUT}] type,
...
argument[{IN | OUT | IN OUT}] type)]
RETURN return_type{IS | AS}
function_body
其中 function_name 是函数的名称，参数 argument 和 type 的含义与过程相同，
return_type 是函数返回值的类型，function_body 是包括函数体的 P L / S Q L 块。
IN , OUT,和 IN
OUT 是参数的模式。如果没有为参数指定模式，则参数缺省的模式是 IN。
3.6 引用变量方面的对比
DM6.0 已经支持
ORACLE 中的引用变量类型，存储过程中可以直接使用。
3.7 系统函数的对比
抽取应用中用的 oracle 的函数，找到 DM 中对应的函数进行移植，DM 兼容绝大部分
ORACLE 的系统函数。
3.8 关于在移植过程中要注意的细节问题
分号问题：DM6.0 和
ORACLE 一样过程中的每条 sql 语句都要求带分号结尾。
关于注释：DM 中支持"/*""*/"多行注释和"--"单行注释，而//是不支持的，要注意。
现在 DM 在存储过程中没有
debug，调试时可以使用 print(’字符串’)语句来设置了解运
行过程，进行调试。
对于变量名和关键字相同的情况，DM 和 oracle 一样是以双引号来区分的。
技术服务电话：400 648 9899
对于 unique（唯一）之类的语句要改成 distinct。
DM 不支持无表定义存储过程，即在定义存储过程的过程中要检测表或视图是否存
在，如果不存在则无法通过。
DM 动态执行
sql 语句的语法是：exec immediate 字符串变量。
13
| 武汉
上海 北京 广州 海南 南宁 合肥 江西