达梦数据库数据迁移全流程：从调研、DTS实操到踩坑排查与核对

简介：《达梦数据库-数据迁移方式》是一份面向达梦数据库运维人员、信创迁移实施者及初中级DBA的PPT课件，聚焦数据从Oracle、MySQL、SQL Server、MariaDB等源端平稳迁入达梦数据库的完整流程与实战经验，内容直接贴合信创环境下数据库国产化替代的迁移场景。课件按“引言、迁移准备、正式迁移、总结”四章组织，系统梳理了迁移前调研的重点，如源端类型支持、网络连通性、带宽条件、图形化桌面环境与防火墙设置；工具选型部分对比了DTS、DMHS以及文件导入等不同路径；正式迁移环节则覆盖初始化参数确定、表空间规划、用户权限设置以及常见报错处理思路，包括驱动不匹配、系统错误、分析失败、表迁移成视图等典型问题，并配以获取源端DDL的示例，具有较强的工程参考价值。资源包内共1个文件，为pptx格式幻灯片，压缩包大小5.83MB，整体结构按4章组织，便于按主题检索学习。目前已有210人浏览学习，适合需要快速了解达梦数据库迁移准备与实施要点的DBA、运维及开发人员参考。

1. 达梦数据库数据迁移：一场先从调研开始的硬仗

数据迁移这事儿，看着就是把数据从 A 库搬到达梦数据库，真做起来十有八九要翻车。网络不通、驱动版本不对、表迁移完变成视图、初始化参数没对齐……每一桩都能让项目延期。我经手过的信创迁移项目里，凡是前期调研做得细的，正式迁移基本一次过；凡是上来就开 DTS 的，几乎都要返工。这篇笔记把达梦数据库数据迁移的完整流程拆开讲——调研、选型、初始化参数、DTS 实操、踩坑排查，最后再给一套迁移后的核对方法。读完你至少能避开我在项目里踩过的那些坑，在动手前就把八成问题堵死。

2. 迁移前调研与工具选型：网络不通、带宽差、客户端缺失的分支处理

2.1 调研清单：源端类型、网络、客户机、防火墙四问

迁移前的调研，核心就是确认四件事：源端数据库类型、源端和目的端网络情况、有没有客户端机器、目的端是否装了图形化桌面。这四个问题直接决定你后面选哪条迁移路线。很多人拿到任务就开始装 DTS，结果源端是个 MariaDB，DTS 解析报错率极高，最后只能绕道。我一般会在入场第一天就把这个清单发给现场同事，让他们逐项确认，避免正式迁移时才发现环境不支持。

第一问：源端数据库类型是不是 DTS 支持的类型。Oracle、MySQL、SQLServer、DB2 这些主流库问题不大，但如果源端是 MariaDB 这种比较少见的分支，DTS 的 DDL 解析经常出幺蛾子，建议通过中间库中转——把 MariaDB 先迁到 MySQL，再从 MySQL 迁到达梦。第二问：源端和目的端的网络通不通。网络不通不是死路，但要走备份还原或文件导入的路线，耗时和操作复杂度都会上一个台阶。第三问：有没有客户端机器。有客户端机器，DTS 这种图形化工具才有地方跑；没有的话，要么直接在服务器上操作，要么走命令行。第四问：目的端服务器是否装了图形化桌面、防火墙是否开放。没桌面、有防火墙，DTS 连不上，就得换 DMHS 或者文件装载。

这四问的逻辑关系是层层递进的。类型决定能不能用 DTS，网络决定要不要走中转，客户端机器决定工具跑在哪，防火墙和桌面决定连接方式。任何一项不满足，你选的迁移工具就可能是错的。我见过最典型的案例：客户环境有防火墙，DTS 连不上目的端，现场工程师硬是把目的端防火墙关了才跑通——项目上是过了，但安全审计的时候差点出事。正确做法是提前问清楚，然后根据约束条件选方案。

2.2 网络不通的两条兜底路线：临时实例中转与文件导入

网络不通的情况在实际项目中很常见，尤其是源库在隔离网段、目的端在另一个网段的时候。这时候有两个兜底方案，我建议按数据量和是否集群来决定走哪条。

第一条路线：在源端临时部署一套同样版本的达梦数据库，初始化参数和正式环境保持一致，先用 DTS 把数据迁到临时实例，再通过备份还原或者导出导入的方式把临时实例的数据搬到正式环境。这条路线适合数据量大、源端到目的端完全隔离的场景。但要注意一个坑：正式环境如果是集群，选择物理备份还原的话，备份集里带着集群配置信息，还需要重搭集群，工作量不小。数据量不大时，更推荐导出 dmp 包再导入，规避掉集群配置问题。

第二条路线：把源端数据导出成 txt 或 Excel 文件，拷到达梦服务器上，再用 dmfldr 或 DTS 批量导入。这条路线操作最简单，但不适合有时间字段、二进制字段或者数据量上千万张表这种场景。dmfldr 对文本格式要求严格，字段分隔符、行分隔符、NULL 值标识都要提前约定好，不然导入到一半报错，排查起来很费劲。我一般会在导出前先和达梦侧确认目标表结构，用 SELECT 语句按列顺序导出，保证字段一一对应。

这两条路线的工作量差异很大。临时实例中转，前置准备至少半天；文件导入，前置准备 1-2 小时，但导入过程中的坑更多。我的建议是：数据量超过 500 万行或者源库有复杂对象（分区表、自定义类型），优先临时实例中转；数据量不大、都是普通表结构，走文件导入更快。

2.3 网络相通的工具选型：DTS、DMHS、dmfldr 怎么选

网络相通的情况下，工具选择主要看带宽、客户端机器、图形化桌面这三个条件。我把不同组合的选型结论整理成了一个表格，项目上直接对着查就行：

这里要特别说下 DTS 和 DMHS 的分工。DTS 适合一次性全量迁移，操作界面直观，能看进度、能跳过错表继续跑；但 DTS 依赖 JDBC 连接，对网络质量敏感，带宽差的时候经常卡在数据传输环节。DMHS 走的是日志解析同步，适合增量同步场景，对网络抖动没那么敏感，但配置复杂度高，而且源端数据库必须是 DMHS 支持的类型。所以如果条件允许，我会先看源端类型，再看带宽：带宽好、类型支持，直接 DTS；带宽差、类型支持，上 DMHS；DMHS 不支持源端类型，就回到导出文件加 dmfldr 快速装载的路线。

3. 目标端初始化参数与磁盘规划：页大小、大小写敏感、目录划分一次定死

3.1 初始化参数：页大小、字符集、大小写敏感必须提前定死

达梦数据库的初始化参数有个特点：库建好了之后，页大小、簇大小、字符集、大小写敏感这些参数就改不了了，也没法像 Oracle 那样通过参数文件动态调整。这意味着你在 dminit 阶段就必须把参数定死，不然后面迁移到一半发现字符集不对，只能删库重建，所有表结构全部重来。这就是为什么我一直强调，迁移前先花半天时间把初始化参数确认清楚，比后面返工省太多时间。

页大小决定单行数据能存多大。达梦的页大小支持 4KB、8KB、16KB、32KB，一般默认 8KB 就够了。如果源端表里有大的 text、blob 字段，或者单行长度超过页大小的一半，就会报"行长度超出页大小限制"的错误。遇到这种表，要么升级页大小，要么改表结构。字符集编码建议统一 UTF-8，除非源端明确是 GBK 而且无法转码。大小写敏感这个参数要特别小心：达梦默认大小写敏感，如果源端是 Oracle，保持大小写敏感没问题；如果源端是 MySQL 且建表时用了小写表名，迁过来后 SQL 里的表名大小写都可能变成一个新的坑。

VARCHAR 类型对象的长度是否以字符为单位，这个参数也容易出问题。设置为以字符为单位时，VARCHAR(100) 能存 100 个汉字；按字节为单位时，VARCHAR(100) 在 UTF-8 下只能存 33 个汉字。源端是 Oracle 的话，建议保持以字符为单位，这样字段长度语义一致。下面是一段 dminit 初始化命令的示例，参数按信创项目常见配置写的：

dminit PATH=/dmdata PAGE_SIZE=8192 CLUSTER_SIZE=32 \ CHARSET=1 CASE_SENSITIVE=1 LENGTH_IN_CHAR=1

