达梦数据库迁移实战：从Oracle兼容到性能调优的完整指南

做数据库维护这行十几年，隔三差五就被人问同一个问题：老系统跑在Oracle上，现在要往国产数据库迁，到底怎么选、怎么干？以前我遇到这类问题习惯先劝一句“谨慎”，直到真正完整做过几个达梦的迁移项目之后，对它的看法发生了明显转变。达梦数据库（圈内一般叫DM）是国内关系型数据库里绕不开的一张牌，它对Oracle语法的兼容度相当高，SQL方言、PL/SQL习惯、工具链设计都能让Oracle出身的人快速上手。这篇内容我不做产品宣讲，直接拆技术内核和迁移实践，包括存储与事务原理、迁移工具怎么选、存储过程怎么改、参数和SQL怎么调优，以及生产环境里那些不起眼却能坑人的细节。适合正在做选型评估的架构师、要接手迁移任务的DBA，以及在达梦上写业务代码的研发同学。

1. 先把底子摸清楚：达梦的技术内核长什么样

1.1 长得像Oracle，内核却是自己的一套

不要被“兼容Oracle”这四个字带着走，就以为达梦是一个换皮改造的开源数据库。我第一次登录达梦的disql界面时，确实有回到Oracle SQL*Plus的错觉：有实例、有表空间、有用户/模式、有数据文件，写SQL时VARCHAR2、NUMBER、SYSDATE、NVL这些老朋友都在。但往下看两层，存储格式、MVCC实现、redo日志、查询优化器都是自己的实现逻辑。

这个设计思路要这样理解：对外保留一套让Oracle开发者和DBA感到熟悉的使用模型，降低迁移的学习成本；对内采用自主内核，不依赖外部开源项目的技术债。实际运作中，这套方式把“好上手”和“自主可控”都占了。想验证这一点，最直接的办法是遇到故障时沿着日志往前翻，能翻到明确的模块和层级，而不是像查黑盒一样只能重启再观察。

当然，对于使用方来说，内核是谁的不重要，重要的是兼容行为是否一致。现实情况是，常规SQL语法没有大问题，但PL/SQL的边界条件非常多，各种隐式转换、异常传播、日期运算语义在不同数据库里总有偏差，这些细微差异才是迁移工程量的大头。换句话说，达梦解决了“能不能用”的问题，“好不好迁”还得看代码质量和不规范写法的多寡。

1.2 存储模型与事务机制：页、日志和回滚怎么协作

物理存储上的布局，达梦和传统集中式数据库的思路一脉相承。数据放在数据文件里，数据文件归表空间管理，用户在逻辑上建表建索引时指定表空间，表空间再对应到物理文件。初始化实例时有一个页大小参数，常见设置是4K或8K，也可以调得更大。页大小直接影响一行的最大长度、索引扇出和随机读写粒度，所以迁移前规划表空间时，最好先想清楚线上数据量和增长趋势，一次性把数据文件大小、是否自动扩展设置好。

我这个习惯是从几次扩容事故里学来的。有一回接手一个从Oracle迁过来的系统，建表空间时给了固定大小，结果上线第二天就报“磁盘空间不足”，业务直接停顿。后来所有新项目我都按“初期容量+半年增长预估”来建表空间，同时把自动扩展打开，但设一个安全上限，避免文件无限膨胀把磁盘塞满。

事务层面，达梦采用多数现代关系库都会走的MVCC思路：写操作在数据页上做变更，读操作通过版本快照读到一致数据，读写之间不互相阻塞。已提交事务的变更靠redo日志固化，实例崩溃后重放日志即可恢复。这个机制和Oracle的undo/redo体系在原理上同构，所以Oracle DBA迁移过来时，关于提交、回滚、日志、检查点的认知模型基本能直接沿用。

这里有个实操上容易忽略的点：达梦的UNDO信息保留时间可以配置。如果库上有长时间运行的查询，或者经常有大事务犹豫着不提交，undo被撑满的情况并不少见。迁移初期最好把这类参数纳入检查清单，别等到生产环境长查询报错才回头查原因。

-- 一个典型的初始化对象示例（在disql中执行） CREATE TABLESPACE TS_DATA DATAFILE '/dm/data/ts_data.dbf' SIZE 2048 AUTOEXTEND ON NEXT 128 MAXSIZE 32768; CREATE USER APP_USER IDENTIFIED BY "App@123" DEFAULT TABLESPACE TS_DATA; GRANT DBA TO APP_USER;

