Oracle移植经验交流

15
二． 数据库表的移植——数据

在移植的过程中，我们主要遇到了以下四类问题：
1. 2. 3. 4.
导入后的中文数据在Java程序或客户端中显示为乱码。 中文数据超出字段长度限制。 空数据超出字段长度限制。 中文乱码导致缺少字段。
16
二． 数据库表的移植——数据
1.
导入后所有中文数据在Java程序或客户端中显示为乱 码
8
二． 数据库表的移植——表结构

根据在验证阶段的经验，如果直接利用PowerDesigner 生成的SQL在Oracle上建表，会出现一些数据迁移上的 问题，因此，需要对生成的建表SQL做一些调整，主要 有以下两点：


对于CHAR和VARCHAR2类型的字段，如果字段的数据包含有 中文或者全角字符等，建议将其转换为NCHAR和NVARCHAR2 类型，以免由于Informix和Oracle的字符集编码方式不一致等导 致字段超长等问题。 对于Informix中类型为LVARCHAR的字段，PowerDesigner会将 其转换为Oracle的CLOB类型，这样在以后的应用中可能会出一 些问题。因此，如果字段长度小于4000，建议根据这些字段中 是否含有中文将其改为VARCHAR2或者NVARCHAR2类型。
18
二． 数据库表的移植——数据
3.
空数据超出字段长度限制。


对于从Informix中导出来的某些数据，在unl中会表示为‘\ ‟， 这种情况下，Oracle会认为这是两个字符。当目标字段的长 度为1时，就会出现“字段超长”的问题。经过排查，发现 如果向Informix中类型为VARCHAR的字段插入‘’，再导 出到unl中就会成为‘\ ‟的形式，当字段类型为CHAR或者插 入null或空格时，不会有这种现象。 对于这一问题，处理的建议是在unl中，批量的将'\ '替换为' „。 不替换为''的原因是，Informix中，''不是null，因此，可以被 插入有not null限制的字段，但是，在Oracle中，''就是null， 因此对于有not null的字段，会导入出错。
7
二． 数据库表的移植——表结构

经过探索，我们选取了Power Designer作为迁移表结构的工具，具 体操作步骤如下：
1. 2.
3.
4.
5.
利用Informix的dbschema工具把系统的表结构整体导出成一个SQL文件。 导出的SQL文件由于编码集的原因，有可能无法被Power Designer识别。 这就需要用ultra edit等工具把SQL文件打开，复制其中的内容，然后另存为 UTF-8的文件。 然后，利用PowerDesigner反向工程（菜单"Database-> Reverse Engineer Database"）功能生成PDM模型。在生成PDM模型的过程中，会自动解析 表与表之间的依赖关系。 打开PDM模型，将DBMS设置从Informix改为Oracle（菜单“Database-> Change Current DBMS”）。Power Designer会自动对数据类型等进行转换。 生成SQL脚本（菜单"Database-> Generate Database"），得到在Oracle上 执行的建表SQL。对于存在依赖关系的表，Power Designer会保证其创建 的先后顺序。
11
二． 数据库表的移植——数据


外部表可以方便快捷的对外部数据进行函数转换处理等，但从 Informix中导出的数据不需要做太多处理，一般只是日期时间等 格式的解析。 SQL*Loader可以在客户端加载数据，也可以在服务器端加载数 据。外部表只能在服务器端加载数据。 外部表需要数据库中创建目录对象，并且将目录对象的读写权 限授予执行导入的数据库用户。 如果将服务器某个位置的文件导入数据库。需要确认操作系统 的oracle用户有这个文件的读权限。 创建外部表之后，还需要执行insert语句才能把数据从外部表导 入Oracle自身的表中。
4
一．整体介绍
二．数据库表的移植
三．存储过程的移植
四．Java应用的移植 五．C程序的移植
5
二． 数据库表的移植
对于数据库表的移植，主要包括表结构的
移植和数据的移植两大步骤。
此外，对于索引，一般来说是在数据移植完
成之后创建，但由于索引的主要目的是为了 提高数据处理的性能，在后续的调优阶段可 能会对索引有较大的调整，因此需要具体问 题具体分析。

一般来说，对于数据量较大的系统，推荐采用1、2、3、4结合来对 数据进行验证。对于数据量较小但对数据准确性要求较高的系统， 可以考虑第5种方式。
21
二． 数据库表的移植——索引



在我们的移植过程中，Informix库中的索引都是以标准SQL语法创 建的，因此，可以直接把创建索引的SQL脚本在Oracle的环境下执 行。 但假如使用从数据库中导出的索引脚本，其中往往包含了一些 Informix特有的语法结构，例如下面的一条语句： create index "amis".t29_psnqualcard_index1 on "amis".t29_psnqualcard (t01personid,t29cardtype) using btree in datadbs ; 在Oracle中，using btree in datadbs无法被识别，可以直接去掉该 子句，不会影响索引的创建。 此外，数据对象前面的所属用户也要去掉。




这 一 问 题 的 原 因 是 Oracle 数 据 库 的 编 码 类 型 设 置 成 为 了 ISO8859_1(WE8ISO8859P1)。 一种解决的方案是在Java等应用中增加转码的逻辑，并当数 据库不是西方字符集时关闭这一功能 另一种方案是将数据库编码修改为GBK(ZHS16GBK)后重新 导入。 在GMIS中，我们采取的是后一种方案。修改的脚本参见 《数据库转码.txt》

通过以上步骤，表结构的移植便基本完成了。
10
二． 数据库表的移植——数据

在数据的移植过程中，我们比较了Oracle的SQL Loader 和外部表以及MS的SSIS等方式，最终选择了SQL Loader。我们的考虑主要基于以下几点：