逻辑说明：PATH 指定实例数据文件存放路径；PAGE_SIZE 和 CLUSTER_SIZE 分别设置页大小和簇大小；CHARSET 设为 1 表示 UTF-8，0 表示 GBK；CASE_SENSITIVE 设为 1 表示大小写敏感；LENGTH_IN_CHAR 设为 1 表示 VARCHAR 长度按字符计算。

参数说明：这三个参数（PAGE_SIZE、CHARSET、CASE_SENSITIVE）在 dminit 之后不可修改，必须在初始化前和业务方、DBA 一起确认。如果拿不准字符集，就看源端数据库的字符集设置，源端是 Oracle 且字符集是 AL32UTF8，就选 UTF-8；源端是 GBK 且数据里有大量中文且不打算转码，才考虑 GBK。我一般在初始化前会把这几项参数写成文档发邮件确认，留个记录，防止事后扯皮。

3.2 INI 参数与兼容性调整：COMPATIBLE_MODE=2 的场景边界

初始化参数定了之后，还有一批 INI 参数需要调整，其中最关键的是 COMPATIBLE_MODE。这个参数控制达梦数据库的兼容模式：0 是默认模式，1 是兼容 SQLServer，2 是兼容 Oracle，3 是兼容 MySQL。大部分信创项目源端是 Oracle，所以 COMPATIBLE_MODE=2 是常态。但这个参数不是设了就万事大吉，它只影响部分语法和函数行为的兼容，不等于你能把 Oracle 的 SQL 原封不动搬过来。

我遇到过一个很典型的场景：源库是 Oracle，用了大量的 ROWNUM 分页、DECODE 函数、Dual 表查询。COMPATIBLE_MODE=2 下这些语法大部分能跑，但有些还是有差异，比如 Oracle 的 (+) 外连接写法在达梦里就报错，必须改成标准的 LEFT JOIN。另外，达梦的自动参数优化脚本值得跑一遍，它能根据 DBA 模式和兼容模式，把一系列相关 INI 参数一起调好，省得一个个手工改。

INI 参数调整的另一个重点和磁盘空间规划相关。迁移前必须确认归档日志目录、备份文件目录的磁盘空间是否充足。归档日志增长速度和迁移期间的数据量直接相关，如果只给 /dmarch 分了 20G，迁移一个 200G 的库，跑到一半归档写满，数据库直接挂起。我一般按源库数据量的 1.5 倍来规划归档空间，并给备份目录留出同样的余量。

3.3 磁盘目录、表空间、redo 与用户的落地脚本

磁盘目录划分这块，达梦官方推荐的做法是：数据文件放 /dmdata，归档日志放 /dmarch，备份文件放 /dmbak，程序文件放 /dmdb。这个划分不是拍脑袋定的，而是为了让数据文件、归档、备份走不同的挂载点，避免一个磁盘满了把整个实例拖死。安装前要让总集把磁盘挂好并做好 RAID，顺序不要搞反——先挂载和 RAID，再安装数据库，否则后面扩容很被动。

表空间规划方面，要预先创建好业务表空间并根据数据量提前分配大小，同时把 redo 日志扩大到 2G。达梦默认的 redo 文件比较小，迁移大批量数据时很容易写满，扩大 redo 是减少迁移中断的有效手段。下面是建表空间、加 redo、建用户的完整脚本：

-- 创建业务表空间，数据量预估 100G，数据文件初始分配 50G CREATE TABLESPACE TS_DATA DATAFILE '/dmdata/TS_DATA01.DBF' SIZE 51200; ALTER TABLESPACE TS_DATA ADD DATAFILE '/dmdata/TS_DATA02.DBF' SIZE 51200; -- 创建索引表空间 CREATE TABLESPACE TS_IDX DATAFILE '/dmdata/TS_IDX01.DBF' SIZE 20480; -- 扩大 redo 日志到 2G ALTER DATABASE ADD LOGFILE '/dmdata/redo03.log' SIZE 2048; -- 创建业务用户，指定默认表空间和索引表空间 CREATE USER APP_USER IDENTIFIED BY "Password_123" DEFAULT TABLESPACE TS_DATA INDEX TABLESPACE TS_IDX; -- 授权 GRANT DBA TO APP_USER;