1.3 兼容模式开关怎么理解

达梦在初始化实例时允许设置兼容模式，让你按源库选择一个更贴近的方言行为。从Oracle迁过来，就把模式调成Oracle，SQL解析器会更宽容地接纳Oracle写法；从MySQL迁过来，则选择对应的MySQL兼容模式。

但这是一个“尽力兼容”的开关，不是免死金牌。开了兼容模式，解决的是高频语法的解析差异，比如外连接写法、常用函数语义、序列取值方式。冷门用法、老系统多年攒下的特殊写法、第三方框架生成的怪SQL，仍然需要单独处理。我在迁移项目里通常的做法是：先按源库设定兼容模式，把全量存储过程、视图、触发器和业务SQL跑一遍，收集报错清单，再逐条人工翻译。

有一点务必记住：兼容模式的验证一定要放在仿真环境里做，不要在生产库上开着开关做实验。有些参数改起来容易，但影响面是全局的，生产环境一旦出现边界问题，回滚成本远高于事前验证。

2. 迁移实战：从体检到上线，一条可复制的路径

2.1 迁移前的对象盘点与风险评估

拿到一个待迁移系统，不要急着打开工具点“迁移”。先用系统视图把老库的家底摸一遍。我习惯整理一份对象清单，主要包含：表的总数和清单、每张表的数据量和预估存储、Top大表、分区表分布、索引数量、约束和外键关系、序列、视图/物化视图、同义词、存储过程、函数、包、触发器、定时作业。

把清单导成表格之后，按对象类型估算迁移工作量，基本就能判断项目要排几天工期。风险评估我只看四个信号：有没有大字段表，这类表对迁移工具和日志压力都大；有没有外键和触发器交叉依赖，容易造成导入顺序错误；有没有冷门系统包或企业特性功能，比如高级队列一类，往往没有直接对等物；有没有跨库DBLINK和分布式查询，这类对象在集中式迁移时常常要重构应用，而不是单纯做数据库迁移。定位完这四个信号，项目复杂度八九不离十。

2.2 图形工具DTS和命令行dexp/dimp怎么选

达梦自带的数据迁移工具DTS，是用过几次之后我觉得性价比最高的入口。图形界面上选择源库类型，填好连接信息，勾选需要迁移的表、视图、存储过程等对象，设置映射规则，就能跑一个迁移任务并输出报告。几十张表的中小型系统，这套流程一两个小时能完成，适合第一次接触达梦的人。

工具顺滑的前提是源、目标两边网络稳定，且对象之间没有太多复杂嵌套依赖。如果表数量上千，或者单表数据量到TB级别，图形工具反而不是最佳选项。我的做法是混合路线：先用DTS迁移结构，也就是把库、表、索引的脚本建出来；再用逻辑导出导入命令dexp/dimp迁移数据。dexp导出、dimp导入的使用逻辑和Oracle的exp/imp相似，只是文件格式和控制参数不同。

# 导出整个用户的数据（示例） dexp USERID=SYSDBA/password@localhost:5236 FILE=app_data.dmp SCHEMAS=APP_USER # 在目标库导入 dimp USERID=SYSDBA/password@localhost:5236 FILE=app_data.dmp SCHEMAS=APP_USER

这里有个重要细节：数据量大时不要一股脑跑单事务。导入端最好按主键或分片把数据切成多个批次，每批几千条提交一次。我在一次测试中发现，上千万行的表用一个事务导入，中途失败回滚能把磁盘IO拖到极低，回滚时间比正常导入还要长几倍。分批提交虽然感觉慢一点，但可控性远好于一次性梭哈。

2.3 存储过程与视图改造：真正的重头戏

数据迁移只是第一步，代码改造才是决定工期的核心。从Oracle到达梦，存储过程中最常见的兼容问题我整理过一张清单，按出现频率排序大致是：VARCHAR2长度单位，Oracle按字节，达梦默认按字符计算，不一致会导致字段截断或报错；字符串空值处理，||遇到NULL的结果可能在两边不同，需要主动用NVL或COALESCE包装；日期运算，SYSDATE+1这种写法在部分模式下含义不同，建议统一改成显式日期函数；隐式类型转换，Oracle比较宽容，达梦更严格，常见于数字与字符串拼接；系统包名，UTL_FILE、DBMS_SCHEDULER等在达梦有对应实现，但名称和参数不完全一致。

改造时我习惯先批量导出源库所有存储过程源码，用脚本统计用到的函数和系统包，形成一个“用词清单”，再和达梦支持列表对比。命中的先自动替换，未命中的单独评审。工具能完成60%的体力活，剩下的逻辑判断无论如何都要人来处理。

视图改造相对简单，但因为视图依赖底层表和函数，建议按依赖顺序逐层创建。触发器要格外小心，Oracle触发器里对NEW、OLD伪记录的用法，在达梦里大体兼容，但触发条件、自治事务的处理存在差异，需要逐个验证。曾有一次迁移，我把一张表的INSERT触发器原样搬过去，结果达梦报“递归触发”错误，查了半天才发现是源库通过触发器控制序列取值，而目标库已经支持IDENTITY自增，两边机制叠加造成了触发循环。

3. 性能调优：参数、统计信息、SQL一个都不能少

3.1 初始参数设置经验

达梦装好之后默认参数能用，但别指望性能有多好。我见过好几个案例，应用迁移后反应变慢，最后查下来都是内存参数没调，数据缓冲区个数不够，热点数据频繁淘汰。达梦里对性能影响直接的参数包括：BUFFER_NUM（数据缓冲区个数）、MAX_BUFFER（缓冲区总大小）、MAX_SESSIONS（最大会话数）、UNDO_RETENTION（回滚数据保留时间）等。

-- 调整数据缓冲区个数（示例，是否静态取决于具体参数定义） SP_SET_PARA_VALUE(1, 'BUFFER_NUM', 16);

参数调整要小步快跑，一次只改一组相关参数，观察性能曲线变化。所有修改都记录在案，方便回退。具体调多大没有统一公式，要和物理内存、并发量、数据工作集挂钩。我自己的做法是：先按物理内存的30%-50%估算缓冲区总量，设置好后观察命中率，跑几天再微调；连接数根据应用连接池和网关数倒推，留20%以上冗余；回滚保留时间的设置要权衡长查询和大事务，不要为了减少undo占用盲目调小。

很多人一上来就照搬网上的“最佳实践”文档，结果库越大越容易出问题。原因很简单，参数之间是联动的，物理内存、磁盘类型、业务并发都不一样，同一组参数在不同环境表现可能天差地别。

3.2 统计信息没收集，加多少索引都没用

Oracle迁移到达梦后，慢SQL往往不是优化器不行，而是没有统计信息可用。目标库刚导完数据，优化器对表行数、列分布、索引选择性一无所知，只能靠默认猜测来选执行计划，自然容易选成全表扫描或者糟糕的连接顺序。

解决方案是迁移完成后第一时间收集统计信息。达梦支持DBMS_STATS风格的系统包，可以对指定用户或指定表做统计信息收集。

-- 收集某个用户下所有对象的统计信息（示例） DBMS_STATS.GATHER_SCHEMA_STATS('APP_USER'); -- 查看一条SQL的执行计划 EXPLAIN SELECT * FROM ORDER_MAIN WHERE ORDER_NO = '202401010001';

收集之后，再到disql里跑实际业务的慢SQL，用EXPLAIN看执行计划是否合理。如果某条SQL换完统计信息还是不理想，再考虑调整索引或者重写SQL。这里要纠正一个动作误区：发现慢SQL，第一反应不要加索引。应该是先看执行计划，确认它为什么慢，再决定是收集统计信息、改Join方式、加索引还是拆SQL。不加分析直接加索引，经常是旧问题没解决，反而让INSERT和UPDATE变慢。

3.3 锁等待、长事务与阻塞处理

数据库运行一段时间后，并发场景下最容易出问题的不是查询性能，而是锁等待。生产线上一旦有卡住的会话，往往不是SQL本身慢，而是有人在事务里长时间占着某张表的行锁不放。达梦提供了系统视图V$LOCK和V$SESSIONS，可以查到当前锁对象、持有会话和等待会话。定位到源头之后，可以用系统存储过程关闭对应会话，事务会被回滚，阻塞随即解除。

我在实际项目里遇到过一类非常容易忽略的案例：应用代码把事务边界扩大到了Service层，一个事务里不仅有数据库操作，还有远程接口调用、文件处理，事务迟迟不提交，把整张表锁死。有一次排查一个库存扣减超时问题，数据库侧锁视图里全是等待，源头会话却停在一个外部接口调用上，单看数据库根本发现不了。这种问题不是调优能解决的，必须回到应用的代码层面治理。