利用SSIS进行数据移植在理论上是可行的，但需要对每个表都 开发移植包，并且由于SSIS属于SQL Server的组件，对于从 Informix到Oracle的移植来说，部署不够方便。 SQL*Loader比较适合将外部数据加载到Oracle中，而外部表适 合对外部数据的经常性读取。 SQL*Loader和外部表都可以读取文本数据文件，外部表还可以 读写二进制数据文件。从Informix中导出的数据文件基本都是文 本格式的。 通过SQL*Loader的直接路径方式导入时，SQL*Loader和外部 表的导入效率比较接近。
20
二． 数据库表的移植——数据

由于在数据移植过程中，数据量不是一个很小的数目，因此，难以 做到逐一检查。为了保证移植过程中数据的正确性，我们提出了如 下几种检查方式：
1.
Βιβλιοθήκη Baidu2.
3. 4.
5.
检查导入日志。通过查看日志来检查数据导入过程中是否有错误，并及 时解决。 统计各表行数。这主要是检查表移植过程中是否有被忽略的数据或者误 插入数据的情况。 统计主要数值字段的总和。这主要是检查数值的精度是否在移植过程中 有所缺失。 抽样检查表中数据。 编写SQL语句，将各字段以精度足够的相同格式查询出来，并导出成文 本文件，利用比对工具进行比较。
北京研发中心应用技术经验交流之n
移植到Oracle数据库
经验交流
版本： 1.0
一．整体介绍
二．数据库表的移植
三．存储过程的移植
四．Java应用的移植 五．C程序的移植
一． 整体介绍
不同于AMIS和BMIS等系统，GMIS选用了
Oracle作为数据库平台而不是Informix，为 此，在项目进入开发之前，我们选用了 BMIS的部分典型功能进行了技术验证，在 正式的开发过程中，又发现并解决了其他 一些问题，现在把这些经验一并总结出来， 供大家参考。
9
二． 数据库表的移植——表结构

在表结构移植之后，需要对表名和列名进行检查，以便及早发现并 解决数据库对表名、字段名约束不同带来的更名问题。我们采取的 方式为：
1.
2.
3.
在Informix中执行如下查询脚本： select upper( b.tabname),upper(c.colname) from systables b, syscolumns c where b.tabid=c.tabid and b.owner in('bmis','amis') order by 1,2 在Oracle中执行如下查询脚本： select b.table_name,c.COLUMN_NAME from user_tables b, user_tab_columns c where b.table_name= c.TABLE_NAME order by 1,2 分别导出查询的结果，进行比较。如果发现有表名或者列名不一致的情况， 则需要记录下来，在后续应用程序等移植的时候，着重注意。
13
二． 数据库表的移植——数据

在数据导入过程中，要注意存在依赖关系的表的 导入先后顺序，也可以把外键给禁用，数据导入 完成之后再重新启用。对于数据量大的表，当其 存在主键或者唯一约束时，也可以把约束先禁用 后再重新启用
14
二． 数据库表的移植——数据

在数据移植的过程中，由于Informix和Oracle在 数据存储方式等方面存在着许多不同点，往往会 报数据移植错误。对于这种情况，我们的做法是， 记录错误数据，具体分析问题原因。
3
一． 整体介绍
在移植过程中，结合项目的实际情况，我
们把整个移植工作分为了数据库移植、存 储过程移植、Java应用移植、C程序移植四 个部分，下面分别加以说明。
其中，Oracle官方提供一个工具Migration
WorkBench，可以用于将表结构、存储过程和 C程序从其他数据库移植到Oracle，但在技术 验证的过程中，我们发现对表结构、存储过程 的移植支持的不太好，因此，只将其用于辅助 C程序的移植。
6
二． 数据库表的移植——表结构

对于表结构的移植，我们主要考虑了以下几点：


源表结构的获取。这是表结构移植的基础。 表与表之间的依赖关系。对于存在主外键依赖关系的表，要注 意创建的先后顺序。 不同数据库间数据类型的映射。由于不同数据库对于数据类型 的实现有所不同，数据类型的名称也有所差异，因此，这一点 要着重注意。 数据库对表名、字段名约束不同带来的更名问题。由于不同数 据库的关键字集合有所有差异，对于表名、字段名的长度限制 等也有不同，因此，有可能需要对表和字段的名称进行修改。
19
二． 数据库表的移植——数据
4.
中文乱码导致缺少字段。


当插入数据超出字段的最大程度时，Informix会把这些数据 的超长部分截掉之后插入库表中。这样对于有些中文数据， 在Informix数据库中最后一个字符就变成了乱码。在导出成 unl之后，乱码吞掉了一个‘|‟分割符，从而SQL loader认为 数据缺少了一个字段。 对于这一问题的处理建议是，手动修改数据，把乱码改为正 确数据并添加分割符。
12
二． 数据库表的移植——数据

SQL*Loader使用比较方便，但编写控制文件比 较麻烦，每个表都要编写一个控制文件。


经过对SQL*Loader的分析，我们开发了Java程序， 专门根据Informix的数据库导出文件批量生成 SQL*Loader的控制文件和导入脚本，并支持字符集、 日期格式、数据库用户、数据文件等多个参数。这样， 可以比较快速的把Informix的数据移植到Oracle上。 其使用说明参见《数据移植说明.txt》
17
二． 数据库表的移植——数据
2.
中文数据超出字段长度限制。


对于中文字符，在有些字符集编码中，占用两个字节的空间， 在另一些字符集中则占用三个字节的空间，而char和varchar 这两种数据类型的长度是以字节为单位的。这样，在 Informix中不超长的字段，到了Oracle中就有可能会超长。 处理的建议是，对于出现超长问题的字段，在Oracle中分别 改为Nchar和Nvarchar。这两种数据类型是以字符数为单位 的，因此在导入时不会发生超长的问题。