简介面向达梦数据库数据迁移场景的 PPT 课件适合 DBA、运维人员及信创项目中的数据迁移实施者参考。内容围绕数据迁移全流程展开先梳理迁移前调研、项目背景与风险评估等准备事项再分析源端类型、网络连通性、客户端环境、防火墙等硬性条件给出网络不通或存在带宽限制时的应急与工具选择策略正式迁移阶段则覆盖初始化参数、磁盘空间划分、表空间与用户权限设置并详解 DTS 迁移原理、JDBC 驱动匹配及表被迁移成视图等常见问题的处理思路。全包共 1 个文件为 PPTX 演示文稿大小 5.83MB内容按引言、迁移准备、正式迁移、总结四部分组织便于随讲随查。这份演示文稿已有 209 人浏览学习对正在准备或执行达梦数据库迁移工作的读者有直接参考价值。1. 达梦数据库的数据迁移先分清四种场景再动手一个生产系统要从 Oracle 或者 MySQL 迁到达梦或者从 DM7 升到 DM8最难的往往不是数据量大小而是方案选错。同样是“数据迁移”用图形工具迁移、命令行逻辑导入导出、物理备份还原、CDC 增量同步这四种方式的适用前提和踩坑点完全不一样。选错路径的直接后果就是表结构过去了数据乱码、模式对不上报错、自增列主键冲突甚至迁了一半发现没启用归档导致增量追不上。这篇按一线落地顺序讲清楚达梦数据库数据迁移的四种方式、各自必调参数和常见坑位适合正在做国产化替换、双库并行或者刚接触达梦的 DBA 和开发。2. 迁移前的“户口调查”版本、模式、字符集与驱动四条线2.1 先确认版本和模式迁移方案的第一道分岔动手迁移前第一件事不是找工具而是先搞清楚源库和目标库到底是谁。达梦数据库的版本差异很大DM7 生成的备份文件 DM8 不一定认DM8 不同小版本的逻辑导出文件也可能存在兼容限制。在 Linux 上装好达梦数据库后我一般直接用 disql 登录实例查版本# 进入达梦安装目录的 bin 目录 cd /home/dmdba/dmdbms/bin # 用 disql 登录用户名/密码主机:端口默认端口 5236 ./disql SYSDBA/SYSDBAlocalhost:5236登录后再执行下面的 SQL-- 查看数据库版本和实例信息 SELECT * FROM V$VERSION; SELECT * FROM V$INSTANCE; -- 查看数据库模式列表 SELECT DISTINCT OWNER FROM ALL_TABLES; SELECT NAME FROM SYS.SYSOBJECTS WHERE TYPE$SCH;这里有一个非常关键的口语化判断达梦里的“模式”类似于其他数据库里的 schema它是一个对象归属空间默认情况下用户登录名和模式名不一致时业务 SQL 不带模式前缀查表会直接报“表或视图不存在”也就是热词里常见的“达梦数据库 模式错误”。所以迁移之前必须确认目标库上是否存在同名模式没有就先建-- 创建模式建议与业务用户名保持一致 CREATE SCHEMA TEST AUTHORIZATION TEST;版本确认影响的是后续用 dexp/dimp 还是用备份还原。如果源和目标都是同为 DM8 小版本接近物理备份还原最快如果跨大版本老老实实走逻辑导出导入。这一步省下来的时间最后都会在排错时还回去。2.2 字符集与大小写敏感最容易埋雷的两个建库参数很多人在源库迁到一半才发现目标库字符集不对然后整批返工。达梦数据库有 LIB_CHAR 和 CASE_SENSITIVE 两个参数在不同资料里写法略有差异实际建库时关注的是字符集和大小写敏感规则。这两个参数在数据库创建后基本改不掉必须提前对齐。-- 查看大小写敏感和字符集相关参数 SELECT * FROM V$PARAMETER WHERE NAME IN (CASE_SENSITIVE, LEN_CHAR);CASE_SENSITIVE 为 Y 时表名和字段名不加双引号会被自动转为大写为 N 时不敏感。源库是 Oracle 时通常建议保持大小写敏感与 Oracle 一致。LEN_CHAR 决定 VARCHAR 的长度单位按字符还是按字节。这个参数直接决定了迁移时字段长度要不要换算比如 Oracle 的 VARCHAR2(20) 按字符存中文迁到 LEN_CHAR0 的达梦库时如果还建 VARCHAR2(20)实际能存的中文数量减半插入 20 个汉字就会报超长。所以正确的做法是在建库前就把字符集统一成 UTF-8、把 LEN_CHAR 设成按字符而不是迁完之后再补救。DTS 这类迁移工具能自动建表但它不会替你判断长度单位是否匹配。迁完后发现中文截断大多就是这个参数没对齐。2.3 驱动与客户端准备Navicat 和 JDBC 的最小前置连接达梦数据库不像 MySQL 那样装完客户端就能用驱动得单独准备。官方提供 JDBC 驱动和 DPI 驱动JDBC 驱动文件常见名是 DmJdbcDriver18.jar对应 JDK 版本不同还有 17、18 等变体DPI 驱动用于 C/C 接口。用 Navicat 连接达梦数据库时选择“达梦数据库”类型填主机名和端口端口默认 5236然后在连接属性里指定驱动文件路径。很多人卡在这一步是因为驱动文件选错版本DM8 连接串是jdbc:dm://localhost:5236Java 工程里引入驱动后连接串写法就是上面这个格式。Navicat 如果自己带驱动库也要确认版本和你要连接的实例大版本匹配驱动不一致时常见报错是“连接失败”或者“无效的连接字符串”这类问题几乎与迁移本身无关但会在迁移验证阶段反复干扰你。命令行工具也一样Linux 上装完达梦数据库后disql、dimp、dexp 都在安装目录的 bin 下建议把 bin 加进 PATHexport PATH/home/dmdba/dmdbms/bin:$PATH export DM_HOME/home/dmdba/dmdbms环境变量配好后后面所有迁移命令都能直接用不用每次写全路径。3. 逻辑迁移的三条主路DTS 工具、dexp/dimp、disql 脚本3.1 DTS 数据迁移工具图形化对接 Oracle/MySQL/PostgreSQL达梦自带的 DTS数据迁移工具是做异构迁移最常见的入口它一般随数据库安装包提供在安装目录的 tool 下启动Windows 上有图形界面Linux 上也有相应启动脚本。DTS 支持从 Oracle、MySQL、PostgreSQL、SQL Server 等来源迁移到达梦也能在达梦实例之间拷贝数据。第一次用时留意 DTS 的迁移流程先建源连接和目标连接然后选择要迁移的对象DTS 会自动完成数据类型映射、生成建表语句并导数据。它比手工写建表语句省掉大量重复工作尤其适合几十张表的批量迁移。用 DTS 时要控制几个参数参数推荐值说明提交批次500~2000 行批次太小导入慢太大会占用内存并可能导致回滚段膨胀迁移线程数2~4默认 1 太慢超过 8 容易把目标库 IO 打满出错策略先跳过并记录不要在第一次迁移就整体失败先拿到全量错误清单再针对性修索引/约束数据后建先导数据再建索引导入速度能快一个量级实际踩过的坑是DTS 报“源连接失败”很多时候不是网络不通而是源库的驱动没放对目录比如迁移 MySQL 时缺 mysql-connector-java.jar。先确认驱动再跑迁移不要在报错以后反复试连接。DTS 适合异构迁移也适合小数据量同构迁移。但如果表数量几百张、数据量几百 GB图形工具跑起来既慢又容易内存溢出这时候就要换命令行方式。3.2 dexp/dimp 逻辑导出导入同构库之间最小可复现命令同是达梦数据库之间的迁移我一般优先用 dexp 导出、dimp 导入。这两个命令分别对应 Oracle 的 exp/imp走逻辑备份跨大版本迁移基本靠它。最小可复现的导出命令是这样# 按模式导出输出 dmp 文件和日志 dexp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/test.dmp LOG/backup/test_exp.log SCHEMASTEST导入命令对应# 将导出文件导入目标库fromuser 对应源模式 touser 对应目标模式 dimp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/test.dmp LOG/backup/test_imp.log FROMUSERTEST TOUSERTEST参数解释FILE 是导入导出的文件路径SCHEMAS 按模式导出还可以用 TABLES 只导部分表FULLY 是全库导出FROMUSER/TOUSER 做模式映射源库模式名和目标库不一致时靠这两个参数转换。这里必须提醒一点dimp 导入时目标库里对应模式要先存在否则建表会进到 SYSDBA 模式下面业务一访问就报上面说的“模式错误”。所以导入前先执行建模式语句或者让 DBA 提前用CREATE SCHEMA建好。大批量导入时还要关注并行度和表存在动作的设值dimp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/test.dmp LOG/backup/test_imp.log \ FROMUSERTEST TOUSERTEST PARALLEL4 TABLE_EXISTS_ACTIONREPLACEPARALLEL 控制最大并行数不是越大越好我一般 4 到 8 够用TABLE_EXISTS_ACTION 可选 REPLACE、APPEND 等重跑导入时如果表已经存在REPLACE 会先删表再建APPEND 是追加数据。中断重跑场景用 APPEND 更安全至少不会因为删表失败卡住。3.3 disql 脚本迁移适合纯表结构和简单数据的场景第三种方式是纯 SQL 脚本迁移。它的适用面窄只适合表数量少、单表几千行、结构简单的场景或者只迁几个配置表。因为达梦支持标准 SQL把其他数据库导出的建表语句和 INSERT 语句稍作兼容性修改就能用 disql 直接执行。这也是“达梦数据库 sql语法”这个热词背后最常见的诉求来源。使用方法是把脚本文件放到目标机器上然后执行# 用 disql 跑脚本 ./disql SYSDBA/SYSDBAlocalhost:5236 /backup/test_schema.sql # 或重定向执行 ./disql SYSDBA/SYSDBAlocalhost:5236 /backup/test_schema.sql注意达梦的 disql 执行外部脚本用符号不能像 MySQL 那样用 source。脚本里如果包含 Oracle 特有的语法比如NUMBER(*,0)、SYSDATE、ROWNUM需要先做兼容性改写。脚本迁移最大的好处是可见可维护出问题可以直接看 SQL 行号最大的坏处是性能和事务控制弱几万条 INSERT 不要用手工脚本会慢到怀疑人生。实际工作中我通常把脚本迁移当成“兜底方案”DTS 和 dexp/dimp 都不可用或者只需要同步少量配置表时用它救急。4. 物理迁移与增量同步备份还原、文件拷贝和 CDC4.1 备份还原物理迁移最快的路但边界要清楚如果源库和目标库都是达梦且大版本一致物理备份还原是速度最快的迁移方式。它不逐行解析数据直接把数据文件备份集恢复到目标实例几十 GB 的库往往能在分钟级完成。达梦备份既可以用 SQL 命令也可以用 dmrman 工具。最常用的是 disql 里执行-- 全库备份备份集路径必须存在且有写权限 BACKUP DATABASE FULL BACKUPSET /backup/dm_full_20240601;完整还原稍微麻烦要保证目标库处于还原可接受的状态常见做法是用 dmrman 做脱机还原# 进入 dmrman 工具 ./dmrman # 在 dmrman 提示符下执行还原 RESTORE DATABASE /home/dmdba/dmdbms/data/DAMENG/dm.ini FROM BACKUPSET /backup/dm_full_20240601; # 还原完成后恢复 RECOVER DATABASE /home/dmdba/dmdbms/data/DAMENG/dm.ini;逻辑说明dmrman 里的路径是 dm.ini 的绝对路径不是简单接主机端口RESTORE 把备份集里的数据文件还原到目标库的路径RECOVER 把数据库回滚到一致状态。备份还原的边界有三个一是源和目标实例的页大小、字符集等建库参数必须一致否则还原直接失败二是不能跨大版本DM7 的全备份不能还到 DM8三是目标库原来的数据文件会被覆盖还原前做好目标库自己的备份。另外还有一个“野路子”是把整个数据目录打包拷走。这种方式适合同平台、同版本、停库状态下做复制生产环境不建议。它省了备份还原的时间但没有一致性检查拷的过程中如果有进程偷偷写文件那这个库大概率起不来。我一般只在测试环境用。4.2 异构迁移数据类型映射和字段规则的重新对位异构迁移主要指从 Oracle、MySQL、PostgreSQL 迁到达梦。这类迁移的重点不在工具而在数据类型和对象语义的映射。达梦兼容 Oracle 程度很高但也不是无痛平移MySQL 到达梦的差异更大。常见的映射关系如下源类型达梦类型注意点Oracle NUMBERDECIMAL / NUMERIC无精度时按 NUMBER(38) 处理注意源库实际数据小数位Oracle VARCHAR2(n)VARCHAR(n)n 是字符还是字节取决于目标库 LEN_CHARMySQL INT / BIGINTINT / BIGINT注意无符号整型要映射到更大范围MySQL VARCHAR(n)VARCHAR(n)MySQL 的 n 默认是字符对齐 LEN_CHAR 即可MySQL DATETIMETIMESTAMP时区不参与存储保证两边时区一致BLOB / LONGBLOBBLOB / IMAGE大字段迁移建议单独验证避免 DTS 内存溢出除了类型映射还要处理默认值、自增列、注释、索引名长度。达梦的标识符长度上限比 Oracle 小Oracle 里 30 字符以上的字段名在达梦里可能超限DTS 自动迁移时会截断或报错。我的做法是先让 DTS 自动生成一份建表脚本然后在测试库上执行一遍把报错逐条改完再正式执行。不要相信自动映射能 100% 正确。每次异构迁移我都要抽查三样东西字段精度、字符集转换、约束名称。这三样出错数据可能看起来一样但应用一跑就炸。4.3 增量迁移与 CDC不停业务时怎么追平数据全量迁移完成后如果业务不能长时间停就要考虑增量同步。“达梦数据库获取读取到的cdc”这个热词背后就是有人在找达梦的日志增量读取方案。达梦有 CDC 能力核心原理是读取归档日志或在线日志把数据变更解析出来再投递到目标端。启用 CDC 的前提是数据库要开启归档模式-- 查看是否开启归档 SELECT ARCH_MODE FROM V$DATABASE; -- 设置归档参数需要按实际路径创建目录 ALTER SYSTEM SET ARCH_INI 1;归档开启后重启实例才完全生效。之后达梦会定期写归档日志CDC 客户端才能从中解析变更。配置完成后应用侧通过达梦提供的 CDC SDK 或接口订阅变更再把变更写入目标库或消息中间件。实操上的关键点CDC 虽然强大但它不是拿来“一次性迁移”的而是用于双库同步、持续容灾或割接窗口内的增量追赶。如果你只是割接一次更实用的方式是停业务-全量迁移-记录 binlog/日志位点-增量回放而不是在迁移早期就引入 CDC。CDC 的运维成本高归档日志空间、解析进度、断点续传都得监控测试环境没充分验证前不要直接上生产。5. 达梦数据迁移的避坑清单模式、字符集、自增列与大表中断5.1 现象应用报“模式错误”或“表或视图不存在”迁移完成后应用连上新库跑一条最简单的SELECT * FROM user_info就报“表或视图不存在”或者 DBA 操作时报“模式错误”。原因数据表确实导进了目标库但建到了 SYSDBA 模式下面而应用连接用户的默认模式是自己的用户名。达梦对模式归属很敏感业务 SQL 没有加模式前缀时它只在当前用户同名模式里找对象。解决迁移前先建好业务模式和用户并保持用户名与模式名一致。如果数据已经导错位置可以批量调整属主。常见做法是如果表不多直接ALTER TABLE 模式名.表名 OWNER TO 新模式名表多了就用 dexp 重新按 SCHEMAS 导出再 dimp 到正确的 TOUSER。5.2 现象中文乱码、插入中文报字符串截断迁移后查询表中文显示成问号或者插入一段中文时提示字符串超出长度。原因两层。一是源库和目标库字符集不一致比如源库是 GBK目标库是 UTF-8DTS 连接串没指定正确的字符集导致转码错乱二是 VARCHAR 长度单位不一致源库按字符定义目标库 LEN_CHAR0 按字节定义VARCHAR(20) 只能存 10 个汉字。解决先统一字符集建议目标库建库时直接用 UTF-8。乱码数据不能靠事后替换修复必须重新按正确的转码方式导一遍。长度截断问题在迁移前检查目标库 LEN_CHAR 参数如果已经建错只能重建数据库或者在 DTS 里对字符串字段长度做倍增映射。5.3 现象自增列导入后主键冲突或 ID 重新从 1 开始从 MySQL 或 Oracle 迁移自增表到达梦DTS 会把数据导进来但达梦的自增列IDENTITY当前值可能没有跟着数据的最大值走。业务插入一条主键马上冲突或者新 ID 从 1 开始覆盖已有数据。原因达梦的 IDENTITY 列和序列是独立维护的数据迁移不会自动重置序列的当前值。Oracle 的 SEQUENCE 即使迁移了对象定义也是独立于表数据。解决迁移完成后把序列或自增列的种子值重置到当前表数据的最大值。达梦版本不同支持的语法有差异我习惯的做法是先查最大值然后重建序列-- 查看自增列最大值 SELECT MAX(ID) FROM TEST.USER_INFO; -- 重建序列到最大值100 的起点具体语法视版本支持程度调整 DROP SEQUENCE TEST.SEQ_USER_ID; CREATE SEQUENCE TEST.SEQ_USER_ID START WITH 1001 MAXVALUE 999999999;如果你用的是旧版达梦不支持直接改序列起始值那就按上面方式重建。关键是别在迁移前建好依赖自增列的业务数据否则回填很痛苦。5.4 现象几百 GB 大表 DTS 迁移到一半失败只能从头跑用 DTS 或 dexp 导大表跑了两小时快结束了网络闪断或者目标库空间不够导致失败一重跑又是两小时。原因DTS 图形工具没有完整的断点续传能力dexp 导出也是如此。导大表失败后从头再来完全浪费前面时间。解决大表别整张导按条件分片。比如按主键或时间字段分成多个区间# 按分区条件分别导出然后分别导入 dexp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/user_1.dmp SCHEMASTEST TABLESUSER_INFO \ QUERYWHERE ID BETWEEN 1 AND 1000000 dexp SYSDBA/SYSDBAlocalhost:5236 FILE/backup/user_2.dmp SCHEMASTEST TABLESUSER_INFO \ QUERYWHERE ID BETWEEN 1000001 AND 2000000QUERY 参数在 dexp 里被双引号和单引号反复包裹不同 shell 转义规则不一样先在测试库上跑通一个小分片再看日志。导入端也可以分批用 dimp 的 FILE 指定不同文件连续导完。这样即使某一批失败只需要重导该批不用全量重来。同时导入前确认目标表空间剩余空间预判大对象占用别让空间不足成为失败主因。6. 迁移后的验证与回退做一次像样的数据对账6.1 用三组 SQL 完成行级与内容级对账迁移完成不等于迁移成功。我最先做的是“三表对账”源库和目标库对比对象数量、行数、关键列求和。这些查询在两边执行后放到一起对比-- 对象数量对账主要查表和视图 SELECT COUNT(*) FROM ALL_TABLES WHERE OWNERTEST; SELECT COUNT(*) FROM ALL_VIEWS WHERE OWNERTEST; -- 行数对账关键业务表逐张检查 SELECT COUNT(*), SUM(AMOUNT) FROM TEST.ORDER_INFO; -- 抽样内容对账挑几条创建时间和状态字段比较 SELECT ORDER_ID, ORDER_STATUS, CREATE_TIME FROM TEST.ORDER_INFO ORDER BY ORDER_ID DESC LIMIT 10;行数一致不代表数据一致SUM 能校验数值字段的平移是否完整。字符字段建议抽查几条中文数据重点看乱码和截断。如果金额、日期这类字段也在对账清单里SUM 和 MAX/MIN 对比基本能发现大部分问题。6.2 业务验证与回退决策数据对账通过后还要做应用层验证。常见做法是把新库作为只读库挂给测试环境让开发团队用典型业务流程跑一遍涉及接口对接的中间件比如 nacos 注册中心的配置、dify 连接数据源这类集成场景本质上验证的还是 JDBC 驱动版本和连接串是否匹配提前用 Navicat 或 JDBC 探活能省很多排错时间。回退策略在迁移前就要定好。我的习惯是旧库不马上销毁保留一组完整备份并且新库同步运行观察至少一个业务周期。如果切换后发现问题需要回退把旧库恢复成迁移前状态业务入口切回旧地址比在新库上修补快得多。回退演练必须做一次不然真正出问题时会发现自己连旧库从哪台机器拉起来都不清楚。做过的项目里最能提升迁移成功率的其实不是某个高级工具而是先写一张“迁移前检查表”版本、字符集、大小写敏感、模式、序列、空间、驱动每一项打勾之后才允许执行迁移。这条检查表救过我很多次希望帮到你。本文还有配套的精品资源点击获取