一、概述
随着数字化转型的推进,越来越多的企业和机构开始关注数据库的自主可控性,国产数据库凭借其技术特性逐渐受到青睐,达梦数据库(DM)作为国产数据库的代表,在数据安全、生态完整、性能优化等方面展现了突出能力。DB2 是一款历史悠久且功能强大的数据库产品,在众多企业的业务系统中有着广泛的应用。然而,出于成本控制、技术升级、自主可控等多方面因素的考虑,许多使用 DB2 数据库的企业有了将其迁移到达梦数据库的需求。
本文旨在介绍从 DB2 移植到 DM 的整体流程、注意事项以及常见问题的解决方案。在迁移过程中,将详细介绍迁移流程、迁移评估、移植工具选择、制定移植计划、移植实施、移植结果校验等关键步骤,以确保迁移过程的顺利进行。同时,针对迁移过程中可能遇到的常见问题,将提供相应的解决方案,以帮助用户更好地完成数据库迁移工作。
二、迁移流程
2.1 迁移流程图
2.2 流程介绍
2.2.1 需求分析
移植会涉及诸多场景,如容灾备份、应用改造/替代、数据库版本升级/回退、数据库替代、业务分流等,不同的场景在数据流向、停机窗口、同步需求、数据处理等方面会有不同的需求,需要针对性地选择迁移方案。
2.2.2 数据库调研
考虑迁移或同步工具版本、驱动版本、基础环境、操作方式、对象个数、对象大小、数据量等均会影响迁移工作的开展,需要对源端和目的端数据库及服务器、业务系统进行调研,确保在满足相关需求的前提下稳定完成迁移。
确认迁移需求后,源端数据库需提前调研如下信息:
- 环境信息。提前了解操作系统层面,对工具能否使用可视化界面,或者端口号开放情况,可以方便在后期部署安装过程中,及时避开处理问题时的一些干扰项。主要包括对服务器、内存、CPU、网络、端口、安全策略、是否具备可视化界面等信息的调研。
- 业务系统信息。提前了解应用系统层面信息,结合应用系统特性,为后面制定迁移策略、迁移时间评估等提供参考。主要包括对业务类型、业务运行时段、停机窗口、数据量、数据增量、并发访问量等信息的调研。
- 数据库信息。提前了解迁移数据量、字符编码、归档保留策略、数据库对象、用户权限、表空间等信息,为后续迁移做好规划和相关准备工作。
2.2.3 迁移评估
达梦数据提供了三种工具进行迁移前源端数据库兼容性评估:
数据迁移工具 DTS:支持对 ORACLE、MySQL、PostgreSQL、DB2、SQL Server 等主流数据库迁移到达梦数据库,提供了异构数据源之间的评估,迁移和对比功能。DM 数据迁移工具采用向导方式引导用户通过简单的图形化进行兼容性评估操作。
达梦企业管理器 DEM:支持对 ORACLE、MySQL、PostgreSQL、DB2、SQL Server 等主流数据库迁移到达梦数据库进行在线采集评估和自动转化,并提供兼容性报告。
SQLark 百灵连接:支持对 ORACLE、MySQL、PostgreSQL 等主流数据库迁移到达梦数据库进行在线采集评估和自动转化,一键生成源数据库画像,获取源库对象、不兼容对象、大表、大字段表等迁移重难点情况,评估本次迁移需要投入的工作量。SQLark 会根据源库画像,生成合理的迁移策略,为开发者后续进行的自动/手动迁移提供迁移方案参考。
除此之外,需要人工对大表、大字段表这些是否单独迁移进行评估及如何配置大表、大字段表的迁移策略。
2.2.4 移植工具选择
达梦公司提供了四种移植工具:数据迁移工具 DTS、SQLark 百灵连接、数据复制软件 DMDRS 和数据集成软件 DMDIS,可满足不同移植场景的使用需求,详细内容参考移植工具介绍。
2.2.5 制定移植计划
根据需求分析和数据库调研,结合每个应用系统的具体要求,选择合适的迁移工具,基于数据迁移的基本原则和迁移工具评估结果,制定合理的移植计划避免任何可能遗漏的步骤,保障迁移工作的稳定实施。
2.2.6 移植实施
对于异构数据库移植到达梦,在正式迁移前,需要根据源端数据库的相关调研信息,对目的库的实例参数、表空间、用户等进行配置,减少由于配置差异带来的迁移问题,保障后续移植工作稳定进行。
同时,达梦数据的迁移工具均具有自动转换功能。大多数情况下,可通过相关迁移工具进行对象和数据移植,但由于异构数据库间语法并非 100% 兼容,少量数据则需要进行手动移植。
2.2.7 移植结果校验
在进行正式环境的数据移植时,每一条数据都是真实的,有效的且完整的,在迁移完成后,必须源端数据库的所有对象都准确无误地迁移到目的端,一旦出现缺少对象、缺少数据或数据内容不正确的情况,可能会导致某些功能模块失效等严重后果。因此在迁移完成后,须确认是否出现迁移后的数据量、数据内容或对象个数不一致的情况,如果不一致应进行对应的维护。
2.2.8 移植后收尾工作
移植后的收尾工作包括:索引补录、更新统计信息、备份、整理对象脚本等内容,保障移植工作的完整性。
2.2.9 应用移植与优化
一般情况下,源端数据库迁移完成后,直接更换应用连接源端数据源到达梦数据库,应用代码适配不用修改。为了验证系统移植的完整性,还需要进行应用的相关功能和性能测试,并改造应用到连接达梦数据库一个最佳状态。
此外,在对应用系统进行全面测试后,排除移植过程中错误的地方,还应对数据库中的慢 SQL 进行优化,保证移植后的系统高效运行。
三、移植过程
3.1 需求确认及调研
3.1.1 需求确认
本例构建了一个 DB2_v11.5 的单机示例库,并介绍利用 DTS 工具从 DB2_v11.5 移植 DB_TEST 库中的所有对象到 DM8 数据库的详细步骤,以供参考。
示例 SQL 脚本如下:
此示例包含了 DB2 中 SMALLINT、INTEGER、BIGINT、DECIMAL、NUMERIC、DECFLOAT、FLOAT、DOUBLE、CHAR、VARCHAR、CLOB、BLOB、DATE、TIME、TIMESTAMP、XML、GRAPHIC、VARGRAPHIC、DBCLOB 等十九种常见数据类型;囊括了普通表、分区表、视图、物化视图、函数、存储过程、触发器、序列等八类常见对象。
3.1.2 数据库调研
考虑迁移或同步工具版本、驱动版本、基础环境、操作方式、对象个数、对象大小、数据量等均会影响迁移方案的制定、迁移工作的开展,需要对源端和目的端数据库及服务器、业务系统进行调研,确保在满足相关需求的前提下稳定完成迁移。
- DB2 源端信息
- 环境信息
调研项 | 说明 |
---|---|
应用后台操作系统 | CentOS 7 x86_64 |
数据库后台操作系统 | CentOS 7 x86_64 |
后台数据库 | DB2_v11.5 |
应用开发平台 | JAVA |
应用开发接口 | JDBC |
需要移植的数据库对象 | 表(数据量)、视图、序列、触发器、函数。 |
- 数据库信息
预先对源端 DB2 数据库开展相关了解工作,此举一方面可为后续的安装工作提供参考依据,另一方面提前掌握迁移数据量、字符编码、归档保留等信息,能为后续的数据迁移工作做好充分的前期准备。以下是针对源端 DB2 的调研情况:
调研项 | 说明 |
---|---|
数据库架构 | 单机 |
节点数 | 1 |
数据库版本 | DB2_v11.5 |
待迁移库 | DB_TEST |
IP 地址/端口 | xxx.xxx.56.65/50000 |
服务器运维用户名(密码) | root/xxxxx |
数据库用户名(密码) | db2inst1/xxxxx |
字符集编码 | UTF8 |
大小写敏感 | 敏感 |
是否以字节为单位 | // |
归档保留策略 | // |
- 迁移对象统计
在进行迁移操作之前,可预先统计待迁移库中的对象,提前掌握迁移数据量、迁移数据对象以及迁移数据类型,从而为评估迁移时长和确定停机窗口提供依据。以下为 DB2 中统计库中对象的方法:
(1)统计指定模式 DB_TEST 中所有对象。
--创建辅助表统计数据库对象
CREATE TABLE DB_TEST.DB2_objects (
obj_owner varchar(20),
obj_type varchar(20),
obj_name varchar(50)
);
--插入查询数据
INSERT INTO DB_TEST.DB2_objects SELECT a.TABSCHEMA,a.TYPE,a.TABNAME FROM syscat.tables a
WHERE a.TABSCHEMA = 'DB_TEST' AND ((a.TYPE = 'T' AND a.TABNAME NOT IN('DB2_OBJECTS')) OR a.TYPE = 'V'OR a.TYPE = 'S')
UNION ALL SELECT c.SEQSCHEMA,'序列',c.SEQNAME FROM syscat.sequences c WHERE c.SEQSCHEMA = 'DB_TEST'
UNION ALL SELECT d.PROCSCHEMA,'存储过程',d.PROCNAME FROM syscat.procedures d WHERE d.PROCSCHEMA = 'DB_TEST'
UNION ALL SELECT e.FUNCSCHEMA,'函数',e.FUNCNAME FROM syscat.functions e WHERE e.FUNCSCHEMA = 'DB_TEST'
UNION ALL SELECT f.TRIGSCHEMA,'触发器',f.TRIGNAME FROM syscat.triggers f WHERE f.TRIGSCHEMA = 'DB_TEST'
UNION ALL SELECT g.INDSCHEMA ,'索引',g.INDNAME FROM syscat.indexes g WHERE g.INDSCHEMA = 'DB_TEST';
--更新字段
UPDATE DB_TEST.DB2_objects SET obj_type = '表' WHERE OBJ_TYPE = 'T';
UPDATE DB_TEST.DB2_objects SET obj_type = '视图' WHERE OBJ_TYPE = 'V';
UPDATE DB_TEST.DB2_objects SET obj_type = '物化视图' WHERE OBJ_TYPE = 'S';
--查看对象统计结果
SELECT * FROM DB_TEST.DB2_OBJECTS;
(2)统计模式 DB_TEST 中所有表数据行数。
--创建辅助表用于记录表数据行数。
CREATE TABLE DB_TEST.table_row_count(schname varchar(50),
tabname varchar(50),
row_count int);
--创建存储过程,统计表数据行数。
CREATE OR replace PROCEDURE DB_TEST.row_count() LANGUAGE SQL
BEGIN
DECLARE sch varchar(20);
DECLARE tab varchar(20);
DECLARE v_sql varchar(1000);
FOR rec AS MYCURSOR CURSOR FOR
SELECT tabschema,tabname FROM syscat.tables WHERE tabschema = 'DB_TEST' AND TYPE = 'T'
DO
SET sch = tabschema;
SET tab = tabname;
SET v_sql = 'insert into DB_TEST.table_row_count select ''' || sch || ''',''' || tab || ''',count(*) from ' || sch || '.' || tab;
PREPARE stmt FROM v_sql;
EXECUTE stmt;
END FOR;
COMMIT;
END;
--执行存储过程
call DB_TEST.ROW_COUNT();
--查询统计结果
select * from DB_TEST.table_row_count where tabname not in ('TABLE_ROW_COUNT','DB2_OBJECTS') ;
借助上述 SQL 统计待迁移对象的数据,并予以记录,以便在迁移工作完成后开展数据对比。
类型 | 数量 |
---|---|
表 | 3 |
物化视图 | 1 |
视图 | 2 |
函数 | 1 |
存储过程 | 1 |
序列 | 1 |
触发器 | 1 |
索引 | 8 |
- DM 目的端信息
明确目的端系统的环境信息,以便选择与之对应的 DM 数据库版本进行安装。
调研项 | 调研命令 |
---|---|
服务器品牌/型号 | dmidecode |
服务器操作系统 | cat /etc/os-release |
内存容量 | cat /proc/meminfo |
CPU 型号/核数 | cat /proc/cpuinfo |
端口策略 | 是否与目的端网络、端口互通 |
安全策略 | 是否有软件、硬件相关安全限制(比如堡垒机、网闸、文件摆渡) |
是否具备可视化界面 | 可视化提供的方式(直连、Xmanager、VNC、BMC 等) |
其他 | ## |
3.2 迁移评估
本例中,介绍使用 DTS 工具进行迁移评估工作,对源端数据库进行迁移评估,包括数据对象和 SQL,最终形成迁移评估报告。可通过迁移评估报告提前了解哪些数据对象或 sql 需要单独处理,方便后续迁移的顺利进行,详细步骤如下(DEM 工具迁移评估详细步骤可参考《从 Oracle 移植到 DM》- DEM 迁移评估)。
DTS 版本 | 2025 年第一季度版 |
---|
- 创建工程
打开 DMDTS 迁移工具点击左上方的 3 色小图标新建迁移工程。
- 创建评估。
点击左侧“评估”,选择点击“新建评估”,按要求填写相关信息。
新建评估完成后选择评估方式为“DB2==>DM”,点击“下一步”。
输入 DB2 数据库连接信息,连接 DB2 数据库,点击下一步。
“评估选项”可进行自定义,本文示例保持默认。
“指定模式”配置项,勾选需要迁移的模式 DM_TEST,点击下一步。
“指定对象”配置项,除了用于统计表数据行数的存储过程“ROW_COUNT”不勾选,其他对象都勾选。配置完成后,点击下一步。
“执行方式”配置项保持默认,直接点击下一步。
“审阅评估任务”配置项,检查无误后,点击“完成”即可开始执行评估任务。
- 查看评估结果
评估完成后,点击“查看评估报告”查看评估结果。
评估报告可选择导出为不同的文件,本示例选择“导出 HTML 报告”。
打开评估报告,可以从不同维度查看迁移评估结果。
(1)源库画像,记录了源端 DB2 数据库的“基本信息”和“对象统计信息”。
(2)“目的库推荐”,提供了目的端 DM8 推荐的初始化参数和系统基础配置。
(3)“兼容性分析”,包括了整体的兼容性、“对象兼容性”和“SQL 兼容性”。
在“对象兼容性”下可以查看“对象兼容性详情”,通过下拉列表来进行筛选。
如筛选本示例中所有不兼容的对象,会发现存在两个完全不兼容的对象,可通过点击“查看详情”来查看导致不兼容的原因。
通过“查看详情”可知,对象“ALL_DATA_TYPES”评估不兼容的情况出现在创建相关索引和注释阶段。迁移该表不受影响,仅需关注索引和注释的迁移状况。若索引及注释迁移失败,可考虑手动进行补充迁移。
同样,通过“查看详情”可以得知,对象“TRG_AUDIT_LOG”不兼容的原因是 DM 触发器语法与 DB2 存在差异。在迁移过程中,可选择不勾选该对象,而是在 DM 中手动创建具有相同功能的触发器来完成迁移。
在“SQL 兼容”下可以查看“SQL 兼容性详情”,也可通过下拉列表来进行筛选。
同样筛选本示例中所有不兼容的对象,会发现存在四个完全不兼容的对象,可通过点击“查看详情”来查看不兼容的原因。
经排查,此处仅需关注第 2 条不兼容的 SQL。该 SQL 是 DB2 端创建的用于统计表格数据行数的存储过程,不在本次迁移对象范围内,故而无需进行手动迁移。
(4)“任务耗时-TOP10”,记录了评估任务耗时情况。
借助迁移评估,能够梳理出 DM 数据库不兼容的对象,采用 DM 语法对其进行手动修改。在正式迁移时,针对不兼容部分的对象,不借助工具实施迁移,待其他对象迁移完毕后,再将修改后的对象手动在 DM 数据库中创建。
3.3 制定移植计划
根据待移植的 DB2 系统信息分析的情况,制定迁移计划:先对整库进行一次性迁移,再对不兼容的对象进行补迁。
3.4 迁移准备
本文将介绍利用 DTS 工具进行通用情况下的数据移植工作,其他特殊配置可根据实际需求进行调整。
3.4.1 源端 DB2 数据库准备
DTS 工具为静态数据迁移工具,在正式开始移植前需要停止所有对 DB2 数据库的变更操作,保证数据一致性。
3.4.2 目的端达梦数据库准备
- 数据库版本选择
DM 数据库会定期进行产品更新迭代。在进行项目移植前,需要先确定使用的 DM 数据库版本:
(1)建议使用当前最新版本的数据库,以保证更高的兼容性。
(2)版本优先选择完整安装版本。
(3)版本与硬件环境一定要严格匹配,以减少干扰性的问题出现。
本示例中,目的端 DM8 版本及 DTS 版本如下:
服务器 | 版本 |
---|---|
DM8 | 2025 年第一季度版 |
DTS | 2025 年第一季度版 |
- 数据库架构选择
达梦数据库为用户提供多样的数据库架构适配用户不同的业务需求,用户可以根据业务系统需求选择达梦合适的数据库架构进行部署。DM 数据库架构可参考:
详细安装部署步骤可参考:达梦在线服务平台-运维指南-数据库规范化部署相关内容,本例中选择目的端数据库架构为单机。
- 初始化设置
在安装好达梦数据库后还需要初始实例用于对数据的管理,在初始实例时初始化参数尤为重要。
数据库参数 | 参数值 |
---|---|
DB_NAME(数据库名) | DAMENG(根据需求设置) |
INSTANCE_NAME(实例名) | DMSERVER(根据需求设置) |
PORT_NUM(端口) | 5237(正式移植环境下,为保证数据库安全,不建议使用默认端口 5236) |
管理员、审计员、安全员密码(安全版本特有) | 建议首次初始化实例时立即修改密码 |
EXTENT_SIZE(簇大小) | 16 |
PAGE_SIZE(页大小) | 32 |
LOG_SIZE 日志大小 | 2048M |
CHARSET(字符集) | UTF-8(一般是 UTF8,根据实际需求配置) |
CASE_SENSITIVE(大小写敏感) | 敏感(根据实际情况设置) |
BLANK_PAD_MODE(尾部空格填充) | 否 |
SYSDBA_PWD(SYSDBA 用户密码) | xxxxxxxx |
SYSAUDITOR_PWD(SYSAUDITOR 用户密码) | xxxxxxxx |
注意其中页大小(page_size)、簇大小(extent_size)、大小写敏感(case_sensitive)、字符集(charset)、结尾空格填充(BLANK_PAD_MODE)一旦确定无法修改,需谨慎设置。
初始化参数的详细说明可参考达梦数据库安装目录下 doc 目录中的《DM8_dminit 使用手册》或在数据库运行目录 bin 目录下执行以下命令查看部分初始化参数说明。
./dminit help
注意用户在安装数据库初始化实例时,必须设置数据库系统用户的初始密码,并保证一定的密码强度,以保障数据安全性。
4.创建迁移用户和表空间
在从 DB2 向达梦数据库(DM)进行移植操作之前,需预先在 DM 端创建好待使用的用户以及该用户的表空间,勿将数据迁移至系统默认的管理员 SYSDBA 用户以及 MAIN 表空间之下。
当从 DB2 迁移至达梦数据库时,需要针对 DB2 中的每一个模式,在达梦数据库中创建一个与之对应的用户。例如,若 DB2 中需要迁移的模式为 DB_TEST,则需先在达梦数据库中创建一个名为 DB_TEST 的表空间,随后创建一个名为 DB_TEST 的用户,并指定其默认表空间为 DB_TEST。示例如下:
创建 DB_TEST 表空间存储 DB2 中 DB_TEST 库迁移过来的数据。
create tablespace "DB_TEST" datafile '/data/dmdata/DAMENG/DBTEST.DBF' size 2048 autoextend on CACHE = NORMAL;--创建表空间DB_TEST,数据文件为DBTEST.DBF。
创建 DB_TEST 用户并授予权限,使用 DB_TEST 表空间。
create user "DB_TEST" identified by "密码" --创建用户
default tablespace "DB_TEST"--指定用户DBTEST表空间为DBTEST
default index tablespace "DB_TEST";--指定用户DBTEST索引表空间为DBTEST
grant "PUBLIC","RESOURCE","SOI","SVI","VTI" to "DB_TEST";--授予用户DBTEST常规权限。
进行 DB2 迁移时,需先分析本次迁移需从源库移植的一个或多个模式的数据。随后,针对每个模式,分别在达梦数据库中创建独立的表空间与用户,用户创建后会自动生成同名的模式。多数情形下,待迁移数据所在的 DB2 库存在多个模式,但并非所有模式均需迁移。因此,在迁移准备阶段,务必明确要迁移哪些库的哪些模式。
3.4.3 迁移工具准备
本文选择“DM 数据迁移工具 V8 (Build 2025.01.22)”作为本次迁移要使用的迁移工具,同版本界面显示上可能会有一些差异。该工具在安装数据库客户端时已安装完成可以直接使用,工具存放在 DM 数据库安装目录下 tool 文件夹中。
Linux 环境下进入 tool 目录中执行 ./dts 即可运行 DM DTS 工具,window 环境下可直接双击启动。
3.5 迁移步骤
3.5.1 创建迁移
- 打开 DMDTS 迁移工具点击左上方的 3 色小图标新建迁移工程。如已创建迁移工程,则可跳过此步。
- 打开刚刚创建的工程右键点击“迁移”,选择“新建迁移”,并自定义迁移名称。
- 新建迁移完成后点击下一步。
- 从“其他数据库迁移到达梦”选项中选择迁移方式为“DB2 ==> DM”。
3.5.2 连接数据库
迁移方式选择完毕后开始连接数据库,首先连接源端 DB2 数据库,再连接目的端 DM 数据库。
- 连接源端 DB2 数据库。
输入源端 DB2 数据库相关登录信息,在“数据库名”选项中选择需要迁移的数据库。
在创建连接 DB2 数据库时建议通过指定驱动的方式来连接数据,避免因为驱动版本不适配等问题导致迁移失败。驱动可以在 DB2 官网获取与 DB2 迁移版本相对应的驱动。
同时在工具目录 \tool\dropins\com.dameng\plugins\com.dameng.jdbc.drivers\db2
也存在相应版本的数据库驱动。
- 连接目的端 DM 数据库。
输入目的端 DM 数据库相关登录信息,选择与源端对应的迁移用户连接数据库。
3.5.3 配置迁移对象及策略
- 迁移对象方式及迁移策略。
当勾选了“使用默认数据类型映射关系”后在迁移时 DTS 会将源端 DB2 数据库中相应的数据类型采用默认的映射关系映射到目的端 DM 数据库中。如果在这里勾选了“使用默认数据类型映射关系”,后面又自定义了数据类型映射关系,DTS 会优先选择使用自定义的数据映射关系。
在“迁移策略”点击“查看数据类型映射关系”可以查看源端 DB2 到目的端 DM 的数据类型映射关系,包括“源数据类型名”、“源精度”、“源标度”、“目的数据类型名”、“目的精度”等等。
- 勾选源端待迁移的数据库。
在指定需要迁移的模式阶段,用户可以通过勾选对应的“源模式”选择源端要迁移的模式,通过“目的模式”来指定要迁移到 DM 的模式,通过是否勾选“创建模式”、“表”、“视图”、“物化视图”、“序列”、“存储过程/函数”和“触发器”来指定目的端 DM 是否要迁入源端 DB2 中的这些对象。在创建迁移用户和表空间阶段已自动创建模式,这里无需勾选“创建模式”。
- 勾选源端数据库中需要迁移的对象。
点击“选择”功能,可对所有待迁移对象执行勾选操作。在此处,能够查看源端待迁移库中的全部对象,用户可自行确定并选择 DB2 需要迁移的具体对象。其中,触发器“TRG_AUDIT_LOG”在迁移评估阶段,由于 DM 与 DB2 存在语法差异,无法直接迁移,因此在此处不进行勾选。存储过程“ROW_COUNT”是在 DB2 中统计表格数据行数时创建的,无需迁移,同样不进行勾选。
注意勾选在 SQL 评估阶段兼容的对象,待其他对象迁移完成后,再手动修改和导入这些不兼容的对象。
待迁移具体对象勾选完毕后选中普通表所在的行,然后双击源表或点击“转换”进行自定义对象迁移策略。
(1)迁移策略
在迁移策略中可根据需要设置表及数据迁移的策略。在左侧选项中可以选择“表定义”、“主键”、“约束”、“索引”等的迁移策略;在右侧选项中可以配置与迁移数据相关的策略。
部分选项说明:
① 压缩:指定迁移的目的表是否按照压缩方式存储;
② 强制聚集索引:即使源表的主键为非聚集主键,创建目的表时也会被转换为聚集主键。
③ 强制非聚集索引:即使源表的主键为聚集主键,创建目的表时也会被转换为非聚集主键。
④ 启用标志列插入:如果表上有标志列,则迁移数据时会强制向标志列插入值,以保证源和目的数据完全一致。
⑤ 显示行数:将在迁移任务过程中,显示数据的行数。
⑥ 拷贝记录:如果目的表已存在,直接拷贝记录,不需要创建表。
⑦ 删除后拷贝记录:迁移过程中先删除已存在的目的表,再重新创建新目的表。
⑧ 源一次读取行数:设置从数据源中读取数据时每次读取数据的行数,该参数决定内存中缓存结果集的大小,对于数据量很大的数据源,设置该参数,可以控制内存的使用。
⑨ 目的一次提交行数:设置向目的数据库中每次写入数据的行数。当数据量比较大时,减小该参数的值可以减少内存的使用。但会影响迁移的速度。
⑩ 缓存批数:设置缓存队列的长度。调整该参数可以调整迁移过程中内存的使用。
⑪ 并发导出,并发数:设置并发导出执行的线程数。
⑫ 并发导入,并发数:设置并发导入执行的线程数。
注意如果数据量较大,可以选择先迁移表结构定义相关内容,再迁移数据,最后迁移索引。大字段建议单独迁移,且迁移大字段时建议把一次读取和一次提交的值调小,一般在 20 或以下效率可能会更好,较大值时迁移效率较低。
(2)列映射选项
在列映射选项中可根据需求修改源端迁移到目的端表的列名、数据类型、精度、小数位数、默认值、是否可空、主键、自增列、起始值、增量信息等。
本示例采用 DTS 默认的关系映射,因此维持默认设置,不作修改。
完成映射关系的配置之后,需勾选“应用当前选择项到其他同类对象”。选择该选项后,会弹出对话框,此时选择其他同类对象,将此策略应用于相同对象。若不勾选“应用当前选择项到其他同类对象”,则所配置的迁移策略仅对当前选中的表有效。
勾选“应用当前选择项到其他同类对象”后,勾选除分区表“SALES”之外的表,然后点击确定。
在该示例中,已知源端表“SALES”为分区表,由于 DB2 和 DM 在创建分区表上语法有区别,迁移时可通过“编辑 SQL”的功能修改创建表的语句。选中该表,点击“转换”。
点击“编辑 SQL”。
将修改完成的分区表创建语句复制到“创建表”的 SQL 编辑区,点击“确定”。在 DM 中创建分区表“SALES”的 SQL 如下:
CREATE TABLE sales (
order_id INT NOT NULL,
order_date DATE NOT NULL,
product_id INT,
amount DECIMAL(10,2),
PRIMARY KEY (order_id, order_date)
)
PARTITION BY RANGE(order_date) (
PARTITION p202301 VALUES LESS THAN ('2023-02-01'),
PARTITION p202302 VALUES LESS THAN ('2023-03-01'),
PARTITION p202303 VALUES LESS THAN ('2023-04-01'),
PARTITION p_max VALUES LESS THAN (MAXVALUE)
);
再点击“确定”。
迁移策略和列映射配置完成后点击下一步。
3.5.4 开始迁移
- 选择执行方式阶段,直接点击“下一步”。
- 检查迁移任务,确认迁移对象是否正确。检查确认后点击“完成”即可开始迁移。
- 迁移完成后可能看到由于 DB2 和 DM 数据库在某些语法上不同导致对象迁移失败。
点击“查看详细信息”,可确认迁移错误的详细信息,有助于定位问题。修改后,可尝试重新迁移出错的对象。若存在对象确实无法通过 DTS 迁移,可考虑手动将相关对象迁移至 DM 数据库。
3.5.5 对象补迁
鉴于 DB2 和 DM 数据库在部分语法运用方面存在差异,致使部分对象可能迁移失败,此外,在迁移评估阶段存在语法不兼容的对象未通过 DMDTS 迁移,用户需依据 DM 语法对这些无法借助工具迁移的对象进行手动修改,而后导入 DM 数据库。
在 DM 端手动创建该示例中迁移失败或未迁移的对象。
(1)视图“IDX_UPPER_VARCHAR_V”迁移未成功,经分析,该视图是在为表“ALL_DATA_TYPES”创建函数索引时,DB2 为提升检索效率而自动生成的视图。查看 DB2 中该视图 DDL 发现模式结尾存在空格,所以迁移失败。
本示例为确保目的端 DM 的视图与源端 DB2 保持一致,在 DM 端手动创建该视图,相应 SQL 如下:
CREATE VIEW "DB_TEST"."IDX_UPPER_VARCHAR_V" ("K00" )
AS
SELECT UPPER(COL_VARCHAR) FROM "DB_TEST"."ALL_DATA_TYPES";
(2)函数索引“IDX_UPPER_VARCHAR”迁移失败,手动在 DM 端创建该索引,SQL 如下:
CREATE INDEX "DB_TEST"."IDX_UPPER_VARCHAR" ON "DB_TEST"."ALL_DATA_TYPES"(UPPER(COL_VARCHAR));
(3)手动迁移未通过 DTS 迁移的触发器“TRG_AUDIT_LOG”,在 DM 中创建具备相同功能的触发器的 SQL 语句如下:
CREATE OR REPLACE TRIGGER "DB_TEST"."TRG_AUDIT_LOG"
AFTER INSERT ON "DB_TEST"."ALL_DATA_TYPES"
FOR EACH ROW
BEGIN
INSERT INTO AUDIT_LOG VALUES ( LOG_SEQ.NEXTVAL,
'ALL_DATA_TYPES',
'INSERT',
CURRENT_TIMESTAMP
);
END;
/
3.6 数据校验
通过 SQL 脚本分别统计 DB2 端和 DM 端的对象和数据量,通过对比判断是否迁移完成。脚本验证步骤如下:
- 统计用户下各类对象的数量,在源端和目的端通过查询对比是否一致。
- 统计用户下的表数量及对应的数据条目,比对数据,验证表的数量和数据量是否一致。
3.6.1 统计 DB2 端对象及数据
DB2 的对象统计可参考 3.1.2 章节-迁移对象统计相关内容。
3.6.2 统计 DM 端对象及数据
- 统计达梦数据库中相关用户的对象数。
SELECT OBJECT_TYPE,
COUNT(*)
FROM ALL_OBJECTS
WHERE OWNER='DB_TEST' --用户名,用户需根据实际情况修改。
AND OBJECT_NAME NOT LIKE 'INDEX%' --排除系统自己创建的索引
GROUP BY OBJECT_TYPE;
在 DM8 环境下,当创建物化视图时,会产生两个字典对象,即物化视图和物化视图表,其中物化视图表用于存放实际的数据。在 DM 端的统计数据里,TABLE 类型的对象包含了物化视图表。通过执行以下 SQL 查询可以发现,在本示例的 DM 端,创建物化视图“MATERIALIZED_VIEW_DATA”的同时生成了物化视图表“MTAB$_MATERIALIZED_VIEW_DATA”,所以实际的表数量应为 5。
select * FROM ALL_OBJECTS WHERE OWNER='DB_TEST' and OBJECT_TYPE='TABLE'
借助以下 SQL 对该示例视图做进一步详细统计,其数量共计 3 个,包含 2 个普通视图与 1 个物化视图。
select * FROM ALL_OBJECTS WHERE OWNER='DB_TEST' and OBJECT_TYPE = 'VIEW';
借助以下 SQL 对该示例自定义索引数量予以进一步详细统计,其数量为 8 个。
select * FROM ALL_OBJECTS WHERE OWNER='DB_TEST' and OBJECT_TYPE = 'INDEX' AND OBJECT_NAME LIKE 'IDX%';
- 统计 DB2 迁移过来的表的数据量并记录到辅助表。
CREATE TABLE DM_TABLES
(
TAB_OWNER VARCHAR(100),
TAB_NAME VARCHAR(100),
TAB_COUNT INT
);
DECLARE BEGIN FOR REC IN
(SELECT OWNER,
OBJECT_NAME
FROM ALL_OBJECTS
WHERE OWNER='DB_TEST' --用户名,用户需根据实际情况修改。
AND OBJECT_TYPE='TABLE'
)
LOOP
EXECUTE IMMEDIATE 'INSERT INTO DM_TABLES SELECT '''|| REC.OWNER ||''','''|| REC.OBJECT_NAME ||''',COUNT(*) FROM "'|| REC.OWNER || '"."' || REC.OBJECT_NAME||'"';
END LOOP;
END;
检查辅助表。
select * from DM_TABLES;
其中,表“DB2_OBJECTS”与表“TABLE_ROW_COUNT”是用于 DB2 对象统计及数据统计的辅助表。
3.6.3 对象及数据量对比
- 对象对比
通过对比 DB2 与 DM 中统计的对象数量及对象名称,检查是否完成所有对象的迁移,针对不对应的对象或缺失的对象进行重新迁移。
DB2 端前期调研统计的对象如下:
调研项 | 说明 |
---|---|
模式名 | DB_TEST |
表数目 | 3(不包含 2 张辅助表) |
视图数目 | 3(2 个普通视图,1 个物化视图) |
序列 | 1 |
函数 | 1 |
触发器 | 1 |
索引 | 8 |
目的端 DM 迁移后的对象统计如下:
调研项 | 说明 |
---|---|
模式名 | DB_TEST |
表数目 | 6(包含 2 张辅助表,和 1 个物化视图) |
视图数目 | 3(2 个普通视图,1 个物化视图) |
序列 | 1 |
函数 | 1 |
触发器 | 1 |
索引 | 8(自定义索引) |
对比 DB2 端与 DM 端的统计结果。
(1)在统计表格数量时,DM 端的物化视图“MATERIALIZED_VIEW_DATA”以表形式进行统计,同时统计了从 DB2 端迁移而来的 2 个辅助表。因此,业务实际表数量应为 3,与源端 DB2 业务表的数量一致。
(2)其他对象数量对比一致。
- 数据量对比
借助以下 SQL 命令对表数据量进行比对,找出数据量不相等的表并重新迁移数据。若结果集为空,则表明源端与目的端对应表的数据量一致。其中,TABLE_ROW_COUNT 为 DB2 迁移前用于统计所有表数据量的辅助表,DM_TABLES 为 DM 数据库中记录各表数据量的辅助表。
SELECT A."TABNAME",
A."ROW_COUNT",
A."ROW_COUNT"-B.TAB_COUNT
FROM DB_TEST."TABLE_ROW_COUNT" A,
DM_TABLES B
WHERE A."TABNAME"=B.TAB_NAME
AND A."TABNAME" NOT IN ( 'TABLE_ROW_COUNT','DB2_OBJECTS')--剔除辅助表
AND A."ROW_COUNT"-B.TAB_COUNT<>0;
对比结果为空表示迁移后目的端 DM8 与源端 DB2 的表数据行数一致。
3.7 统计信息与备份
3.7.1 更新统计信息
数据核对完成无问题后,应进行一次全库的统计信息更新工作。统计信息更新脚本示例如下:
按模式更新统计信息:
DBMS_STATS.GATHER_SCHEMA_STATS(
DB_TEST, --DB_TEST为模式名,需要根据实际情况修改为自己的模式名。
100,
FALSE,
'FOR ALL COLUMNS SIZE AUTO');
如果数据量较大,该过程执行较慢,需要等待一段时间。
按照表进行统计信息的收集:
DBMS_STATS.GATHER_TABLE_STATS(
'username',--用户名
'table_name',--表名
null,100,TRUE,'FOR ALL COLUMNS SIZE AUTO');
更新统计信息的目的在于大批量迁移数据后数据库系统未对用户数据进行全面分析存在错误的统计信息,可能会导致数据库优化器根据错误的统计信息得到错误的查询计划,严重影响查询性能。
更多更新统计信息方式可参考:统计信息。
3.7.2 备份
在对数据更新完统计信息后,在数据量不大,磁盘空间足够的情况下应进行一次数据备份工作,避免在数据验证过程中对数据产生修改需要重新迁移。数据备份有三种方式:
- 正常停止数据库后,拷贝备份到实例目录或保存数据文件的其他目录;
- 开启归档日志后,进行物理备份;
- 逻辑备份,使用 dexp 工具进行逻辑导出。
此外,通常生产系统都需要制定定时备份任务,备份时间点建议避开业务高峰期,可根据需要配置备份作业任务。
3.8 应用迁移
一般情况下,DB2 迁移完成后,需要更换应用连接数据源到达梦数据库。为了验证系统移植的完整性,还需要进行应用的相关功能和性能测试,并改造应用到连接达梦数据库一个最佳状态。
3.8.1 语言、接口、框架
应用在适配时,可以前往达梦在线服务平台-应用开发指南模块参考相关语言的适配指南。
四、SQL 日志开启与分析
数据库和应用系统移植完毕后开启 sql 日志,对系统进行全面测试,排除移植过程中错误的地方,对慢的 sql 语句进行优化。可以通过对 SQL 日志记录的慢 SQL 进行优化提升 SQL 执行效率。在开启 SQL 日志时可参考如下两个 SQL 日志参数的配置,通过在 sqllog.ini 中设置 SQL 过滤规则来记录需要优化的 SQL。
--设置SQL过滤规则
SQL_TRACE_MASK=2:3:22:23:25:28---指定 SQL 日志中需要被记录的语句类型,详细说明可参考达梦数据库安装目录下doc目录中《DM8系统管理员手册》。
MIN_EXEC_TIME=500 --记录执行时间大于500毫秒的SQL,用户需根据实际情况设置。
SQL 日志开启方法可参考达梦在线服务平台-运维指南-单机安装部署-配置 sql 日志。
在功能测试和性能测试的时候可以开启 SQL 日志,然后通过日志分析工具从执行时间和执行次数两个维度对 SQL 日志进行分析,生成分析结果,然后根据分析结果对系统性能进行优化。使用日志分析工具时最好采用 32k 页大小的 DM 作为分析库。
更多性能优化可参考达梦在线服务平台-运维指南-性能诊断与优化。
五、常见问题
1、DB2 数据库迁移至 DM 报错:java.io.CharConversionException
【问题描述】
DB2 数据库迁移至 DM,迁移过程中报错:java.io.CharConversionException
【问题解决】
在 DTS 的配置文件中添加参数 -Ddb2.jcc.charsetDecoderEncoder=3
。
Linux 下: dmdbms/tool/dts
添加参数。
Windows 下 :dmdbms/tool/dts.ini
添加参数。
2、DB2 迁移到 DM 如何适配函数 timestampdiff
【问题分析】
在 DB2 中,TIMESTAMPDIFF 函数用于根据两个时间戳之间的时差,返回由第一个参数定义的类型表示的估计时差。该函数返回的结果是一个整数,不过它存在一定局限性,其计算结果未考虑闰年情况,并且假设每个月都是 30 天,因此只能提供近似值。当 enddate 早于 startdate 时,函数会返回负整数。
{fn TIMESTAMPDIFF(interval-type, startdate, enddate)}
【问题解决】
如 DB2 中查询:
select timestampdiff(256, char(current timestamp - timestamp('2000-01-01-00.00.00.00'))) from sysibm.dual;
修改到 DM8:
select timestampdiff(month,to_date('2000-01-01-00.00.00.00','yyyy-mm-dd-HH24:MI:SS'), sysdate ) from dual;
函数 TO_DATE 解释
语法:TO_DATE(char [,fmt[,'nls']])
功能:将 CHAR 或者 VARCHAR 类型的值转换为 DATE 数据类型。TO_DATE 的结果不带小数秒精度。
参数 NLS:指定日期时间串的语言类型,取值:AMERICAN、ENGLISH 或 SIMPLIFIED CHINESE,分别表示美式英语、英语和简体中文,其中 AMERICAN 和 ENGLISH 的效果相同。例如,当将日期时间串指定为 2022-DECEMBER-12 时,应将 NLS 设置为 AMERICAN 或 ENGLISH。缺省为 SIMPLIFIED CHINESE。 这个参数的使用形式是:“NLS_DATE_LANGUAGE=''语言类型''”。更多参数说明可参考《DM8 SQL 语言使用手册》函数 TO_DATE。
六、更多帮助
更多 DB2 到 DM 迁移常见问题可参考达梦在线服务平台-常见问题-从其他数据库迁移到 DM。
更多 DTS 工具使用详情可参考 DTS 工具“帮助主题”,具体位置见下图: