Oracle移植经验交流

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 分别导出查询的结果，进行比较。如果发现有表名或者列名不一致的情况， 则需要记录下来，在后续应用程序等移植的时候，着重注意。
20
二． 数据库表的移植——数据

由于在数据移植过程中，数据量不是一个很小的数目，因此，难以 做到逐一检查。为了保证移植过程中数据的正确性，我们提出了如 下几种检查方式：
1.
2.
3. 4.
5.
检查导入日志。通过查看日志来检查数据导入过程中是否有错误，并及 时解决。 统计各表行数。这主要是检查表移植过程中是否有被忽略的数据或者误 插入数据的情况。 统计主要数值字段的总和。这主要是检查数值的精度是否在移植过程中 有所缺失。 抽样检查表中数据。 编写SQL语句，将各字段以精度足够的相同格式查询出来，并导出成文 本文件，利用比对工具进行比较。




这 一 问 题 的 原 因 是 Oracle 数 据 库 的 编 码 类 型 设 置 成 为 了 ISO8859_1(WE8ISO8859P1)。 一种解决的方案是在Java等应用中增加转码的逻辑，并当数 据库不是西方字符集时关闭这一功能 另一种方案是将数据库编码修改为GBK(ZHS16GBK)后重新 导入。 在GMIS中，我们采取的是后一种方案。修改的脚本参见 《数据库转码.txt》
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会保证其创建 的先后顺序。
3
一． 整体介绍
在移植过程中，结合项目的实际情况，我
们把整个移植工作分为了数据库移植、存 储过程移植、Java应用移植、C程序移植四 个部分，下面分别加以说明。
其中，Oracle官方提供一个工具Migration
WorkBench，可以用于将表结构、存储过程和 C程序从其他数据库移植到Oracle，但在技术 验证的过程中，我们发现对表结构、存储过程 的移植支持的不太好，因此，只将其用于辅助 C程序的移植。
17
二． 数据库表的移植——数据
2.
中文数据超出字段长度限制。


对于中文字符，在有些字符集编码中，占用两个字节的空间， 在另一些字符集中则占用三个字节的空间，而char和varchar 这两种数据类型的长度是以字节为单位的。这样，在 Informix中不超长的字段，到了Oracle中就有可能会超长。 处理的建议是，对于出现超长问题的字段，在Oracle中分别 改为Nchar和Nvarchar。这两种数据类型是以字符数为单位 的，因此在导入时不会发生超长的问题。
北京研发中心应用技术经验交流之n
移植到Oracle数据库
经验交流
版本： 1.0
一．整体介绍
二．数据库表的移植
三．存储过程的移植
四．Java应用的移植 五．C程序的移植
一． 整体介绍
不同于AMIS和BMIS等系统，GMIS选用了
Oracle作为数据库平台而不是Informix，为 此，在项目进入开发之前，我们选用了 BMIS的部分典型功能进行了技术验证，在 正式的开发过程中，又发现并解决了其他 一些问题，现在把这些经验一并总结出来， 供大家参考。
12
二． 数据库表的移植——数据

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


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

一般来说，对于数据量较大的系统，推荐采用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无法被识别，可以直接去掉该 子句，不会影响索引的创建。 此外，数据对象前面的所属用户也要去掉。
8
二． 数据库表的移植——表结构

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


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

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


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


当插入数据超出字段的最大程度时，Informix会把这些数据 的超长部分截掉之后插入库表中。这样对于有些中文数据， 在Informix数据库中最后一个字符就变成了乱码。在导出成 unl之后，乱码吞掉了一个‘|‟分割符，从而SQL loader认为 数据缺少了一个字段。 对于这一问题的处理建议是，手动修改数据，把乱码改为正 确数据并添加分割符。
4
一．整体介绍
二．数据库表的移植
三．存储过程的移植
四．Java应用的移植 五．C程序的移植
5
二． 数据库表的移植
对于数据库表的移植，主要包括表结构的
移植和数据的移植两大步骤。
此外，对于索引，一般来说是在数据移植完
成之后创建，但由于索引的主要目的是为了 提高数据处理的性能，在后续的调优阶段可 能会对索引有较大的调整，因此需要具体问 题具体分析。
13
二． 数据库表的移植——数据

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

在数据移植的过程中，由于Informix和Oracle在 数据存储方式等方面存在着许多不同点，往往会 报数据移植错误。对于这种情况，我们的做法是， 记录错误数据，具体分析问题原因。