逻辑说明：CREATE TABLESPACE 指定数据文件路径和初始大小；ALTER TABLESPACE ADD DATAFILE 扩展第二个数据文件；ALTER DATABASE ADD LOGFILE 新增一个 2G 的 redo 日志文件；CREATE USER 时用 DEFAULT TABLESPACE 和 INDEX TABLESPACE 把用户对象落到业务表空间，避免数据堆到系统表空间。

参数说明：SIZE 的单位是 MB，51200 代表 50GB。TABLESPACE 的大小不用一次给足，但要保证迁移期间不触发自动扩展，否则频繁扩展数据文件会影响 DTS 的写入性能。用户密码建议用强密码，生产环境不要用默认密码。GRANT DBA 这步在测试环境可以图省事，生产环境按最小权限原则授权，只给业务需要的权限。

这里还要强调一个原则：不允许把数据迁移到 SYSDBA 用户下，也不允许用 MAIN 表空间。原因有两层：一是 SYSDBA 是达梦的超级管理员，业务表和系统表混在一起，备份恢复、权限管理都容易出问题；二是 MAIN 表空间是系统默认表空间，后续做表空间级别的维护、扩容时无法单独操作。我见过一个项目，迁移时图省事没建用户，所有表都建在 SYSDBA 下，结果达梦版本升级时连回滚方案都没有，最后只能重新迁移一遍。

4. DTS 迁移实操：DDL 获取到装载的完整链路与参数配置

4.1 DTS 迁移原理：五个步骤拆解

DTS 看起来是一个图形化工具，实际内部是五个步骤串起来的流程：获取源端 DDL、解析 DDL 并转化为达梦支持的 DDL 语句、在达梦数据库中执行 DDL、获取源端数据、传输到目的端并装载。理解这五步，你就能看懂错误信息到底出在哪一环。

第一步获取源端 DDL，DTS 会通过 JDBC 连接源库，调用数据库自带的元数据接口拿建表语句。这一步最依赖驱动版本，驱动不对或者版本太老，拿到的 DDL 就是残缺的。第二步解析 DDL，把源端的建表语句翻译成达梦语法，这是 DTS 最容易出问题的环节。源端用了达梦不支持的数据类型、函数默认值、或者奇怪的约束写法，解析就会失败，报"分析失败"错误。第三步在达梦执行 DDL，这一步报错通常是权限不足或者表空间不存在。第四步和第五步是数据传输和装载，报错多半是网络中断、驱动连接超时、目的端表空间不够。

前面说的 DTS 报错率高的场景，比如 MariaDB，问题就出在第二步——DTS 的 DDL 解析器是针对主流数据库做过适配的，MariaDB 的某些 DDL 写法它识别不了。这也是为什么遇到冷门数据库要先中转。

4.2 JDBC 驱动版本对照与准备

DTS 连接源端数据库依赖 JDBC 驱动，驱动版本不对是迁移过程中出现"系统错误"最常见的原因。很多项目现场图省事，随便找一个驱动就填进 DTS 配置里，结果连接报错或者拿到不完整元数据。我的习惯是在进场前就把驱动准备好，条件允许的情况下直接从源端数据库安装目录下拷贝。Oracle 的驱动版本和 JDK 版本有对应关系，整理了一张对照表可以参考：

MySQL 这边，装了 MySQL Community Connector J 8.0 就有对应驱动。驱动版本不是越新越好，关键要和源端数据库版本、DTS 版本匹配。我踩过一个坑：用 ojdbc8 连接 Oracle 11g，DTS 反复报"系统错误"，换成 ojdbc6 之后一切正常。所以我在 DTS 的驱动配置上从来不追求最新，而是按源库版本查对应的驱动包。

4.3 MySQL 到 DM 的实操步骤与参数配置

MySQL 到达梦是信创项目里频率最高的迁移组合，我把完整操作步骤拆出来。第一步是确认源端和目标端的字符集、大小写敏感等基础参数对齐；第二步是在目标端建好表空间和用户；第三步是配置 DTS 迁移任务。