所以排查锁问题时，我一向建议DBA和应用开发一起看通话，不要只盯着锁视图发呆。先把长时间不提交的会话找出来，再逆推是哪段代码控住了事务，最后修正事务边界和超时时间。

4. 上线后的常见坑与排查手册

4.1 字符集问题：迁移后中文变乱码

字符集不一致是迁移项目里最常见、最能引发线上事故的一类问题。源库数据存成GBK，目标初始化时选了UTF-8，导入后中文会变成问号或乱码；反过来也一样。而且这种问题往往不是迁移当时爆发，而是业务第一次回显中文时才暴露，容易让人觉得是应用代码的bug。

规避方法是在初始化实例时就把字符集定为统一标准，所有环境保持一致；迁移成功后立刻执行全表抽查，把带中文的字段抽样查询一遍，确认无乱码再进入联调。如果已经导入错误数据且量不大，可以重新选择正确字符集的目标库重建导入。我到今天仍然把“确认字符集”当作迁移上线前的固定检查项，因为吃过太多次亏了。

有一次在客户现场做月度巡检，发现一张报表里所有客户名称都是“???”，当时第一反应是应用做了错误编码转换。查了一圈才发现，测试环境库是UTF-8，生产环境库初始化时被人顺手选了默认的GBK，开发所有联调都在测试库通过，生产库一上数据就乱。最后重建生产库才解决，有用信息是：环境差异和数据格式校验永远要比对三套环境来做。

4.2 序列与自增列：主键不连续的幕后原因

建表时用自增列，比如达梦支持的IDENTITY，是很多新开发的习惯。但迁移时，Oracle序列更容易出问题。Oracle里序列NEXTVAL取到的值可能在缓存块里跳号，达梦也允许配置序列缓存，迁移后如果业务逻辑依赖主键严格连续，就会集体炸锅。这类问题不常见，但真出现时排查半天才能定位。

更常见的坑是Oracle里一张表的默认值直接调用序列名.NEXTVAL，达梦对这种调用方式兼容。可一旦涉及多张表共用一个序列，两边NEXTVAL的推进节奏不一样，迁移后主键冲突也有先例。我的建议是：序列相关对象要单列一张清单，迁移前逐个核对依赖关系，必要时用触发器显式取序列值，确保新旧两边ID语义对齐。

4.3 分区表、大字段和高级特性的验证清单

老系统里多少都会用到分区表、CLOB/BLOB大字段、物化视图、同义词等高级特性。达梦支持范围、哈希、列表分区，支持大对象存储，也有物化视图与同义词机制，但支持程度不等于Oracle完全一致。比如分区表上的分区裁剪策略、大字段并发写入行为、物化视图的刷新方式，都可能在特定场景下表现不同。

因此在迁移计划里，我坚持“仿真验证优先于生产上线”。把DDL脚本先在仿真库执行一遍，把分区裁剪、大字段读写、物化视图刷新的实际结果记录成验证报告，尤其注意冷门参数写法和数据类型的边界情况。千万不要拿生产直接试探，这种试探一旦触发边界问题，回滚成本极高。

4.4 备份恢复与容灾，不能只是“配置过”

迁移上线的另一个高频盲区是备份恢复。很多环境部署了备份任务，日志显示成功，但从来没有真正做过一次恢复验证。直到某次磁盘损坏或误删数据，才发现备份文件里缺表空间、恢复命令参数不对。达梦可以用dmrman做物理备份恢复，也支持在disql里执行BACKUP DATABASE命令生成备份文件，核心思路和传统数据库一致。

-- 在disql中执行全库备份（示例） BACKUP DATABASE TO "FULL_BAK_20240101" FULL;

我的习惯是：每次备份策略调整后，都在临时环境做一次完整的异机恢复演练，包括备份文件、归档日志、重放日志、启动验证的全流程。上线切换前，再拿生产环境的备份做一次演习，确认从恢复到提供服务的时间窗口可控。备份这件事，追求的不是每天成功执行，而是“真到要恢复时一定能恢复”。

最后说点个人体会。在达梦上摸爬滚打这几回，我对“国产化替代”这件事的态度，从“先谨慎观望”变成了“有章法可循”。工具解决的是共性的80%，剩下20%靠对业务代码的理解、对数据库原理的掌握，以及一次次试错积累下来的排查清单。如果你正准备启动这类迁移，我给的建议是：先挑一个周边系统做试点，把流程跑通、把坑踩一遍，再铺开核心系统。一个成功的试点，比十份迁移方案文档都更能说服团队。