尧图网站建设 
简介达梦数据库数据迁移方式以PPT课件形式提供聚焦达梦数据库与其他数据库、文本数据间的迁移场景面向数据库运维、实施工程师以及信创项目相关技术人员帮助读者在有限工期内规范完成迁移准备与正式迁移。内容按引言、迁移准备、正式迁移、总结四个模块展开迁移准备部分涵盖项目背景、移植范围、时间与性能目标、风险评估等调研项以及源端数据库类型、网络连通性、客户端和图形化桌面等环境核查要点正式迁移部分说明DTS迁移原理与参数配置、JDBC驱动版本对应关系、DMHS工具使用条件并针对系统错误、分析失败、表迁移成视图等常见问题整理了排查思路。资源为单个pptx文件大小5.83MB结构紧凑可直接用于项目培训或迁移方案交流。已有209人学习适合正在规划数据库迁移或希望系统梳理达梦迁移流程的读者学习参考。1. 达梦数据库的数据迁移比你想的更依赖工具链做过几轮达梦数据库数据迁移我最深的印象是真正让团队熬夜的往往不是达梦本身而是把数据迁移方式选错了。有人拿着建表脚本直接跑跑到一半报“模式错误”整批回滚有人写程序从源库一条条查、再往目标库插几千万行的流水表跑了三天还没跑完也有人想照搬 Oracle 那套备份思路结果字符集、自增列、大字段轮流出问题。我常用到的达梦数据库数据迁移方式可以分成四类图形化工具 DTS、命令行工具 dexp/dimp、外部表导入以及临时取数用的 disql 脚本。选择的标准很简单先看数据是跨库还是跨文件、再看要一次性搬完还是要持续同步。这个选择做完迁移工作就完成了一半。这篇笔记适合正在把 Oracle/MySQL 上的数据迁到达梦、或者在两套达梦库之间做数据汇聚的从业者。后面每一章都会落到具体参数和操作命令能直接在自己的环境里照着跑。2. 迁移方案选型先回答三个问题再碰工具2.1 先给结论场景决定工具不要一上来就开 DTS很多人拿到达梦数据库之后第一反应就是打开自带的图形化数据迁移工具 DTS。我理解这种习惯图形界面确实省心但它不是所有场景的最优解。我一般先问自己三个问题数据源是数据库还是文件数据量是几十万行还是几千万行这次迁移是要一次性搬完还是以后每个月都要搬这三个问题问完工具基本就定下来了。如果源和目标都是达梦且要做整库搬迁我会优先考虑 dexp/dimp 或备份恢复而不是 DTS。原因是同构库之间走逻辑导出导入对象依赖、索引、约束都能原样带过去整体速度也比跨库读写好几个量级。如果源是 Oracle、MySQL、SQL Server 这类异构库DTS 反而是最稳的默认选项因为它在内部把源库类型映射到达梦类型的工作做了省掉大量手工建表和改类型的成本。如果数据以 CSV、TXT 文件形式存在那根本不需要连数据库迁移外部表映射一下用 SQL 就能把文件读进来。迁移场景推荐方式理由异构库(Oracle/MySQL/SQL Server)迁到达梦DTS图形工具自带JDBC/ODBC适配和类型映射自动建表两套达梦库之间整库迁移dexp/dimp 或备份恢复同构通道对象和依赖保留完整速度快文本文件(CSV/TXT)入库外部表 INSERT SELECT不需要源库连接文件直接映射成临时表少量临时取数disql 执行SQL一条命令连库跑完不建工程不落文件需要在不停机场景持续同步达梦CDC/数据同步方案解析库日志追增量全量迁移后追平窗口这五个方向是我这几年用得最多的组合后面第3、4、5章都会按这张表展开。选中工具之后还会遇到一个容易忽略的决策点这次迁移是一次性的还是要做成经常性任务。一次性任务条件反射是“怎么省事怎么来”打开 DTS 建个任务拖一拖执行完就算完。经常性任务就不能这样图形界面点来点去没法交给调度系统日志、告警、重试都不好处理我会把这类长期任务写成 dexp/dimp 脚本进 crontab 或调度平台这样哪天失败了能看日志定位重跑也只是一条命令的事。所以不要一上来就点 DTS。先判断数据形态再判断迁移频率最后再选工具。顺序反了后面往往要返工。2.2 DTS 图形化工具的内部逻辑为什么它是默认选项DTS安装目录里的名字一般是“数据迁移工具”是达梦数据库自带的图形化迁移工具。它的工作流程可以概括为四步连接源库读取元数据把源表结构翻译成达梦的建表语句按目标库语法生成对象再分批读取源表数据写入目标表。整个过程里最值钱的部分是类型映射规则这也是推荐用它处理异构迁移的核心原因。举个例子Oracle 里的 NUMBER(38,0) 既可能是整数也可能是金额MySQL 里的 datetime(6) 带微秒精确到小数秒SQL Server 里的 nvarchar(4000) 在 UTF-8 下字符长度和字节长度还不一致。如果自己写迁移程序每种数据库都要重新写一遍映射逻辑还要逐字段核对精度工作量极大。DTS 把这张映射表内置了界面上一勾目标建表语句就自动生成省掉的这部分劳动量往往就是项目按期交付的关键。但这不意味着 DTS 是黑匣子你只管点下一步就行。实际使用中有一半的问题出在连接阶段DTS 连接源库一般通过 JDBC 或 ODBC 驱动驱动文件需要提前放到指定目录不同数据库的驱动版本差异也会导致连接失败连接串里的 schema 和字符集参数很多人在这一步漏掉导致后面目标表上出现一堆怪异的类型和乱码。我的建议是每次建任务前先把源端元数据用查询语句拉一遍确认表清单、列名、字符集三项信息再开始配置迁移任务。DTS 另一个容易被低估的能力是任务配置可复用。建好的任务可以保存成一个工程文件下次迁移同结构的库时改一下连接信息就能再用。我在项目里会把 DTS 工程文件一并交给运维作为后续其他库迁移的模板。这样做的好处是团队里任何一个人拿到工程文件都能复现迁移过程不需要依赖当初建任务的那个人的记忆。后面第3章会具体讲任务里哪些参数值得调。这里先记住一个结论DTS 适合做异构库的一次性、可交互的迁移任务它是默认选项但不是所有场景的唯一选项。2.3 命令行兜底dexp/dimp 和 disql 各自的适用边界DTS 负责交互式迁移但交付项目里我更信任命令行。达梦自带的 dexp 和 dimp 是逻辑导出/导入工具dexp 从库里抽取对象和数据生成 dmp 文件dimp 再把 dmp 文件导回目标库。它的适用边界非常清晰两边都必须是达梦数据库版本尽量接近数据量在几十 GB 内时效率很高。如果源库不是达梦dexp 连不上去还是得回到 DTS 或外部表方案。# 逻辑导出把 DMUSER 这个模式下的对象和数据导出为 dmp 文件 dexp USERIDSYSDBA/你的密码127.0.0.1:5236 \ FILE/backup/dmuser.dmp \ LOG/backup/dmuser_exp.log \ SCHEMASDMUSER \ ROWSY \ INDEXESY这里每个参数都是日常必用项。USERID是连接信息格式固定为“用户名/密码IP:端口”示例密码要替换成安装达梦时设置的管理员密码FILE指定导出文件路径注意目录要先建好并且有写权限否则导出会在最后一步才报错浪费大量时间SCHEMAS指定要导出的模式名不是用户名。虽然达梦中用户和模式同名但概念上要区分开ROWSY控制是否导出数据只要结构就改成NINDEXESY把索引定义一并导出目标库导入后不用重建索引。# 逻辑导入把 dmp 文件导入目标库对应模式 dimp USERIDSYSDBA/你的密码127.0.0.1:5236 \ FILE/backup/dmuser.dmp \ LOG/backup/dmuser_imp.log \ SCHEMASDMUSER \ IGNOREYdimp 的IGNOREY是我每次必开的参数。它的含义是目标库中如果已经存在同名对象跳过创建步骤继续导入数据和后续对象。很多新手第一次导入看到“对象已存在”的报错就停了其实加上这个参数让导入流程继续往下跑往往就是正确结果。还有一个容易忽略的点如果源表带有触发器dimp 导入数据时触发器会被真实触发大表导入可能会因此变得极慢。迁移前最好先确认目标表的触发器状态或者先禁用触发器再导入。disql 是达梦的命令行 SQL 客户端对应 Oracle 的 sqlplus。它既支持交互式操作也支持从文件执行 SQL。临时取数、巡检、校验行数这类轻量操作我都是直接用 disql因为不需要打开任何图形工具一条命令就能拿到结果。# 用 disql 执行一条查询并退出 disql SYSDBA/你的密码127.0.0.1:5236 \ -e SELECT COUNT(*) FROM DMUSER.ORD WHERE ORDER_DATE 2025-01-01;-e参数让 disql 执行完 SQL 后直接退出不进入交互式提示符这个特性在 Shell 脚本里非常关键。第5章的定时增量同步脚本就是围绕 dexp、dimp 和 disql 三条命令拼出来的。三者的分工可以归纳成一句话DTS 管复杂异构迁移dexp/dimp 管同构库间的结构化搬运disql 管日常查询和脚本化执行。3. 用 DTS 把数据搬过去建任务、调参数、跑批3.1 建第一个迁移任务连接源端和目标端时别忽略的两个字段DTS 的界面结构在不同版本上略有差异但核心流程是稳定的。打开工具后先新建工程然后在工程里新建迁移任务选择源库类型Oracle、MySQL、SQL Server 等都列在这里填入源库的 IP、端口、服务名或数据库名再选择 JDBC/ODBC 驱动类型接着填目标达梦库的连接串勾选要迁移的表或整个模式最后执行任务。大部分表直接采用默认映射就能迁成功决定成败的其实是连接阶段的两个字段。第一个是驱动类型。同样是连 MySQLODBC 和 JDBC 进入 DTS 后的表现不一样尤其在中文数据的处理上选错驱动可能出现字符串被截断、乱码一类的问题。我一般在 Windows 上优先用 JDBC在 Linux 服务器上按数据库官方推荐的 JDBC 驱动来处理如果源库没有现成驱动需要先去数据库厂商页面下载对应驱动包放到 DTS 能读到的目录再重启工具才能看到。驱动版本也不建议随便换DTS 官方适配过的版本往往比最新版更稳这一点在生产环境里比想象中重要。第二个是目标端 schema。达梦里建一个用户会自动生成同名模式DTS 默认会把源表创建到目标连接用户同名模式下面。比如你用 SYSDBA 连接目标库去跑迁移表会建在 SYSDBA 的模式下但业务程序可能期望表在 APPUSER 名下。这个问题在异构迁移里非常常见业务连上新库后报“表或视图不存在”实际上表存在只是模式不对。解决方式是在 DTS 目标端的模式设置里显式指定或者提前建好目标用户并把默认模式切过去再开始跑迁移任务。3.2 五个必调参数批大小、事务提交频率、并发连接数、字符集、LOB 阈值DTS 界面上的参数名在不同版本里叫法不完全一样但下面这五个参数我每次都会看它们直接影响迁移速度和能否跑完。参数建议值说明每次读取行数(批大小)1000~2000太小网络往返多太大内存占用高事务提交频率每 1 万行提交提交太少导致回滚段暴涨太多则性能下降并发连接数2~4最多 8大表可提升但目标端压力随之上升字符集转换按源端实际字符集配置避免中文乱码和长度超限LOB 字段读取阈值64KB~256KB超过阈值改用文件流写入防内存飙升批大小决定一次从源库读多少行批量写到目标库。值太小时每批的网络往返和 SQL 拼接开销占比高几千万行的表会明显变慢值太大时DTS 进程占用的内存会随批大小线性增长低配服务器上跑 OOM 的多数情况就是这里设太大。我在生产上一般设 1000字段多的大宽表降到 500简单表可以提到 2000。事务提交频率是最容易忽略的一项。迁移任务默认可能是每批提交源端一个事务里如果有几十万行目标端就要攒几十万行的重做回滚段压力会很大。把提交频率调成每 1 万行一次目标端就能及时释放锁和日志空间整体反而更快。注意这个参数要和批大小配合看批大小 1000、每 10 批提交一次是一个相对稳定的组合。并发连接数指的是 DTS 同时开启几个连接来读源库和写目标库。并发不是越高越好目标库的 redo、undo 和磁盘 IO 就那么宽连接数设到 10 以上往往数据库自己先成为瓶颈。我的经验是默认 2 个连接起步跑一遍看目标库等待事件明显等待再往上加一般到 4 个已经很快。字符集转换这个参数很多任务因为没开它而翻车。源库是 UTF-8目标达梦默认字符集可能是 GB18030数据里含有生僻人名、emoji 或不常见符号时迁移过程可能直接报“字符集不兼容”或“无效字符”。处理方式是在 DTS 字符集选项里选择源端实际字符集让工具在写入前做转码。此外目标库本身也能改字符集但建库之后再改代价很大迁移前先确认目标库字符集比迁移后统一改数据明智得多。LOB 字段读取阈值主要影响带 BLOB/CLOB 的表。默认情况下 DTS 把大字段读进内存再写入阈值太高时一张带几百 MB 附件表的迁移会持续吃内存甚至一直卡在某个大字段上。把阈值调到 64KB 或 256KB超过这个大小的大字段改成文件流方式落地内存占用会稳定很多。第4章里我会专门讲一次因为 LOB 参数没调导致的迁移卡死排查。3.3 跑批之后快速核对用 disql 脚本验证表级数据差异DTS 任务执行完并不代表迁移结束我习惯立刻用命令行脚本对每个大表做行数和最大主键比对。这个动作能提前发现绝大多数“任务显示成功但目标缺数”的问题比如源表在迁移期间又有新写入、某些约束导致部分行被忽略、以及中断重跑时的重复数据。#!/bin/bash # 源库和目标库连接串按实际情况替换 SRCSRC_SYS/你的密码127.0.0.1:5236 DSTSYSDBA/你的密码127.0.0.1:5236 TABLESORD CUST ACCT for t in ${TABLES}; do echo 表 ${t} # 源库行数和最大主键 disql ${SRC} -e SELECT COUNT(*) FROM SRC_SYS.${t}; | grep -E ^[0-9]$ disql ${SRC} -e SELECT MAX(ID) FROM SRC_SYS.${t}; | grep -E ^[0-9]$ # 目标库行数和最大主键 disql ${DST} -e SELECT COUNT(*) FROM DMUSER.${t}; | grep -E ^[0-9]$ disql ${DST} -e SELECT MAX(ID) FROM DMUSER.${t}; | grep -E ^[0-9]$ done这里用grep -E ^[0-9]$是为了把 disql 输出里的表头、分隔线全过滤掉只取纯数字的结果行。脚本输出的四个数字依次是源库行数、源库最大主键、目标库行数、目标库最大主键四列对比下来哪张表缺数一目了然。如果两边最大主键一致但行数不一致说明中间有删除或重复数据需要进一步排查约束。补数建议用 dexp 按主键范围抽取后再 dimp 导入不要去手工拼接 SQL 逐行插入。比如发现目标库 ORD 表最大主键比源库小就可以把源库大于目标最大主键的记录导出成一个 dmp再导入目标库。这比写 INSERT 语句安全也不会触发额外的应用层逻辑。4. 达梦数据库迁移避坑5 个高频问题与现场处理4.1 连接后报“模式错误”达梦的用户和模式是一一对应的现象连接配置都正确但迁移工具或应用访问目标表时报“模式错误”“schema 不存在”或“无效的模式名”。原因达梦中每个用户默认对应一个同名模式迁移前没有在目标库创建对应的用户/模式或者连接用户与表所在的模式不一致。比如源表建在 A 用户下你却在 B 用户下查找这张表达梦不会自动跨模式解析对象名。解决先建用户再迁移或者连接到目标库后切换当前模式。下面这段 SQL 在目标库执行一遍建好模式再重新跑任务。-- 在目标库执行为迁移单独建一个用户同名模式会随用户创建 CREATE USER DMUSER IDENTIFIED BY 你的密码; GRANT DBA TO DMUSER; -- 连接后把当前会话切到目标模式 SET SCHEMA DMUSER;在 disql 里执行SET SCHEMA之后当前连接对不带模式前缀的表名都按 DMUSER 解析这样逐条核对数据时不容易写错。另外一个习惯是DTS 建任务时就在目标端设置里把默认模式指定好不要让工具帮你猜。迁移任务结束后再用 4.1 的第一条命令把所有相关表重新确认一遍所属模式能避免后续应用连库时报一模一样的问题。4.2 字符集不一致乱码、长度报错、索引超长现象目标库查出来的中文是乱码迁移过程中报“数据超长”或被截断VARCHAR 列建立索引时报索引长度超限。原因源库和目标库的字符集不一致。GB18030 下一个汉字占 2 字节UTF-8 下占 3 字节同一列定义长度在两种字符集下可容纳的汉字数量不同。源表 VARCHAR(50) 里存了 50 个汉字如果目标列按 GB18030 计算长度时定义成了 VARCHAR(80)迁移时直接超限。解决迁移前先确认目标达梦库的字符集再选择是否在 DTS 里开启字符集转换。-- 在目标达梦库查看字符集相关参数 SELECT * FROM V$DM_INI WHERE PARA_NAME LIKE %CHAR%;这条 SQL 会把和字符集相关的参数列出来常见版本里能看到 CHARSET 或 UNICODE_FLAG 之类的项具体值对照当前版本的手册确认。如果已经迁完成出现乱码优先判断是历史脏数据还是迁移时转码导致后者可以重跑任务并在 DTS 中打开转码。如果只是列宽不够用ALTER TABLE ... MODIFY 列名 VARCHAR(更大的长度);调整别在应用层做二次截断。4.3 大字段表迁移卡死LOB 读取阈值没调现象DTS 跑到某张带 BLOB/CLOB 的表时进度条长时间不动几十分钟都没有新日志DTS 进程的内存占用却一路走高。原因默认把大字段整体读入内存再写入一张含几百 MB 附件记录的表会把批处理缓冲区直接占满批大小再大一些一次要同时组装多个大字段内存和磁盘 IO 双双打满任务就像卡死了一样。解决先把任务停掉把 LOB 读取阈值调低到 64KB超过阈值的大字段改用文件缓存方式写入同时把批大小降到 500降低单批内存峰值。环境不允许停任务时可以把这张表拆成多个子任务按主键范围分段迁移每个分段的数量控制在几百条以内。还有一种更实用的兜底方案迁移主表时先把大字段排除或者把大字段临时置空等全部普通字段迁完了再单独开一个小任务只迁 BLOB/CLOB 列。这样做的好处是业务最关心的核心字段能先上线大字段后补齐不会因为单张大表拖住整个迁移窗口。4.4 自增列和序列没迁过去插入数据报主键冲突现象数据行数完全一致但业务系统往新库插入时立刻报主键冲突或者新插入数据的主键和已有数据的主键重叠导致后续主键增长错乱。原因DTS 把数据搬过去了但表上的自增列属性或配套的序列并没有跟着数据重建。应用插入时从序列拿到的下一个值是 1而表里已经有主键到 100000两条新数据直接就撞上了。解决迁移后手动重建序列并让序列的起始值大于源表当前最大主键。-- 先确认目标表当前最大主键 SELECT MAX(ORDER_ID) FROM DMUSER.ORD; -- 重建序列START WITH 必须大于当前最大主键 CREATE SEQUENCE SEQ_ORD START WITH 1000000; -- 应用如果使用序列把序列赋权给业务用户 GRANT USAGE ON SEQ_ORD TO DMUSER;序列名称尽量和源库保持一致否则应用里拼的 SQL 可能找不到序列。如果建表时用的是 identity 自增属性还需要检查 DTS 是否勾选了“迁移自增属性”没勾就在目标表上补列属性。我的习惯是迁移计划里专门加一步“序列与自增列对齐”和 3.3 的核对脚本一起执行。4.5 校验只看行数为什么迁移后业务还是对不上现象两边 COUNT(*) 完全一致但业务报表跑出来数据偏差金额总和不对或者某些明细查不到。原因只比了行数。类型映射时精度丢失、DECIMAL 被截断成整数、字符被截断、唯一约束没建导致重复数据混入这些都不会影响行数却会直接影响业务结果。解决做三层校验。第一层比行数和最大主键第二层比关键数值列的合计、最大、最小专门发现精度问题第三层抽样几条明细记录逐字段比对。-- 对比两库订单金额合计用 TO_CHAR 保留原始精度 SELECT TO_CHAR(SUM(AMOUNT)) FROM SRC_SCHEMA.ORD; SELECT TO_CHAR(SUM(AMOUNT)) FROM DMUSER.ORD; -- 对比唯一约束和索引数量 SELECT COUNT(*) FROM USER_INDEXES WHERE TABLE_NAMEORD; SELECT COUNT(*) FROM USER_CONSTRAINTS WHERE TABLE_NAMEORD;TO_CHAR是为了避免客户端可视化格式化掩盖精度差异。索引和约束的对比同样重要DTS 建表时如果没有把唯一索引迁过去目标表可以写入重复数据行数可能对得上业务逻辑却已经错了。这一层校验做完才敢说迁移结果可用。5. 用外部表与 dexp/dimp 做不依赖图形界面的快迁5.1 外部表把文本文件映射成可查询的表客户只给了一个 CSV 导出文件、没有源库连接权限这是迁移项目里经常遇到的情况。此时不需要申请数据库权限也不需要装驱动直接建一个外部表把文件映射成表然后用 SQL 把数据搬进正式表就行。外部表本身不占用数据库存储空间它只是把文件当作只读表来看待。-- 建外部文件目录并授给目标用户读写权限需要DBA权限 CREATE DIRECTORY EXT_DIR AS /data/load; GRANT READ, WRITE ON DIRECTORY EXT_DIR TO DMUSER; -- 把 CSV 映射成外部表字段顺序与文件列一致 CREATE EXTERNAL TABLE DMUSER.EMP_EXT ( EMPNO INT, ENAME VARCHAR(50), SAL DECIMAL(10,2) ) FROM /data/load/emp.csv FIELDS TERMINATED BY , RECORDS DELIMITED BY \r\n ERRORS 1000; -- 先确认外部表能正常读取再写入正式表 INSERT INTO DMUSER.EMP (EMPNO, ENAME, SAL) SELECT EMPNO, ENAME, SAL FROM DMUSER.EMP_EXT;FIELDS TERMINATED BY ,定义了列分隔符RECORDS DELIMITED BY \r\n定义了每条记录的分隔方式Windows 下导出的文件通常是\r\nLinux 下往往是\n这里写错会导致所有记录被当成一行ERRORS 1000表示解析过程中允许跳过最多 1000 条坏行防止一行脏数据中断整个导入。如果 CSV 第一行是表头先确认外部表是否支持 skip 参数不同版本支持情况不一样我一般直接用sed -i 1d把表头那行摘掉再做映射。外部表最适合的形态是一次性历史数据入库文件数量不多、单文件大小可控、字段类型简单。把文件映射成外部表之后可以直接 join 正式表做增量对比也可以加 WHERE 条件只导入需要的分区数据这比写 Python 逐行读文件快得多。5.2 用 dexp/dimp 做定时增量不依赖图形界面的同步分析库每天要同步生产库的新增订单这个场景适合用 dexp/dimp 做定时增量不需要每次人工打开 DTS 点任务。我的做法是crontab 里挂一个 Shell 脚本凌晨从生产库按主键或时间条件抽取增量数据生成 dmp 文件再导入分析库。#!/bin/bash # 每夜从生产库抽取当天新增订单导入分析库 PRODPROD_SYS/你的密码生产库IP:5236 DWSYSDBA/你的密码分析库IP:5236 DMP_FILE/backup/inc_ord_$(date %F).dmp # 按主键或时间字段抽取增量数据 dexp USERID${PROD} \ FILE${DMP_FILE} \ TABLESPROD_SYS.ORD \ QUERYWHERE ORDER_DATE TO_DATE(2025-01-01, YYYY-MM-DD) \ ROWSY # 导入目标库已有对象跳过 dimp USERID${DW} \ FILE${DMP_FILE} \ SCHEMASPROD_SYS \ IGNOREYQUERY参数里的引号嵌套是很多人卡住的地方SQL 条件本身需要单引号但又不能和外层参数引号冲突所以脚本里用双引号包住整个 WHERE 子句内部时间字符串再写成两个连续单引号。实际写脚本时建议先echo打印一遍最终的 dexp 命令确认引号转义正确再执行。增量条件优先用主键或时间戳字段具体用哪个取决于源表有没有合适的创建时间列。如果目标分析库不想用 PROD_SYS 这个模式名我会在导完后用视图或CREATE TABLE AS SELECT做一次模型层的转换而不是强行要求命令行工具支持模式重映射。增量同步脚本跑一段时间后注意观察 dmp 文件大小如果每天都接近全量说明源表的数据分布和条件选择出了问题需要重新考虑用 CDC 方案。5.3 三种轻量路径的边界什么时候不该用外部表方式适用场景不适用场景外部表CSV/TXT 一次性入库、无源库连接数据量大到上亿、需要频繁增量、字段含复杂 LOBdexp/dimp达梦到达梦、整表/条件导出导入异构源库(Oracle/MySQL)、需要实时同步disql 脚本小表查询、临时取数、快速校验大表逐行处理、跨库数据搬运判断标准我是这样掌握的单表超过几千万行或者字段里有大规模大对象就老老实实走 DTS 或 CDC数据文件超过几个 GB 且要长期反复入库优先考虑先落成数据库表再迁移而不是每次都让外部表扫一遍大文件增量同步一旦出现“每天补数超过表总量 20%”的情况说明业务对时效的要求已经不适合离线批处理该上 CDC 实时追平了。轻量路径的定位是“快速、可靠、不惹麻烦”一旦这三个词满足不了就升级方案。6. 迁移后的校验与增量追平CDC6.1 迁移结果三件套行数、金额、约束我用惯的客户端连上达梦数据库跑三层校验。第一层是行数和最大主键第二层是数值列 SUM/MAX/MIN 对比第三层是把两边索引和约束数量拉平对比。三层都通过之后再开始内部业务口径的验证比如抽几条订单明细逐字段核对。6.2 用 CDC 追平全量迁移窗口期全量迁移往往要跑几个小时这个过程里源库还在持续写入。如果业务要求系统切换时数据基本对齐就要在迁移开始时记录一个时间点迁移完成后把该时间点之后的增量变更追平。达梦库具备 CDC 能力通过解析数据库日志拿到增删改事件再按主键应用到目标库具体开启步骤和消费接口以对应版本的《数据同步/CDC 使用说明》为准。启用前确认归档空间充足因为开启后日志量会有明显上涨。全量迁移不要和 CDC 并行跑通常是先全量、再增量追平、最后短暂停写切换。6.3 我习惯在开跑前做的三件事第一件备份目标库。达梦的备份可以用备份恢复工具做也可以在 disql 里执行备份命令迁移前留一个干净的还原点出了问题能迅速回到原位。第二件打印一张表映射清单写清源表名、目标模式、预计行数、预计耗时迁移完对着清单逐项打勾避免漏表。第三件先抽一张结构最复杂的单表在测试环境把全链路跑通确认类型映射、字符集、序列三个重点没有异常再正式开跑生产迁移。这三件事看起来笨却帮我躲过好几次灾难。尤其是那张表映射清单项目参与人越多越能体现出价值所有人对着同一张表沟通比群里翻聊天记录高效太多。希望这些实践对你下一次遇到达梦数据迁移能有点帮助。本文还有配套的精品资源点击获取 达梦数据库数据迁移全攻略：从工具选型到一致性校验
简介达梦数据库数据迁移方式以PPT课件形式提供聚焦达梦数据库与其他数据库、文本数据间的迁移场景面向数据库运维、实施工程师以及信创项目相关技术人员帮助读者在有限工期内规范完成迁移准备与正式迁移。内容按引言、迁移准备、正式迁移、总结四个模块展开迁移准备部分涵盖项目背景、移植范围、时间与性能目标、风险评估等调研项以及源端数据库类型、网络连通性、客户端和图形化桌面等环境核查要点正式迁移部分说明DTS迁移原理与参数配置、JDBC驱动版本对应关系、DMHS工具使用条件并针对系统错误、分析失败、表迁移成视图等常见问题整理了排查思路。资源为单个pptx文件大小5.83MB结构紧凑可直接用于项目培训或迁移方案交流。已有209人学习适合正在规划数据库迁移或希望系统梳理达梦迁移流程的读者学习参考。1. 达梦数据库的数据迁移比你想的更依赖工具链做过几轮达梦数据库数据迁移我最深的印象是真正让团队熬夜的往往不是达梦本身而是把数据迁移方式选错了。有人拿着建表脚本直接跑跑到一半报“模式错误”整批回滚有人写程序从源库一条条查、再往目标库插几千万行的流水表跑了三天还没跑完也有人想照搬 Oracle 那套备份思路结果字符集、自增列、大字段轮流出问题。我常用到的达梦数据库数据迁移方式可以分成四类图形化工具 DTS、命令行工具 dexp/dimp、外部表导入以及临时取数用的 disql 脚本。选择的标准很简单先看数据是跨库还是跨文件、再看要一次性搬完还是要持续同步。这个选择做完迁移工作就完成了一半。这篇笔记适合正在把 Oracle/MySQL 上的数据迁到达梦、或者在两套达梦库之间做数据汇聚的从业者。后面每一章都会落到具体参数和操作命令能直接在自己的环境里照着跑。2. 迁移方案选型先回答三个问题再碰工具2.1 先给结论场景决定工具不要一上来就开 DTS很多人拿到达梦数据库之后第一反应就是打开自带的图形化数据迁移工具 DTS。我理解这种习惯图形界面确实省心但它不是所有场景的最优解。我一般先问自己三个问题数据源是数据库还是文件数据量是几十万行还是几千万行这次迁移是要一次性搬完还是以后每个月都要搬这三个问题问完工具基本就定下来了。如果源和目标都是达梦且要做整库搬迁我会优先考虑 dexp/dimp 或备份恢复而不是 DTS。原因是同构库之间走逻辑导出导入对象依赖、索引、约束都能原样带过去整体速度也比跨库读写好几个量级。如果源是 Oracle、MySQL、SQL Server 这类异构库DTS 反而是最稳的默认选项因为它在内部把源库类型映射到达梦类型的工作做了省掉大量手工建表和改类型的成本。如果数据以 CSV、TXT 文件形式存在那根本不需要连数据库迁移外部表映射一下用 SQL 就能把文件读进来。迁移场景推荐方式理由异构库(Oracle/MySQL/SQL Server)迁到达梦DTS图形工具自带JDBC/ODBC适配和类型映射自动建表两套达梦库之间整库迁移dexp/dimp 或备份恢复同构通道对象和依赖保留完整速度快文本文件(CSV/TXT)入库外部表 INSERT SELECT不需要源库连接文件直接映射成临时表少量临时取数disql 执行SQL一条命令连库跑完不建工程不落文件需要在不停机场景持续同步达梦CDC/数据同步方案解析库日志追增量全量迁移后追平窗口这五个方向是我这几年用得最多的组合后面第3、4、5章都会按这张表展开。选中工具之后还会遇到一个容易忽略的决策点这次迁移是一次性的还是要做成经常性任务。一次性任务条件反射是“怎么省事怎么来”打开 DTS 建个任务拖一拖执行完就算完。经常性任务就不能这样图形界面点来点去没法交给调度系统日志、告警、重试都不好处理我会把这类长期任务写成 dexp/dimp 脚本进 crontab 或调度平台这样哪天失败了能看日志定位重跑也只是一条命令的事。所以不要一上来就点 DTS。先判断数据形态再判断迁移频率最后再选工具。顺序反了后面往往要返工。2.2 DTS 图形化工具的内部逻辑为什么它是默认选项DTS安装目录里的名字一般是“数据迁移工具”是达梦数据库自带的图形化迁移工具。它的工作流程可以概括为四步连接源库读取元数据把源表结构翻译成达梦的建表语句按目标库语法生成对象再分批读取源表数据写入目标表。整个过程里最值钱的部分是类型映射规则这也是推荐用它处理异构迁移的核心原因。举个例子Oracle 里的 NUMBER(38,0) 既可能是整数也可能是金额MySQL 里的 datetime(6) 带微秒精确到小数秒SQL Server 里的 nvarchar(4000) 在 UTF-8 下字符长度和字节长度还不一致。如果自己写迁移程序每种数据库都要重新写一遍映射逻辑还要逐字段核对精度工作量极大。DTS 把这张映射表内置了界面上一勾目标建表语句就自动生成省掉的这部分劳动量往往就是项目按期交付的关键。但这不意味着 DTS 是黑匣子你只管点下一步就行。实际使用中有一半的问题出在连接阶段DTS 连接源库一般通过 JDBC 或 ODBC 驱动驱动文件需要提前放到指定目录不同数据库的驱动版本差异也会导致连接失败连接串里的 schema 和字符集参数很多人在这一步漏掉导致后面目标表上出现一堆怪异的类型和乱码。我的建议是每次建任务前先把源端元数据用查询语句拉一遍确认表清单、列名、字符集三项信息再开始配置迁移任务。DTS 另一个容易被低估的能力是任务配置可复用。建好的任务可以保存成一个工程文件下次迁移同结构的库时改一下连接信息就能再用。我在项目里会把 DTS 工程文件一并交给运维作为后续其他库迁移的模板。这样做的好处是团队里任何一个人拿到工程文件都能复现迁移过程不需要依赖当初建任务的那个人的记忆。后面第3章会具体讲任务里哪些参数值得调。这里先记住一个结论DTS 适合做异构库的一次性、可交互的迁移任务它是默认选项但不是所有场景的唯一选项。2.3 命令行兜底dexp/dimp 和 disql 各自的适用边界DTS 负责交互式迁移但交付项目里我更信任命令行。达梦自带的 dexp 和 dimp 是逻辑导出/导入工具dexp 从库里抽取对象和数据生成 dmp 文件dimp 再把 dmp 文件导回目标库。它的适用边界非常清晰两边都必须是达梦数据库版本尽量接近数据量在几十 GB 内时效率很高。如果源库不是达梦dexp 连不上去还是得回到 DTS 或外部表方案。# 逻辑导出把 DMUSER 这个模式下的对象和数据导出为 dmp 文件 dexp USERIDSYSDBA/你的密码127.0.0.1:5236 \ FILE/backup/dmuser.dmp \ LOG/backup/dmuser_exp.log \ SCHEMASDMUSER \ ROWSY \ INDEXESY这里每个参数都是日常必用项。USERID是连接信息格式固定为“用户名/密码IP:端口”示例密码要替换成安装达梦时设置的管理员密码FILE指定导出文件路径注意目录要先建好并且有写权限否则导出会在最后一步才报错浪费大量时间SCHEMAS指定要导出的模式名不是用户名。虽然达梦中用户和模式同名但概念上要区分开ROWSY控制是否导出数据只要结构就改成NINDEXESY把索引定义一并导出目标库导入后不用重建索引。# 逻辑导入把 dmp 文件导入目标库对应模式 dimp USERIDSYSDBA/你的密码127.0.0.1:5236 \ FILE/backup/dmuser.dmp \ LOG/backup/dmuser_imp.log \ SCHEMASDMUSER \ IGNOREYdimp 的IGNOREY是我每次必开的参数。它的含义是目标库中如果已经存在同名对象跳过创建步骤继续导入数据和后续对象。很多新手第一次导入看到“对象已存在”的报错就停了其实加上这个参数让导入流程继续往下跑往往就是正确结果。还有一个容易忽略的点如果源表带有触发器dimp 导入数据时触发器会被真实触发大表导入可能会因此变得极慢。迁移前最好先确认目标表的触发器状态或者先禁用触发器再导入。disql 是达梦的命令行 SQL 客户端对应 Oracle 的 sqlplus。它既支持交互式操作也支持从文件执行 SQL。临时取数、巡检、校验行数这类轻量操作我都是直接用 disql因为不需要打开任何图形工具一条命令就能拿到结果。# 用 disql 执行一条查询并退出 disql SYSDBA/你的密码127.0.0.1:5236 \ -e SELECT COUNT(*) FROM DMUSER.ORD WHERE ORDER_DATE 2025-01-01;-e参数让 disql 执行完 SQL 后直接退出不进入交互式提示符这个特性在 Shell 脚本里非常关键。第5章的定时增量同步脚本就是围绕 dexp、dimp 和 disql 三条命令拼出来的。三者的分工可以归纳成一句话DTS 管复杂异构迁移dexp/dimp 管同构库间的结构化搬运disql 管日常查询和脚本化执行。3. 用 DTS 把数据搬过去建任务、调参数、跑批3.1 建第一个迁移任务连接源端和目标端时别忽略的两个字段DTS 的界面结构在不同版本上略有差异但核心流程是稳定的。打开工具后先新建工程然后在工程里新建迁移任务选择源库类型Oracle、MySQL、SQL Server 等都列在这里填入源库的 IP、端口、服务名或数据库名再选择 JDBC/ODBC 驱动类型接着填目标达梦库的连接串勾选要迁移的表或整个模式最后执行任务。大部分表直接采用默认映射就能迁成功决定成败的其实是连接阶段的两个字段。第一个是驱动类型。同样是连 MySQLODBC 和 JDBC 进入 DTS 后的表现不一样尤其在中文数据的处理上选错驱动可能出现字符串被截断、乱码一类的问题。我一般在 Windows 上优先用 JDBC在 Linux 服务器上按数据库官方推荐的 JDBC 驱动来处理如果源库没有现成驱动需要先去数据库厂商页面下载对应驱动包放到 DTS 能读到的目录再重启工具才能看到。驱动版本也不建议随便换DTS 官方适配过的版本往往比最新版更稳这一点在生产环境里比想象中重要。第二个是目标端 schema。达梦里建一个用户会自动生成同名模式DTS 默认会把源表创建到目标连接用户同名模式下面。比如你用 SYSDBA 连接目标库去跑迁移表会建在 SYSDBA 的模式下但业务程序可能期望表在 APPUSER 名下。这个问题在异构迁移里非常常见业务连上新库后报“表或视图不存在”实际上表存在只是模式不对。解决方式是在 DTS 目标端的模式设置里显式指定或者提前建好目标用户并把默认模式切过去再开始跑迁移任务。3.2 五个必调参数批大小、事务提交频率、并发连接数、字符集、LOB 阈值DTS 界面上的参数名在不同版本里叫法不完全一样但下面这五个参数我每次都会看它们直接影响迁移速度和能否跑完。参数建议值说明每次读取行数(批大小)1000~2000太小网络往返多太大内存占用高事务提交频率每 1 万行提交提交太少导致回滚段暴涨太多则性能下降并发连接数2~4最多 8大表可提升但目标端压力随之上升字符集转换按源端实际字符集配置避免中文乱码和长度超限LOB 字段读取阈值64KB~256KB超过阈值改用文件流写入防内存飙升批大小决定一次从源库读多少行批量写到目标库。值太小时每批的网络往返和 SQL 拼接开销占比高几千万行的表会明显变慢值太大时DTS 进程占用的内存会随批大小线性增长低配服务器上跑 OOM 的多数情况就是这里设太大。我在生产上一般设 1000字段多的大宽表降到 500简单表可以提到 2000。事务提交频率是最容易忽略的一项。迁移任务默认可能是每批提交源端一个事务里如果有几十万行目标端就要攒几十万行的重做回滚段压力会很大。把提交频率调成每 1 万行一次目标端就能及时释放锁和日志空间整体反而更快。注意这个参数要和批大小配合看批大小 1000、每 10 批提交一次是一个相对稳定的组合。并发连接数指的是 DTS 同时开启几个连接来读源库和写目标库。并发不是越高越好目标库的 redo、undo 和磁盘 IO 就那么宽连接数设到 10 以上往往数据库自己先成为瓶颈。我的经验是默认 2 个连接起步跑一遍看目标库等待事件明显等待再往上加一般到 4 个已经很快。字符集转换这个参数很多任务因为没开它而翻车。源库是 UTF-8目标达梦默认字符集可能是 GB18030数据里含有生僻人名、emoji 或不常见符号时迁移过程可能直接报“字符集不兼容”或“无效字符”。处理方式是在 DTS 字符集选项里选择源端实际字符集让工具在写入前做转码。此外目标库本身也能改字符集但建库之后再改代价很大迁移前先确认目标库字符集比迁移后统一改数据明智得多。LOB 字段读取阈值主要影响带 BLOB/CLOB 的表。默认情况下 DTS 把大字段读进内存再写入阈值太高时一张带几百 MB 附件表的迁移会持续吃内存甚至一直卡在某个大字段上。把阈值调到 64KB 或 256KB超过这个大小的大字段改成文件流方式落地内存占用会稳定很多。第4章里我会专门讲一次因为 LOB 参数没调导致的迁移卡死排查。3.3 跑批之后快速核对用 disql 脚本验证表级数据差异DTS 任务执行完并不代表迁移结束我习惯立刻用命令行脚本对每个大表做行数和最大主键比对。这个动作能提前发现绝大多数“任务显示成功但目标缺数”的问题比如源表在迁移期间又有新写入、某些约束导致部分行被忽略、以及中断重跑时的重复数据。#!/bin/bash # 源库和目标库连接串按实际情况替换 SRCSRC_SYS/你的密码127.0.0.1:5236 DSTSYSDBA/你的密码127.0.0.1:5236 TABLESORD CUST ACCT for t in ${TABLES}; do echo 表 ${t} # 源库行数和最大主键 disql ${SRC} -e SELECT COUNT(*) FROM SRC_SYS.${t}; | grep -E ^[0-9]$ disql ${SRC} -e SELECT MAX(ID) FROM SRC_SYS.${t}; | grep -E ^[0-9]$ # 目标库行数和最大主键 disql ${DST} -e SELECT COUNT(*) FROM DMUSER.${t}; | grep -E ^[0-9]$ disql ${DST} -e SELECT MAX(ID) FROM DMUSER.${t}; | grep -E ^[0-9]$ done这里用grep -E ^[0-9]$是为了把 disql 输出里的表头、分隔线全过滤掉只取纯数字的结果行。脚本输出的四个数字依次是源库行数、源库最大主键、目标库行数、目标库最大主键四列对比下来哪张表缺数一目了然。如果两边最大主键一致但行数不一致说明中间有删除或重复数据需要进一步排查约束。补数建议用 dexp 按主键范围抽取后再 dimp 导入不要去手工拼接 SQL 逐行插入。比如发现目标库 ORD 表最大主键比源库小就可以把源库大于目标最大主键的记录导出成一个 dmp再导入目标库。这比写 INSERT 语句安全也不会触发额外的应用层逻辑。4. 达梦数据库迁移避坑5 个高频问题与现场处理4.1 连接后报“模式错误”达梦的用户和模式是一一对应的现象连接配置都正确但迁移工具或应用访问目标表时报“模式错误”“schema 不存在”或“无效的模式名”。原因达梦中每个用户默认对应一个同名模式迁移前没有在目标库创建对应的用户/模式或者连接用户与表所在的模式不一致。比如源表建在 A 用户下你却在 B 用户下查找这张表达梦不会自动跨模式解析对象名。解决先建用户再迁移或者连接到目标库后切换当前模式。下面这段 SQL 在目标库执行一遍建好模式再重新跑任务。-- 在目标库执行为迁移单独建一个用户同名模式会随用户创建 CREATE USER DMUSER IDENTIFIED BY 你的密码; GRANT DBA TO DMUSER; -- 连接后把当前会话切到目标模式 SET SCHEMA DMUSER;在 disql 里执行SET SCHEMA之后当前连接对不带模式前缀的表名都按 DMUSER 解析这样逐条核对数据时不容易写错。另外一个习惯是DTS 建任务时就在目标端设置里把默认模式指定好不要让工具帮你猜。迁移任务结束后再用 4.1 的第一条命令把所有相关表重新确认一遍所属模式能避免后续应用连库时报一模一样的问题。4.2 字符集不一致乱码、长度报错、索引超长现象目标库查出来的中文是乱码迁移过程中报“数据超长”或被截断VARCHAR 列建立索引时报索引长度超限。原因源库和目标库的字符集不一致。GB18030 下一个汉字占 2 字节UTF-8 下占 3 字节同一列定义长度在两种字符集下可容纳的汉字数量不同。源表 VARCHAR(50) 里存了 50 个汉字如果目标列按 GB18030 计算长度时定义成了 VARCHAR(80)迁移时直接超限。解决迁移前先确认目标达梦库的字符集再选择是否在 DTS 里开启字符集转换。-- 在目标达梦库查看字符集相关参数 SELECT * FROM V$DM_INI WHERE PARA_NAME LIKE %CHAR%;这条 SQL 会把和字符集相关的参数列出来常见版本里能看到 CHARSET 或 UNICODE_FLAG 之类的项具体值对照当前版本的手册确认。如果已经迁完成出现乱码优先判断是历史脏数据还是迁移时转码导致后者可以重跑任务并在 DTS 中打开转码。如果只是列宽不够用ALTER TABLE ... MODIFY 列名 VARCHAR(更大的长度);调整别在应用层做二次截断。4.3 大字段表迁移卡死LOB 读取阈值没调现象DTS 跑到某张带 BLOB/CLOB 的表时进度条长时间不动几十分钟都没有新日志DTS 进程的内存占用却一路走高。原因默认把大字段整体读入内存再写入一张含几百 MB 附件记录的表会把批处理缓冲区直接占满批大小再大一些一次要同时组装多个大字段内存和磁盘 IO 双双打满任务就像卡死了一样。解决先把任务停掉把 LOB 读取阈值调低到 64KB超过阈值的大字段改用文件缓存方式写入同时把批大小降到 500降低单批内存峰值。环境不允许停任务时可以把这张表拆成多个子任务按主键范围分段迁移每个分段的数量控制在几百条以内。还有一种更实用的兜底方案迁移主表时先把大字段排除或者把大字段临时置空等全部普通字段迁完了再单独开一个小任务只迁 BLOB/CLOB 列。这样做的好处是业务最关心的核心字段能先上线大字段后补齐不会因为单张大表拖住整个迁移窗口。4.4 自增列和序列没迁过去插入数据报主键冲突现象数据行数完全一致但业务系统往新库插入时立刻报主键冲突或者新插入数据的主键和已有数据的主键重叠导致后续主键增长错乱。原因DTS 把数据搬过去了但表上的自增列属性或配套的序列并没有跟着数据重建。应用插入时从序列拿到的下一个值是 1而表里已经有主键到 100000两条新数据直接就撞上了。解决迁移后手动重建序列并让序列的起始值大于源表当前最大主键。-- 先确认目标表当前最大主键 SELECT MAX(ORDER_ID) FROM DMUSER.ORD; -- 重建序列START WITH 必须大于当前最大主键 CREATE SEQUENCE SEQ_ORD START WITH 1000000; -- 应用如果使用序列把序列赋权给业务用户 GRANT USAGE ON SEQ_ORD TO DMUSER;序列名称尽量和源库保持一致否则应用里拼的 SQL 可能找不到序列。如果建表时用的是 identity 自增属性还需要检查 DTS 是否勾选了“迁移自增属性”没勾就在目标表上补列属性。我的习惯是迁移计划里专门加一步“序列与自增列对齐”和 3.3 的核对脚本一起执行。4.5 校验只看行数为什么迁移后业务还是对不上现象两边 COUNT(*) 完全一致但业务报表跑出来数据偏差金额总和不对或者某些明细查不到。原因只比了行数。类型映射时精度丢失、DECIMAL 被截断成整数、字符被截断、唯一约束没建导致重复数据混入这些都不会影响行数却会直接影响业务结果。解决做三层校验。第一层比行数和最大主键第二层比关键数值列的合计、最大、最小专门发现精度问题第三层抽样几条明细记录逐字段比对。-- 对比两库订单金额合计用 TO_CHAR 保留原始精度 SELECT TO_CHAR(SUM(AMOUNT)) FROM SRC_SCHEMA.ORD; SELECT TO_CHAR(SUM(AMOUNT)) FROM DMUSER.ORD; -- 对比唯一约束和索引数量 SELECT COUNT(*) FROM USER_INDEXES WHERE TABLE_NAMEORD; SELECT COUNT(*) FROM USER_CONSTRAINTS WHERE TABLE_NAMEORD;TO_CHAR是为了避免客户端可视化格式化掩盖精度差异。索引和约束的对比同样重要DTS 建表时如果没有把唯一索引迁过去目标表可以写入重复数据行数可能对得上业务逻辑却已经错了。这一层校验做完才敢说迁移结果可用。5. 用外部表与 dexp/dimp 做不依赖图形界面的快迁5.1 外部表把文本文件映射成可查询的表客户只给了一个 CSV 导出文件、没有源库连接权限这是迁移项目里经常遇到的情况。此时不需要申请数据库权限也不需要装驱动直接建一个外部表把文件映射成表然后用 SQL 把数据搬进正式表就行。外部表本身不占用数据库存储空间它只是把文件当作只读表来看待。-- 建外部文件目录并授给目标用户读写权限需要DBA权限 CREATE DIRECTORY EXT_DIR AS /data/load; GRANT READ, WRITE ON DIRECTORY EXT_DIR TO DMUSER; -- 把 CSV 映射成外部表字段顺序与文件列一致 CREATE EXTERNAL TABLE DMUSER.EMP_EXT ( EMPNO INT, ENAME VARCHAR(50), SAL DECIMAL(10,2) ) FROM /data/load/emp.csv FIELDS TERMINATED BY , RECORDS DELIMITED BY \r\n ERRORS 1000; -- 先确认外部表能正常读取再写入正式表 INSERT INTO DMUSER.EMP (EMPNO, ENAME, SAL) SELECT EMPNO, ENAME, SAL FROM DMUSER.EMP_EXT;FIELDS TERMINATED BY ,定义了列分隔符RECORDS DELIMITED BY \r\n定义了每条记录的分隔方式Windows 下导出的文件通常是\r\nLinux 下往往是\n这里写错会导致所有记录被当成一行ERRORS 1000表示解析过程中允许跳过最多 1000 条坏行防止一行脏数据中断整个导入。如果 CSV 第一行是表头先确认外部表是否支持 skip 参数不同版本支持情况不一样我一般直接用sed -i 1d把表头那行摘掉再做映射。外部表最适合的形态是一次性历史数据入库文件数量不多、单文件大小可控、字段类型简单。把文件映射成外部表之后可以直接 join 正式表做增量对比也可以加 WHERE 条件只导入需要的分区数据这比写 Python 逐行读文件快得多。5.2 用 dexp/dimp 做定时增量不依赖图形界面的同步分析库每天要同步生产库的新增订单这个场景适合用 dexp/dimp 做定时增量不需要每次人工打开 DTS 点任务。我的做法是crontab 里挂一个 Shell 脚本凌晨从生产库按主键或时间条件抽取增量数据生成 dmp 文件再导入分析库。#!/bin/bash # 每夜从生产库抽取当天新增订单导入分析库 PRODPROD_SYS/你的密码生产库IP:5236 DWSYSDBA/你的密码分析库IP:5236 DMP_FILE/backup/inc_ord_$(date %F).dmp # 按主键或时间字段抽取增量数据 dexp USERID${PROD} \ FILE${DMP_FILE} \ TABLESPROD_SYS.ORD \ QUERYWHERE ORDER_DATE TO_DATE(2025-01-01, YYYY-MM-DD) \ ROWSY # 导入目标库已有对象跳过 dimp USERID${DW} \ FILE${DMP_FILE} \ SCHEMASPROD_SYS \ IGNOREYQUERY参数里的引号嵌套是很多人卡住的地方SQL 条件本身需要单引号但又不能和外层参数引号冲突所以脚本里用双引号包住整个 WHERE 子句内部时间字符串再写成两个连续单引号。实际写脚本时建议先echo打印一遍最终的 dexp 命令确认引号转义正确再执行。增量条件优先用主键或时间戳字段具体用哪个取决于源表有没有合适的创建时间列。如果目标分析库不想用 PROD_SYS 这个模式名我会在导完后用视图或CREATE TABLE AS SELECT做一次模型层的转换而不是强行要求命令行工具支持模式重映射。增量同步脚本跑一段时间后注意观察 dmp 文件大小如果每天都接近全量说明源表的数据分布和条件选择出了问题需要重新考虑用 CDC 方案。5.3 三种轻量路径的边界什么时候不该用外部表方式适用场景不适用场景外部表CSV/TXT 一次性入库、无源库连接数据量大到上亿、需要频繁增量、字段含复杂 LOBdexp/dimp达梦到达梦、整表/条件导出导入异构源库(Oracle/MySQL)、需要实时同步disql 脚本小表查询、临时取数、快速校验大表逐行处理、跨库数据搬运判断标准我是这样掌握的单表超过几千万行或者字段里有大规模大对象就老老实实走 DTS 或 CDC数据文件超过几个 GB 且要长期反复入库优先考虑先落成数据库表再迁移而不是每次都让外部表扫一遍大文件增量同步一旦出现“每天补数超过表总量 20%”的情况说明业务对时效的要求已经不适合离线批处理该上 CDC 实时追平了。轻量路径的定位是“快速、可靠、不惹麻烦”一旦这三个词满足不了就升级方案。6. 迁移后的校验与增量追平CDC6.1 迁移结果三件套行数、金额、约束我用惯的客户端连上达梦数据库跑三层校验。第一层是行数和最大主键第二层是数值列 SUM/MAX/MIN 对比第三层是把两边索引和约束数量拉平对比。三层都通过之后再开始内部业务口径的验证比如抽几条订单明细逐字段核对。6.2 用 CDC 追平全量迁移窗口期全量迁移往往要跑几个小时这个过程里源库还在持续写入。如果业务要求系统切换时数据基本对齐就要在迁移开始时记录一个时间点迁移完成后把该时间点之后的增量变更追平。达梦库具备 CDC 能力通过解析数据库日志拿到增删改事件再按主键应用到目标库具体开启步骤和消费接口以对应版本的《数据同步/CDC 使用说明》为准。启用前确认归档空间充足因为开启后日志量会有明显上涨。全量迁移不要和 CDC 并行跑通常是先全量、再增量追平、最后短暂停写切换。6.3 我习惯在开跑前做的三件事第一件备份目标库。达梦的备份可以用备份恢复工具做也可以在 disql 里执行备份命令迁移前留一个干净的还原点出了问题能迅速回到原位。第二件打印一张表映射清单写清源表名、目标模式、预计行数、预计耗时迁移完对着清单逐项打勾避免漏表。第三件先抽一张结构最复杂的单表在测试环境把全链路跑通确认类型映射、字符集、序列三个重点没有异常再正式开跑生产迁移。这三件事看起来笨却帮我躲过好几次灾难。尤其是那张表映射清单项目参与人越多越能体现出价值所有人对着同一张表沟通比群里翻聊天记录高效太多。希望这些实践对你下一次遇到达梦数据迁移能有点帮助。本文还有配套的精品资源点击获取