DTS 配置时有几个关键参数要注意。JDBC URL 的写法直接影响连接方式，MySQL 的 URL 里要带上 useUnicode=true 和 characterEncoding=utf8，否则中文导入后乱码。端口、时区参数也要看源库的实际配置对齐。在 DTS 的映射设置里，建议先不勾选"创建表"，而是在目标端预先建好表，这样做的好处是表结构可以手工调整，避免 DTS 生成的 DDL 不符合预期。

源端检查阶段，有一个 SQL 可以用来快速浏览源库的所有表清单和行数，方便迁移后核对：

-- MySQL 源端查看所有库的表数量和数据量 SELECT table_schema, table_name, table_rows FROM information_schema.tables WHERE table_schema = 'business_db' ORDER BY table_rows DESC;

逻辑说明：information_schema.tables 是 MySQL 自带的元数据视图，table_rows 是 MySQL 估算的行数，不是精确值，但迁移前看量级够用了。table_schema 过滤出业务库，table_name 拿到具体表名，table_rows 排序后就能看出哪些是大表。

参数说明：table_schema 要替换成实际的库名；table_rows 是估算值，如果发现某个表显示 0 行但实际有数据，是因为 InnoDB 的统计信息没更新，可以使用 ANALYZE TABLE 刷新后再查。这个查询结果建议导出保存，迁移完成后和目标端数据量做对比。

DTS 任务跑起来之后，还要做一次参数核对：源端和目标端的 JDBC 驱动、网络端口、表空间映射关系，一项一项确认。DTS 任务跑到一半失败的情况很常见，失败后不会自动续跑，而是以表为单位回滚，所以我在迁移前会先跑一个只迁移表结构不迁移数据的任务，验证 DDL 解析没问题后，再跑全量迁移。

5. 迁移踩坑排查：系统错误、分析失败、表变视图的定位与绕过

5.1 DTS 报系统错误和分析失败：先查驱动和 DTS 版本

现象：DTS 任务启动后，在获取源端 DDL 或者分析 DDL 阶段报"系统错误""分析失败"，错误信息里没有具体 SQL 或表名，无法直接定位。

原因：绝大多数情况是 JDBC 驱动不对或者 DTS 版本不兼容。驱动包版本和源库不匹配，DTS 调用源库元数据接口时拿到异常数据，解析器就崩了。另一种情况是 DTS 版本本身有 bug，同一个迁移任务在新版 DTS 上报错、在旧版 DTS 上却能跑通。

解决：先换 JDBC 驱动，按 4.2 节的对照表选对应版本；驱动换完还报错，就换 DTS 版本。这里有个血泪经验：达梦 DM7 的早期 DTS 版本比某些新版本反而更稳定，所以电脑上多备份几个 DTS 版本是值得的。换完版本后，重新加载迁移任务，错误一般会消失。如果错误信息里带了表名，记录下这个表，单独导出建表语句手工处理后再继续。

5.2 表迁移成视图：MariaDB 迁过去的怪现象

现象：源端是 MariaDB，迁到达梦后，源端明明是表，目标端却变成了视图。查询数据没问题，但业务程序对视图做 INSERT、UPDATE 时报错，程序直接不可用。

原因：MariaDB 的 DDL 和 MySQL 有差异，DTS 在解析 MariaDB 的建表语句时，某些表类型的定义被错误映射成了达梦的视图。DTS 对 MariaDB 的支持本来就不完善，出现这种映射错误很正常。

解决：不要从 MariaDB 直接迁到达梦，中间加一个 MySQL 中转。先用 Navicat 把 MariaDB 迁移到 MySQL，再从 MySQL 迁到达梦。MariaDB 到 MySQL 这一步，Navicat 可以识别表结构差异并自动转换；从 MySQL 到达梦，DTS 的解析器就认识这些 DDL 了。中转会产生额外的磁盘和时间开销，但比起目标端一堆视图导致业务不可用，这个代价完全可以接受。

5.3 目的端是集群时选择备份还原：要算上重搭集群的时间

现象：源端数据量很大，选择临时达梦实例中转 + 备份还原的方式往正式环境迁移，结果备份集还原到集群环境时报错，或者还原成功但集群状态异常，需要重搭集群。

