国产数据库迁移这件事，这几年只要做过 Oracle、SQL Server 或者 MySQL 存量系统改造的人，多少都被问过“能不能迁、好不好迁、会不会踩坑”。真正动手之前觉得步步都是雷，尤其是从 Oracle 迁到达梦这类国产库的场景，总会担心 SQL 方言、存储过程、大表数据、应用连接串这些环节出问题。实际跑完几轮之后我的判断是：迁移本身没有想象中那么难，难的是没有按“先盘点、再迁移、后验证”的顺序推进，导致每一步都像是在补前面的漏。下面这篇内容就以 Oracle 迁移到达梦为例，把整个流程压缩成三件事：准备阶段把账算清、迁移阶段把对象和数据按顺序搬完、切换阶段把校验和回滚做到位。如果你正在评估国产数据库替换，或者已经拿到一个迁移任务不知道从哪里下手，可以按这份思路先走一遍。
做迁移最大的误区，是以为把几十张表的数据拷过去就算完成。真正决定成败的是表结构、主外键、序列、视图、函数、过程、触发器，以及隐藏在业务 SQL 里的方言差异。数据表只是“看得见的工作量”，对象兼容性和应用改造才是“看不见的工作量”。所以我建议不要把迁移理解成一个大动作，而是拆成三个阶段来管理：迁移前的盘点与评估、迁移中的全量执行、迁移后的切换与验收。每个阶段有明确的输入、输出和判断标准，任何一个环节异常，都能定位到具体任务，而不是在一堆报错里猜。
1. 先把三个层面的兼容账算清，再决定怎么迁
很多人拿到迁移任务就急着创建目标库、打开迁移工具，结果跑到一半发现时间类型对不上、字符集不一致、存储过程编译失败，再回头改环境，返工成本非常高。正确做法是先做三天预判：数据能不能搬、对象能不能转、应用能不能跑。这三个问题解决不了，后续所有操作都会被反复打断。
1.1 数据层面最该检查的，不是字段多少，而是类型映射和字符集
数据层面的兼容风险主要出现在字段类型、字符集、大字段和超大表。Oracle 里常见的 VARCHAR2、NUMBER、DATE、CLOB、BLOB，在达梦中一般都有对应类型，但迁移工具通常会给出一套默认映射，这套默认映射不等于最优映射。举例来说，Oracle 的 NUMBER(10) 在达梦里可以映射成 INT，也可以映射成 NUMBER(10)，两种做法都能跑，但前者占用空间更小，后者和原库语义更贴近。我的经验是，结构小的系统可以直接用默认映射，结构复杂、有大量数值运算和核心报表的系统，最好手动过一遍类型映射。
字符集是另一个容易忽略的点。源库如果是 AL32UTF8，目标库初始化时也建议选择 UTF8 系列，避免中文乱码、长度计算偏差和排序规则不一致。有一类问题特别隐蔽：Oracle 里空字符串和 NULL 是等同的，如果你原来就依赖了这种行为，迁移到字符集或兼容模式不同的目标库后，可能出现字符尾部补空格、判断条件变化等问题。看起来是数据异常，实际是语义差异。
大字段和超大表要单独评估。CLOB、BLOB 不是不能迁移，而是在网络拓扑复杂、工具配置不当的时候，迁移速度会非常慢，甚至中途卡死。几十个 CLOB 字段的普通业务表问题不大，但如果有 TB 级日志表或者包含大量大字段的归档表，就要提前计划分片抽取。对于单次全量迁移，可以先统计每张表的行数、预估数据量，把超大表分成独立任务处理，不要和普通表混在一个队列里跑。
1.2 对象层面最缺的是一份完整的对象清单
表数据只是迁移对象的一部分。典型的 Oracle 业务库通常包含表、索引、主键、外键、唯一约束、check 约束、序列、触发器、视图、函数、存储过程、包。这些对象在迁移工具里不是不可以自动转换，但自动转换之后必须重新编译和验证。
最让我意外的是，很多项目查了很久找不到的问题，最后都出在索引和约束的顺序上。先迁移表再接外键，还是先建外键再导数据，执行效率完全不一样。正确顺序一般建议先建表结构，再迁移数据，最后补约束和索引。如果在导数据前就把外键全部建好，大数据量插入时会频繁校验关联关系，速度明显下降；如果先导数据再建索引，则能减少索引维护开销。
序列是 Oracle 应用里另一个高频依赖。迁移时如果只把序列对象复制过去，不检查当前值和实际表数据的最大值，等应用跑起来后很可能出现主键冲突。我在真实项目里见过一个榜单业务表，源库序列当前值比表里最大 ID 小了几千，原因是历史数据回滚过。迁移完新增数据直接撞主键。正确做法是迁移完所有表数据后，把每个序列的当前值调整为对应表主键最大值加一，或者至少检查一遍再上线。
存储过程和包是工作量最大的部分。达梦对 Oracle 的 PL/SQL 做了大量兼容，但并不是所有语法都能盲目照搬。包中的自定义类型、记录类型、数组在部分国产数据库中需要改写；隐式游标和动态 SQL 的写法也要逐一编译验证。不要指望迁移工具把所有代码对象改成百分百可执行，它能把大部分通用场景处理掉，剩下的要靠人工核对。这个预期要提前建立，否则进入联调阶段会发现一堆“编译通过但运行结果不对”的问题，比编译失败更难查。
1.3 应用层面的风险点，要先看 SQL 写法和配置依赖
应用层面不能放到迁移完成后再看。最合理的做法是在盘点阶段就明确项目里用了哪些连接方式、ORM 框架、持久层 XML 和手工 SQL。现在很多 Java 管理系统基于若依这类框架，这类框架底层通常是 MyBatis，切换数据库时工作量往往集中在 XML 文件里。如果框架自带分页插件支持多方言，大部分查询都能自动适配；如果业务代码里手工写了大量 Oracle 专属 SQL，就必须逐个排查。
典型高风险写法包括：使用 ROWNUM 做分页和取前 N 条、使用 Oracle 特有的函数如 NVL、SYSDATE 直接运算、字符串与数字隐式转换、MINUS 集合操作。这些语法不一定所有国产库都原样支持，即使支持，也需要确认当前数据库实例的兼容模式是否开启。所以迁移前最好让开发团队提前导出项目中的 SQL 关键字清单，按风险等级排个优先级。
2. 第 1 步：准备目标库和迁移通道，先让数据和对象都能“通起来”
这一步的目标很明确：目标库环境就绪、连接通道可用、对象清单完整、迁移工具能正常读取源库与目标库结构。很多人会跳过这一步直接开始迁移，其实环境准备阶段做得好不好，直接决定后面能否顺利执行。
2.1 初始化目标库时，字符集和兼容模式要先定下来
达梦数据库在创建实例时有几个初始化参数对迁移影响较大，尤其是字符集和兼容模式。字符集建议根据源库和业务需求提前选定，不要默认创建后再改，因为后期修改字符集非常麻烦，甚至需要重建实例。
如果你安装的实例模式下默认语法偏向 MySQL，那么在迁移 Oracle 项目时，部分 SQL 需要在内存层面做更多转换。这里需要说明白：不同版本的安装入口和界面表达会有差异，具体参数名称以官方安装文档为准，但原理是一样的——先用与源库同类的字符集和语法模式搭建目标环境，能最大程度降低后续迁移和改造成本。
2.2 创建业务用户，不要用系统管理员账号直接跑业务
迁移和使用过程中要区分管理账号与业务账号。安装达梦后一般会存在系统管理账号，可以用它来创建数据库、管理用户和初始化资源。但实际业务连接最好使用单独的业务用户，把表空间、默认表空间、权限都按生产标准配置好。
权限设置要遵循最小化原则：业务用户一般只需要对自己 schema 下对象的增删改查权限，以及对序列的使用权限。如果应用需要跨 schema 访问其他业务库，也要单独授权，不要直接给 DBA 级别权限。这样做一是安全，二是以后排查问题更清晰，三是在做数据回滚时不会因为权限过大误操作。
2.3 把源库结构清单导出，先做一轮纯结构对比
在正式迁移前，我建议先导出一份源库对象清单，包括所有表、字段、类型、长度、索引、约束、序列、视图、函数、过程、触发器等。然后连接目标库，先建一个空 schema，看看结构创建过程中有哪些会报错、有哪些类型映射需要调整。
这个“纯结构演练”非常值得做。它不涉及数据量，执行速度很快，能提前暴露 80% 以上的类型兼容和语法兼容问题。做完之后把报错清单收集起来，逐个确认是能自动修正、需要手工改写，还是可以忽略。如果这一步不跑，直接带着几十张表、上千万行数据去试错，每次失败都要等待很长的回滚或重试时间，效率非常低。
2.4 创建数据迁移任务前，先验证源库和目标库连接
无论你使用厂商提供的迁移工具、开源 DBeaver，还是自研脚本，第一步都是确保源库和目标库可以被同时访问。这里要注意网络连通性、驱动版本、账号权限和连接超时四项。
DBeaver 这类通用数据库管理工具非常适合做迁移前的结构查看、SQL 验证和迁移后的数据抽样，但它不是所有场景下的最佳大批量迁移工具。很多国产数据库会提供自己做数据迁移的图形化工具，用原厂工具转换 Oracle 结构通常比通用第三方工具更贴合同一厂商的兼容策略。所以在实际项目里，我会建议把工具分工明确：原厂工具用于批量结构和数据迁移，DBeaver 用于迁移前探查、迁移中抽查和迁移后对比。
3. 第 2 步：执行全量迁移，按“结构、数据、程序对象、验证”四层顺序推进
到了执行阶段，整个迁移任务要按依赖关系分层。一般顺序是：先建基础表和字段，再迁数据，然后补索引约束，再处理序列、视图、函数、过程、触发器等程序对象，最后做一次完整校验。如果不按这个顺序走，经常会出现数据已经导完，但外键约束导致后续修改无法进行的情况。
3.1 结构迁移：先不急着处理所有约束
迁移工具通常会生成目标库的建表语句。在批量执行时，我建议把主键、唯一约束、外键约束拆开处理。第一步只建表和字段，尽量不建外键；主键可以根据情况保留，因为它影响数据唯一性校验；但外键和部分索引完全可以等数据迁移完成后再补。
为什么这么做？数据迁移过程中经常会发生部分批次失败、重试、修改映射关系等操作，如果外键先建好，每次插入都要检查所有关联表，速度变慢不说，遇到批量更新还容易因为数据顺序问题触发约束冲突。先把数据导完，再统一补约束，出问题更容易定位。
3.2 数据迁移：大表要分批，小表可以一次过
数据迁移方式选择上，几十万行以内的小表可以直接通过迁移工具执行。几百万到几千万行的大表，不要在一棵树上吊死，建议把大表单独拿出来，按主键范围或时间条件分批迁移。这样做的原因是，长时间运行的单任务一旦出现网络闪断或内存溢出，整张表都要重来。分批任务的好处是失败后只需要重跑当前批次。
如果源库是生产环境，尽量在业务低峰期或停机窗口内执行全量迁移，避免源库持续写入导致数据不一致。有的团队会用“先全量、再补增量”的方式缩短停机时间，但补增量需要额外开发增量比较和同步脚本，复杂度会上升。如果业务允许短时间停机，就直接在停机窗口内完成全量抽取和导入，最简单，也最容易验证。
数据迁移过程中要关注工具日志。迁移工具一般会记录成功多少、失败多少、失败原因。不要看到失败数为 0 就认为全部结束，还要看是否有跳过记录、是否有因字段长度截断被自动忽略的行。我在项目里遇到过一种情况：字段类型映射为 VARCHAR2(100)，目标库映射成 VARCHAR(50)，源库中恰好有一条 80 个字符的记录，工具默认截断后写入，日志只记录一行“字段长度已调整”。这种问题不仔细看日志，校验时很难发现。
3.3 程序对象迁移：存储过程、函数、触发器最容易产生“编译通过但行为不同”
在表和索引完成后，开始处理视图、序列、函数、存储过程和触发器。视图相对简单，通常只要改写很少一部分；函数和存储过程则要重点验证。我们做完一批对象后，最好对每个对象单独执行编译或生成状态检查。比如某国产数据库会把对象状态分为有效和无效，如果有无效对象，必须逐个排查为什么无效，不能直接上线。
触发器是另一个高风险区。Oracle 项目里很多主键生成依赖“序列 + 触发器”，而有的数据库原生支持自增列。迁移时如果保留了触发器，新增数据可能产生重复 ID；如果删掉触发器，又可能影响依赖数据库生成主键的代码逻辑。这需要结合每条业务路径判断，不能一刀切。
存储过程中使用动态 SQL 时，变量拼接和数据库标识符的大小写也容易出问题。Oracle 默认把未加引号的对象名转换为大写，有些国产数据库则可能保留小写。迁移后如果应用层拼接 SQL 时传入了小写表名，而库里的对象是大写，就会出现“表或视图不存在”。这种报错非常容易误导人，让人以为表没迁过来。
3.4 数据校验：不能只查总行数，还要做字段级抽样
数据迁移完成后，第一轮校验通常是全表行数对比。两张表如果行数一致，只能说明没有丢行，不能证明列值没有变化。还需要做字段级校验。做法是取几张大表的分区或抽样键，分别统计每一列的非空个数、字段最大值、最小值、数值列求和。更严谨一点，可以在源库和目标库分别执行对主键排序后的哈希聚合，再把哈希值比对。
对于生产系统，我建议准备一套校验 SQL。不要临时手写，因为你需要在多次迁移演练中反复执行。把校验脚本固化下来，可以减少每次的遗漏。如果源库中数据允许加只读账号，也可以同时连接到源和目标，用 DBeaver 等工具窗口分别执行对比脚本，把差异输出到一个表中，节省排查时间。
4. 第 3 步：应用切换、回归测试和回滚预案，这一步决定上线顺不顺
很多人把数据导完就当作迁移完成，结果一接通应用，各种 SQL 报错、分页异常、编码乱码、慢查询全部爆发。应用切换阶段的重点是：先改连接、再跑回归、最后切流量，过程中始终保持可回滚。
4.1 把连接切换到国产数据库，重点检查驱动类、连接串和连接池配置
应用连接层需要切换的内容一般包括：JDBC 驱动包、驱动类名、JDBC URL、账号、密码和配置。项目如果用的是 MyBatis、Hibernate、Spring Data JPA 等框架，数据源信息通常集中在 application.properties 或 application.yml 中。改的时候要格外注意数据库驱动 jar 是否已经打包进应用，如果本地没引入，启动时会在初始化数据源时报 ClassNotFoundException。
连接池参数也需要重新审视。很多应用原本为 Oracle 配置了连接数上限、连接空闲超时、最大等待时间，切换到国产库时不要直接沿用旧值，应根据目标库最大连接数和业务并发量调整。有人会忽略这个问题，上线后发现数据库端连接数打满，应用不断报连接超时，把责任归到数据库，其实参数没调好。
第一次连通应用时，不要直接放全量生产流量。更稳妥的做法是先启动一个只读副本或一两个服务节点，指向国产数据库，观察日志中的 SQL 执行情况。这时如果发现明显方言报错，影响面可控。等应用能正常跑通核心流程后，再逐步把入口请求切过去。
4.2 回归测试要有业务清单，而不是只跑“能打开页面”
回归测试必须覆盖新增、修改、删除、查询、批量导入、定时任务和报表导出。这些场景分别对应不同 SQL 路径，最能暴露方言差异。如果你在页面上只做简单查询，可能完全发现不了存储过程里某个日期格式化函数的兼容问题。
测试过程中建议开启慢 SQL 日志。很多 SQL 在 Oracle 上走了正确索引，切换到国产库后执行计划完全不同，慢查询会非常明显。可以先跑一遍核心页面的响应时间，再做一次并发压测，观察是否存在连接泄漏和死锁。小程序量数据下的功能测试和真实数据量下的性能测试，结果可能差很多。上线前至少要拿核心表全量数据量做一轮查询性能压测。
回归测试时还要关注字符集回显、大字段读写、文件导出等细节。这些场景在发版验收中容易被忽略，但真出问题时影响非常直接。
4.3 回滚预案不是空文档，而是要能一键恢复
任何迁移都要有回滚能力。常见的回滚策略有两种：数据库层面回滚和应用流量回滚。数据库层面回滚，一般在迁移前为目标库做一次完整备份。如果迁移后校验不通过或业务运行异常，可以恢复备份，重新执行修正后的迁移任务。
应用流量回滚更容易实现：入口网关或注册中心保留切换开关，发现国产数据库链路异常时，立刻将流量切回 Oracle 源库链路。虽然长期目标是迁移到国产库，但在过渡期保留源库可用是很正常的生产策略。关键是回滚决策要快，不要等到业务已经开始大量写入后再切，因为那时源库可能已经缺了目标库产生的新数据。
建议在正式上线前做一次完整的切换演练，把回滚步骤真实执行一遍。演练最大的价值是，你会发现很多文档里没写的坑：某个应用节点缓存没清、某个定时任务还连着旧库、某个运维脚本把目标库初始化覆盖了。这些问题在真实切换时出现，会造成长时间业务中断。
5. 迁移后最容易让人误判的问题，建议按这个顺序排查
最后补充几个我在真实迁移项目里见过多次、也容易让人反复踩坑的问题。如果迁移过程中遇到异常，不要急着改目标参数或重新导数据，先按下面这个顺序排查。
5.1 先看日志，再改参数
很多迁移工具会把任务执行状态写入日志或输出面板。当迁移任务报错时，第一步应该打开日志定位是哪张表、哪个字段、哪条 SQL 失败。不要一上来就怀疑是目的地实例配置问题，然后翻手册调整一堆参数。有相当比例的错误是源库账号权限不足、目标库表名冲突、某条数据包含目标库不支持的字符。这些在日志里都有明确记录，看完可以省下大量时间。
5.2 再看对象状态，是否有无效的存储过程
结构迁移完成后，检查目标库中的视图、函数、存储过程等对象状态。如果存在无效对象，多半是因为对象之间依赖顺序不对，或引用了还不存在的表和字段。先把依赖关系理清楚，再重新编译。一个常用的排查方法是按照依赖树从底层对象开始编译，逐层向上解决。
5.3 再看 SQL 行为差异，尤其是空值、排序和日期计算
功能验证阶段遇到“结果不正确”或“排序不对”的问题，优先排查三条：
- 空字符串是否被当作 NULL。
- 日期类型相减后返回的是整数还是天数。
- 分页查询时记录顺序是否稳定。
这三种问题不是结构性问题，但非常影响业务正确性。遇到时间字段对不上、统计汇总差几条、分页翻页时重复或丢失，多数都是这些语义差异导致。不要觉得是迁移工具 bug，也不要全盘否认定目标库能力，先写出最小 SQL 用例，直接在两库执行对比，很快能得到结论。
5.4 最后再评估是改业务 SQL 还是改数据库参数
确定根因后，还要判断解决问题的方式。如果某个 SQL 语法不兼容，优先在业务侧改写，这样能保证应用跨库能力更强。如果某个默认行为差异导致改造成本太高，再评估是否调整实例参数的兼容行为。这里的原则是：业务侧能解决的问题，不要依赖数据库侧全局参数，因为全局参数可能带来其他副作用。
从整体效果看，数据库迁移的难点不在“把数据装进去”，而是在保证对象语义、应用行为和性能表现与迁移前一致。只要按“盘点、迁移、验证”三阶段推进，每一步都能留下明确日志和校验结果，国产数据库替换这件事并没有大多数团队一开始想象的那么可怕。真正常见的问题，也都会在仔细的对象检查和两轮回归测试中暴露出来。
