简介：这份PPT资料聚焦达梦数据库的数据迁移方式，面向正在参与信创项目、PK测试或日常数据库运维的DBA与开发人员，帮助解决从异构数据库或文本数据向达梦迁移过程中遇到的各类实际问题。资源包内仅含1个pptx文件，整体约5.83MB，以幻灯片形式系统梳理迁移流程，内容涵盖迁移前调研、网络与工具选择、正式迁移及常见问题处理等模块。资料从项目背景、移植范围、时间与性能目标、风险评估等准备事项切入，详细讲解源端类型确认、网络连通性判断、DTS与DMHS等工具选型，以及初始化参数、表空间划分、JDBC驱动匹配等关键配置。针对系统错误、分析失败、表被迁移成视图等典型故障，也给出了获取源端DDL、更换驱动或版本、借助中间库中转等排错思路。目前已有211人学习，适合需要快速掌握达梦迁移方法论、对照排查迁移障碍的技术人员参考。
1. 从一次 PK 测试翻车说起：这份达梦迁移 PPT 到底值不值得存
去年信创项目集中交付那阵子，我手上有个系统要在两周内从 Oracle 切到达梦，甲方还卡着 PK 测试的时间点。当时我自信满满地打开 DTS 就开干，结果源端一张带触发器的表死活分析不过去，折腾到凌晨两点才发现是 JDBC 驱动版本对不上。那次血泪经验让我意识到，数据迁移这件事，工具会用只是入门，真正决定成败的是迁移前的调研和参数规划。这份《达梦数据库-数据迁移方式》的 PPT，讲的正是从迁移准备、工具选型到正式迁移和常见问题处理的完整链路，它不是 API 手册，而是一线实施视角的避坑地图。适合正在做信创替换的 DBA、实施工程师，以及需要把 Oracle、MySQL、SQL Server 等异构库往达梦搬的团队。如果你只想知道 DTS 按钮在哪，这份材料可能偏重；但如果你想搞清楚“什么场景该选 DTS、什么场景必须换 DMHS、初始化参数怎么定”，它值得你花时间拆一遍。
2. 迁移准备：调研清单与工具选型的决策逻辑
2.1 迁移前必须确认的六个问题
PPT 里把迁移准备拆成了项目背景、移植范围、移植时间、性能目标、移植测试、风险评估六个维度，这个框架看着像项目管理模板，但落到实操上，它对应的其实是几个非常具体的判断。我一般会把它们压缩成一张调研清单，逐项打勾之后才敢动手。
| 调研项 | 具体确认内容 | 不确认的后果 |
|---|---|---|
| 源端类型 | 是否是 DTS 支持的类型 | 遇到 MariaDB 等冷门库，DTS 报错率极高 |
| 网络连通性 | 源端、目的端、客户端三者是否互通 | 不通就得走临时库中转或文件导出 |
| 客户端机器 | 是否有独立客户端、带宽如何 | 带宽差时 DTS 传输大表会超时中断 |
| 图形化桌面 | 目的端服务器是否安装 | 没有桌面就只能走命令行或 DMHS |
| 防火墙 | 需要开放哪些端口 | 端口没开，DTS 连不上源端 |
| 磁盘规划 | 数据、归档、备份目录是否分开 | 混在一起后期扩容极其痛苦 |
这张表里最容易被忽略的是“客户端机器和带宽”。很多人觉得网络通就行，但 DTS 是 Java 客户端工具，它要从源端拉数据再推到目的端，如果客户端到源端的带宽只有几兆，一张千万级大表迁到一半断掉，重头再来心态直接崩。PPT 里给了一个很实在的建议：网络不通时，可以在源端临时部署一套同版本达梦，先把数据迁到临时环境，再通过备份还原或导出导入搬到正式环境。这个思路的本质是把“跨网络迁移”降级成“本机迁移 + 物理搬运”，绕开了网络瓶颈。
2.2 工具选型：DTS、DMHS 和文件装载的边界
PPT 里把迁移工具选择分成了五种场景，我把它整理成更直观的决策路径。核心判断依据就两个：客户端到服务器的网络质量，以及目的端有没有图形化桌面。
# 场景判断伪代码，帮你快速定位该用哪个工具 if 有客户端机器 and 带宽充足 and 无防火墙阻断: 用 DTS 图形化迁移 elif 有客户端机器 and 带宽充足 and 有防火墙: 用 DTS，但需提前开放端口 elif 有客户端机器 and 带宽较差: 用 DMHS（需确认源端类型是否支持） elif 无客户端 and 目的端有图形化桌面: 在目的端直接装 DTS 跑 elif 无客户端 and 目的端无图形化桌面: 用 DMHS 或 dmfldr 快速装载 else: 导出 txt/Excel → 拷贝 → dmfldr 导入这段逻辑里，DMHS 的定位是“对网络带宽不敏感”的迁移工具，它更适合源端和目的端直连、但客户端到两端网络都不好的场景。但 PPT 特别提醒了一句：要注意源端数据库是否是 DMHS 支持的类型，如果不支持，就得走“导出文件 + 快速装载”的路子。dmfldr 是达梦自带的命令行快速装载工具，适合处理文本文件导入，它的优势是不依赖图形界面，在纯命令行环境里很稳。
提示：MariaDB 是个特殊案例。PPT 明确说 DTS 迁 MariaDB 报错率很高，建议先通过 Navicat 把 MariaDB 迁到 MySQL，再从 MySQL 迁到达梦。这个“中间库中转”的思路在异构迁移里很常见，本质是用一个 DTS 支持更好的库做跳板。
3. 正式迁移：初始化参数与 DTS 配置的实操细节
3.1 初始化参数定生死：页大小、簇大小和字符集
达梦数据库的初始化参数是在创建实例时确定的，后期修改成本极高，所以这一步必须一次做对。PPT 里列了五个关键参数：页大小、簇大小、字符集编码、大小写敏感、VARCHAR 长度是否以字符为单位。
页大小决定单行记录的最大长度和 I/O 效率，OLTP 场景常用 16K，OLAP 场景可以到 32K。簇大小影响空间分配的粒度，一般保持默认 16 或 32 即可。字符集编码必须和源端对齐，否则迁移后中文乱码，这个坑我踩过——源端是 GBK，达梦初始化选了 UTF-8，迁完发现所有中文变成问号，只能重建实例重来。大小写敏感参数决定了表名和字段名是否区分大小写，如果源端是 MySQL 的 lower_case_table_names=1 模式，达梦这边也要设成不敏感，否则应用层 SQL 全报错。
# dm.ini 关键参数参考（迁移场景） COMPATIBLE_MODE = 2 # 兼容 Oracle 模式，MySQL 源端可设为 4 PAGE_SIZE = 16 # 页大小，单位 KB EXTENT_SIZE = 32 # 簇大小 CHARSET = 1 # 1 表示 UTF-8，需与源端一致 CASE_SENSITIVE = 1 # 1 敏感，0 不敏感 LENGTH_IN_CHAR = 1 # VARCHAR 长度以字符为单位COMPATIBLE_MODE 这个参数值得单独说。它控制达梦的 SQL 语法兼容性，设为 2 时兼容 Oracle，设为 4 时兼容 MySQL。PPT 里建议参考参数自动优化脚本，我一般会在迁移前用达梦自带的脚本跑一遍，让它根据源端类型自动推荐参数组合。调整完 INI 参数后需要重启实例生效，所以这一步必须在正式迁移前完成。
3.2 表空间和用户规划：别把数据迁到 SYSDBA 下
PPT 里有一句话我特别认同：“不允许把数据迁移到 SYSDBA 用户下和 MAIN 表空间下。”这是很多新手会犯的错误——图省事直接用 SYSDBA 建表，结果后期权限管理、备份恢复、性能调优全乱套。
正确的做法是：预先创建独立的表空间，数据表和索引分开存放，然后创建业务用户并指定默认表空间。磁盘目录也要提前规划好，数据文件、归档日志、备份文件、程序文件分别放在不同目录，避免单目录写满导致数据库挂起。
-- 创建表空间和用户的标准流程 CREATE TABLESPACE TS_DATA DATAFILE '/dmdata/ts_data01.dbf' SIZE 1024 AUTOEXTEND ON; CREATE TABLESPACE TS_INDEX DATAFILE '/dmdata/ts_index01.dbf' SIZE 512 AUTOEXTEND ON; CREATE USER APP_USER IDENTIFIED BY "App@12345" DEFAULT TABLESPACE TS_DATA; GRANT RESOURCE, PUBLIC TO APP_USER; ALTER USER APP_USER DEFAULT INDEX TABLESPACE TS_INDEX;这段 SQL 里，AUTOEXTEND ON 让数据文件在写满后自动扩展，避免迁移中途因空间不足中断。索引表空间单独指定是为了让索引和数据物理分离，减少 I/O 争用。redo 日志建议扩大到 2G，PPT 里也提到了这一点，因为迁移过程中大量 DDL 和 DML 操作会产生密集的日志写入，redo 太小会导致频繁切换，拖慢迁移速度。
3.3 DTS 迁移原理与参数配置
DTS 的迁移流程 PPT 拆成了五步：获取源端 DDL、解析并转化为达梦 DDL、在达梦执行 DDL、获取源端数据、传输到目的端并装载。理解这个流程的价值在于，当迁移报错时你能快速定位是哪一步出了问题。
比如“分析失败”通常发生在第二步，原因是源端 DDL 里有达梦不支持的语法，或者 JDBC 驱动版本不对导致 DDL 获取不完整。“表迁移成视图”这种诡异现象，PPT 里说在迁移 MariaDB 时会出现，本质是 DDL 解析时类型映射出错，解决方案就是走 MariaDB → MySQL → 达梦的中转路线。
DTS 参数配置里，最关键的几个是：源端 JDBC 驱动路径、连接 URL、批量提交大小、并发线程数。批量提交大小默认 1000 行，大表迁移时可以调到 5000 甚至 10000，但要注意 undo 表空间是否够用。并发线程数根据目的端 CPU 和 I/O 能力调整，一般 4 到 8 个线程比较稳妥，开太多反而会因为锁竞争导致性能下降。
# DTS 命令行方式启动（部分版本支持） ./dts.sh -source_type oracle \ -source_url "jdbc:oracle:thin:@192.168.1.100:1521/ORCL" \ -source_driver "/opt/drivers/ojdbc8.jar" \ -dest_url "jdbc:dm://192.168.1.200:5236" \ -batch_size 5000 \ -thread_num 6这段命令里的 source_driver 参数就是 PPT 强调的“更换源端 JDBC 驱动指定 URL 的方式迁移”。Oracle 的驱动版本和 JDK 版本强相关，classes12.jar 对应 JDK 1.2/1.3，ojdbc8.jar 对应 JDK 8，选错了 DTS 直接报“系统错误”。PPT 里建议条件允许时从源端数据库中拷贝驱动，这是最稳妥的做法，因为源端自带的驱动一定和源端版本匹配。
4. 避坑与排查：迁移现场最常见的五类翻车
4.1 驱动不对导致“系统错误、分析失败”
现象：DTS 连接源端成功，但一到获取 DDL 或分析阶段就报“系统错误”或“分析失败”，日志里只有一行模糊的异常堆栈。
原因：JDBC 驱动版本和源端数据库版本不匹配，或者驱动 jar 包不完整。Oracle 的 ojdbc14.jar 在 JDK 8 环境下可能加载失败，MySQL 的 Connector/J 8.0 和 5.7 的协议也有差异。
解决：先确认源端数据库版本和 JDK 版本，然后从源端安装目录下拷贝对应的驱动 jar。Oracle 各版本驱动对应关系是：classes12.jar 用于 JDK 1.2/1.3，ojdbc14.jar 用于 JDK 1.4/5.0，ojdbc5.jar 用于 JDK 5.0，ojdbc6.jar 用于 JDK 6.0，ojdbc7.jar 用于 JDK 7.0，ojdbc8.jar 用于 JDK 8.0。在 DTS 里手动指定驱动路径和 URL，不要用默认的。
4.2 表迁移成视图
现象：迁移完成后，在达梦里查询某张表，发现它变成了视图，数据也不对。
原因：PPT 明确指出这是迁移 MariaDB 时的典型问题，根源是 DDL 解析时类型映射出错，MariaDB 的某些表定义被错误识别成了视图定义。
解决：不要直接迁 MariaDB 到达梦。先用 Navicat 把 MariaDB 迁到 MySQL，再从 MySQL 迁到达梦。Navicat 对 MariaDB 到 MySQL 的兼容性处理得很好，这一步基本不会丢东西。到了 MySQL 之后，DTS 的解析就稳定了。
4.3 网络带宽不足导致大表迁移中断
现象：小表迁移正常，一到大表就卡住，进度条长时间不动，最后报连接超时。
原因：DTS 是客户端工具，数据要从源端拉到客户端再推到目的端，客户端到源端的带宽成了瓶颈。PPT 里专门问了“客户端机器和源端、目的端带宽情况”，就是这个原因。
解决：如果带宽确实差，改用 DMHS 做源端到目的端的直连迁移。如果 DMHS 不支持源端类型，就在源端本地导成 txt 或 Excel，拷贝到达梦服务器，再用 dmfldr 快速装载。dmfldr 是命令行工具，不依赖网络传输，只读本地文件，速度很稳。
4.4 字符集不一致导致中文乱码
现象：迁移完成后，查询中文数据全是问号或乱码。
原因：达梦初始化时字符集编码和源端不一致。源端是 GBK，达梦建库时选了 UTF-8，或者反过来。
解决：这个坑没有后悔药，只能重建实例。所以在初始化之前，一定要用SELECT * FROM NLS_DATABASE_PARAMETERS查源端字符集，达梦这边建库时严格对齐。如果源端是 ZHS16GBK，达梦的 CHARSET 参数要选对应的 GBK 编码；源端是 AL32UTF8，达梦选 UTF-8。
4.5 把数据迁到了 SYSDBA 或 MAIN 表空间
现象：迁移时图省事，直接用 SYSDBA 用户和 MAIN 表空间，迁完发现应用连接报权限错误，或者后期备份恢复时无法按用户粒度操作。
原因：SYSDBA 是达梦的超级管理员，MAIN 是系统默认表空间，把业务数据放进去会导致权限边界模糊、空间管理混乱。
解决：迁移前就创建好独立的业务用户和表空间，DTS 里指定目标用户和目标表空间。如果已经迁错了，用ALTER TABLE ... MOVE TABLESPACE逐表搬移，但大表搬移很耗时，不如一开始就做对。
5. 迁移后的验证与一个压箱底的习惯
迁移完成不等于交付完成，PPT 里在迁移准备阶段就问了“迁移后是否需要测试”，这个问题的答案永远是“需要”。我一般会做三层验证：第一层是对象数量核对，源端有多少张表、多少个索引、多少个约束，达梦这边必须一一对应，差一个都要查清楚；第二层是数据量核对，每张表的行数用SELECT COUNT(*)对比，大表可以用采样比对；第三层是业务 SQL 验证，把应用里最核心的几条查询和写入语句在达梦上跑一遍，看执行计划和结果集是否一致。
-- 对象数量核对查询（达梦侧） SELECT OBJECT_TYPE, COUNT(*) FROM DBA_OBJECTS WHERE OWNER = 'APP_USER' GROUP BY OBJECT_TYPE; -- 数据量核对（逐表对比，可配合脚本批量执行） SELECT 'TABLE_NAME' AS TAB, COUNT(*) AS CNT FROM APP_USER.TABLE_NAME;这两段 SQL 看着简单，但批量跑起来能省掉大量人工核对时间。我一般会写个 Python 脚本，从源端和目的端分别拉取对象清单和行数，自动 diff 出差异项，然后只针对差异项排查。
最后说一个我压箱底的习惯：每次迁移前，我都会在本地备份至少两个版本的 DTS。PPT 里有一句话很实在——“有时候老的 DM7 的版本相对于最新版本的 dts 还稳定点”。新版本 DTS 可能修了一些 bug，但也可能引入新的兼容性问题，手头留个旧版本，遇到诡异报错时换一个版本跑，往往能绕过问题。这个习惯让我在好几次紧急迁移中省下了大量排查时间。从那以后我每次做异构迁移，都会先把驱动、DTS 版本、字符集这三样东西确认三遍，再开始动手。希望帮到你。
本文还有配套的精品资源，点击获取