原因：物理备份集里包含了实例的配置信息和集群标记，还原到不同的集群环境时，这些信息会对不上。

解决：数据量不大就改用导出 dmp 包再导入的方式，绕开集群配置。数据量实在太大、必须走物理备份还原的话，要把重搭集群的时间算进项目计划里，不要天真地以为还原完就能直接用。迁移前和集群负责人确认重搭流程，预留至少半天时间。

5.4 获取源端 DDL 失败：各数据库的 DDL 获取方式对照

现象：DTS 在第一步获取源端 DDL 时就卡住，目标端一张表都没建出来。排查 JDBC 驱动、DTS 版本都没问题，但 DTS 还是拿不到 DDL。

原因：DTS 内部使用数据库特定的元数据接口拿 DDL，这个接口在某些数据库版本上可能被限制或语法不兼容，导致获取返回为空。

解决：手工获取 DDL 后用脚本在目标端执行，绕过 DTS 的 DDL 获取环节。四种主流数据库的获取方式如下：

拿到 DDL 后，在目标端先手工执行一遍建表语句，再使用 DTS 里"只迁移数据"的模式。这个操作会丢掉 DTS 自动建表的能力，但能保证表结构完全可控，适合表数量不多、结构复杂的场景。表特别多的情况下，可以把源端 DDL 导出成文件，写脚本批量转换关键字（比如把 MySQL 的 AUTO_INCREMENT 换成达梦的 IDENTITY），再批量执行。

6. 迁移后的核对技巧：数据量比对、DDL 抽查与回滚习惯

6.1 数据量比对的 SQL 脚本

迁移完成不等于迁移成功。我每次做完迁移，都要跑一遍数据量比对脚本，确认源端和目标端每个表的行数一致。达梦这边可以用 DBA_TABLES 视图加动态 SQL 来统计，MySQL 源端则用 information_schema.tables。两边导出的结果做一次全量比对，重点看大表。

-- 达梦端生成统计所有表行数的动态 SQL SELECT 'SELECT ''' || table_name || ''', COUNT(*) FROM ' || owner || '.' || table_name || ';' FROM dba_tables WHERE owner = 'APP_USER';

逻辑说明：这段 SQL 的作用是生成一批统计行数的 SELECT 语句，每张表一条。把生成的语句复制出来，在达梦中逐条执行，得到每个表的行数。owner 要替换成业务用户，不要统计 SYSDBA 下的系统表。

参数说明：table_name 拼接时会包含 schema 前缀，避免重名表；执行结果建议导出到 CSV 文件，再用Excel或脚本和源端统计结果做比对。差异超过阈值（我一般定 0.1%）的表要单独查。

比对完了再做 DDL 抽查：随机抽几张关键业务表，对比源端和目标端的列类型、默认值、约束、索引定义。数据量一致不代表结构一致，DTS 解析 DDL 时可能把某些约束类型转了，比如把 Oracle 的 VARCHAR2 转成了 VARCHAR，把 CHECK 约束丢了。这部分如果业务对约束有强依赖，最好做一轮手工核对。

6.2 迁移前的快照与回滚习惯：给自己留后悔药

数据量比对通过之后，还要做应用级的功能测试和性能测试。但比这个更重要的，是迁移前就留好回滚方案。我现在的习惯是：正式迁移开始前，目标端实例做一次完整备份，源端保留原始导出文件，这样迁移出了问题可以快速回滚，而不是当场想办法补数据。

以前我接手过一个项目，迁移完成后的第三天，业务发现某个字段的值全乱了。查下来是 DTS 的字符集映射有问题，一批特殊字符在迁移时被替换掉了。因为迁移前没做备份，只能重新跑一遍全量迁移，前后花了四天时间。从那以后，我每次做迁移都强制走一遍"迁移前备份 + 迁移后比对 + 保留出口"三个步骤，哪怕业务说"数据丢了也没关系"，我也不会跳过。数据迁移是个不能后悔的活，提前把回滚方案准备好，真出了事你才知道这有多值钱。希望这些方法和坑能帮到你少走弯路。

本文还有配套的精品资源，点击获取