企业官网建设流程全解析

先说一个经历。几年前我第一次听到“国产数据库迁移”，第一反应是“又要改一堆SQL、又要处理字段类型映射、又要担心数据丢不丢”，心里多少有点打鼓。后来实际走完一套从 Oracle 到达梦数据库的迁移流程，发现只要把工作拆成“评估、迁移、校验”三个阶段，并且把每一阶段要做的事情提前列清楚，整个过程并没有想象中那么可怕，反而是一套可以复制、可以量化进度的方法。本文就把这套思路完整分享出来，重点围绕“Oracle 迁移到达梦数据库”的场景展开，也适合其他主流数据库向国产数据库迁移的参考。

阅读本文，你可以掌握：国产数据库迁移前需要盘点哪些信息；如何选择全量迁移还是增量同步；三步迁移法的具体执行细节；如何用 DBeaver、官方迁移工具、手写脚本做迁移和校验；以及迁移过程中最常见的问题和最实用的工程建议。如果你是后端开发、DBA 或者项目技术负责人，正在评估国产数据库落地，这篇文章可以帮你少走不少弯路。

1. 背景与核心概念：为什么很多人觉得国产数据库迁移难

1.1 国产数据库迁移到底在迁移什么

数据库迁移，不只是“把数据从一个库复制到另一个库”，它至少包含三部分内容：

• 结构对象迁移：表、视图、序列、索引、主外键、约束、存储过程、触发器、函数、包。
• 数据迁移：存量数据按目标库支持的方式写入，并保证数据一致。
• 应用适配：修改连接配置、SQL 方言、事务控制、分页语句、日期函数等。

从结构对象到数据再到业务调用，任何一环没跟上，都会让系统在新库上跑不起来或者跑起来结果不对。这也是“国产数据库迁移难”说法的主要来源：很多人只做了数据复制，忽略了语法差异和业务 SQL 兼容性，最后在测试阶段被各种报错淹没。

常见的国产数据库包括达梦 DM、人大金仓 KingbaseES、openGauss 系、OceanBase、TiDB 等。网上常说的“国产数据库排名前十名”在不同报告里口径差异很大，有些看社区活跃度，有些看信创落地案例，有些看商业营收。选型时不必把排名当作唯一依据，重点看团队熟悉度、与原库的兼容性、运维生态和许可证成本。

1.2 数据库迁移的常见误区

误区一：认为“能连上目标库、能把数据导过去”就算迁移完成。实际上，如果目标库表结构设计不合理，或者应用里仍存在大量源库私有语法，上线后随时可能炸出问题。

误区二：认为一次大版本或跨品牌迁移可以完全依赖某个工具一键完成。工具能处理常规表结构和数据，但对于特殊类型、正则函数、存储过程、递归查询等复杂对象，往往仍然需要人工介入。

误区三：忽视字符集和大小写敏感性。源库和目标库如果字符集不一致，中文乱码几乎是必然事件；如果目标库开启了大小写敏感配置，未加引号的表名、字段名可能会产生“表或视图不存在”的经典报错。

1.3 不同迁移场景的区分

在实际规划中，需要先区分“同构迁移”和“异构迁移”：

• Oracle 11g 到 Oracle 12c/19c，属于同构迁移，常见做法有物理 DataGuard、RMAN 恢复、expdp/impdp，全程相对平滑。
• Oracle 到达梦数据库，属于异构迁移，需要把 Oracle 兼容的 DDL/DML 转换为目标库能接受的写法。
• MySQL 到国产数据库同理，要处理反引号、自增列、engine=InnoDB后缀、ON DUPLICATE KEY UPDATE等语法差异。

对应到迁移窗口，又可以分为“停机全量迁移”和“增量同步迁移”。

很多同学在搜索引擎里找“Oracle 11g 数据库怎么冷迁移”。如果你问的是 Oracle 到 Oracle，冷迁移通常指停库后做文件级复制或逻辑导出再恢复；如果目标是达梦这类国产库，那本质上已经不是冷迁移，而是“离线逻辑迁移”，也就是把源库停掉或让业务暂停写入，然后通过逻辑导出/迁移工具把结构、数据搬过去。对于业务允许停机、数据量不大、并发要求不高的系统，这种离线全量迁移是性价比很高的方案；如果业务不允许长时间停机，则需要同步工具先做全量，再拉取归档日志或使用 CDC 机制做增量追平。

2. 迁移前的准备：先盘点存量，再谈方案

2.1 盘点源库基本信息

我曾经看过一些团队，迁移方案都写好了，到了现场才发现源库字符集是ZHS16GBK，业务表有几百张 CLOB，还有大量含START WITH ... CONNECT BY的递归查询。这些都是影响工作量的关键因素。

因此，第一步永远是盘点存量信息。以 Oracle 为例，至少需要收集：

查询 Oracle 当前用户下的对象数量，可以用类似下面的 SQL：

SELECT object_type, COUNT(*) FROM user_objects GROUP BY object_type ORDER BY COUNT(*) DESC;

这里补充一句：目标国产库通常也提供兼容 Oracle 的字典视图，但不建议把所有细节都寄托在单一工具上。很多数据字典查询SQL，虽然两边都有，但具体字段和返回格式会有差异。最好在源库查完之后，导出一份对象清单，作为后续核对目标库的依据。

2.2 确定目标库和兼容模式

每种国产数据库对 Oracle 的兼容程度不同。以达梦数据库为例，它提供了兼容模式相关配置，在 Oracle 兼容模式下，很多 Oracle 数据类型如VARCHAR2、NUMBER，以及SYSDATE、DECODE等函数都可以直接识别。这能大幅减少脚本改写量。

需要留意的是：兼容模式并不是银弹。VARCHAR2能建出来，不代表内部行为完全一致；SYSDATE能用，不代表复杂的 PL/SQL 匿名块都能无缝执行。把目标库安装在测试环境之后，一定要用真实的源库 DDL 做一轮试跑，以实际报错为准。

2.3 工具选型：官方迁移工具、DBeaver、脚本

先说一个比较反直觉的观点：工具不在多，而在于知道什么场景用什么工具。

这里特别说一下 DBeaver。网上经常有人问“DBeaver 如何进行数据库迁移”，因为 DBeaver 是一款很流行的通用数据库客户端，能同时连接 Oracle、达梦、MySQL 等多种数据源。它的定位更像“数据库工作台”，适合做以下事情：

• 在一个界面里分别连接源库和目标库，直观查看表、视图、序列等对象。
• 查询小表数据，对比表行数。
• 将查询结果导出为 CSV、SQL 等格式。
• 手工执行建表语句和修正 SQL。

但要注意，不要把 DBeaver 当作专业的异构迁移工具。跨品牌迁移时，它的 DDL 转换能力有限，也不会像专业迁移工具那样自动做对象依赖排序和错误重试。表少、字段简单时可以“连库拖数据”；表多、关系复杂时，还是优先用目标厂商自带的迁移工具。

如果是 Java 项目从 MySQL/Oracle 迁移到达梦，还需要提前确认 JDBC 驱动包和连接参数。达梦 JDBC 的驱动类和连接 URL 会随版本变化，典型的写法形如：

spring.datasource.driver-class-name=dm.jdbc.driver.DmDriver spring.datasource.url=jdbc:dm://192.168.1.20:5236?schema=TEST spring.datasource.username=TEST_USER spring.datasource.password=your_password

注意：不同版本驱动类名可能不变，但 URL 参数格式以官方文档为准。生产环境不要直接用系统管理员账号，应在目标库中创建业务专用账号并授予最小权限。

2.4 迁移窗口与回退预案

迁移方案里最容易被忽略的是回退预案。这里的回退不是说“万一失败了再导一次”，而是明确回答三个问题：

• 迁移过程中源库是否还允许写入？
• 如果目标库数据校验不通过，源库要不要继续对外服务？
• 回退时是否需要恢复源库到某个时间点？

生产环境切换前，建议给源库做一次完整备份或至少导出最近可用的逻辑备份，并且把备份文件存放在独立位置。涉及生产环境变更，必须提前申请维护窗口，并且先在小数据量的测试环境演练完整流程，不要在正式环境边试边改。

3. 三步迁移法：评估、迁移、校验

把迁移过程压缩成可执行的三个步骤，并不是为了简化问题，而是给整个团队一个统一的工作节奏：先摸清家底，再做迁移动作，最后用数据和业务验证结果。下面分别展开。

3.1 第一步：对象与 SQL 兼容性评估

评估阶段的核心产出是一份“风险清单”，而不是迁移脚本。风险清单至少包括：

• 对象数量清单：需要迁移哪些表、字段、约束、索引。
• DDL 兼容性清单：哪些建表语句可以直接在目标库执行，哪些需要改写。
• SQL 语法风险点：业务代码中的NVL、DECODE、ROWNUM、CONNECT BY、SYSDATE、TO_DATE等使用情况。
• 数据风险点：大表数量、CLOB/BLOB 字段、字符集差异、可能引起乱码的对象。

实际操作中，可以先让官方迁移工具或 DBeaver 分别读取源库和目标库，把源库的表结构脚本导出。例如下面的 Oracle 建表脚本：

-- Oracle 源表结构（示例） CREATE TABLE t_order ( order_id NUMBER(12) NOT NULL, order_no VARCHAR2(32) NOT NULL, amount NUMBER(10,2) DEFAULT 0 NOT NULL, status NUMBER(1) DEFAULT 1, create_time DATE DEFAULT SYSDATE, remark VARCHAR2(500), CONSTRAINT pk_t_order PRIMARY KEY (order_id) );

如果目标库处于 Oracle 兼容模式，这段脚本可能直接创建成功；如果目标库是更严格的通用模式，可能需要改写成：

-- 目标库建表脚本（通用模式改写示例） CREATE TABLE t_order ( order_id NUMERIC(12) NOT NULL, order_no VARCHAR(32) NOT NULL, amount NUMERIC(10,2) DEFAULT 0 NOT NULL, status NUMERIC(1) DEFAULT 1, create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, remark VARCHAR(500), CONSTRAINT pk_t_order PRIMARY KEY (order_id) );

这个例子只是想说明一个原则：不要拿着一份源库 DDL 无脑执行，要先在测试库试跑。官方迁移工具能生成目标库可执行的初步脚本，人工只需要集中精力处理失败项，这样效率更高。

3.2 第二步：结构迁移与数据迁移

评估完之后，进入正式迁移。为了避免“先导数据后建约束”导致外键校验失败，一般推荐顺序是：

1. 先创建用户、表空间等基础环境。
2. 迁移表结构，先建父表，再建子表。
3. 迁移序列和自增设置，确保新插入主键不会与已有数据冲突。
4. 迁移索引，但大表上的索引可以等数据导入完成后再重建。
5. 迁移数据，子表数据在父表数据之后导入。
6. 迁移视图、函数、存储过程、触发器，并逐项编译。
7. 最后创建外键约束和补充检查。

如果是大表，建议按主键范围或时间条件分批读取。下面是一个 Python 思路的骨架，核心是“源库游标读一批，目标库批量写一批”，避免一次性加载全部数据导致内存溢出。示例代码不代表现成可跑的生产脚本，需要按实际表和驱动调整。

# 引入源库和目标库的 Python 驱动 # 例如：pip install oracledb dmPython import oracledb import dmPython # 连接参数需要替换成实际环境 src = oracledb.connect(user="scott", password="password", dsn="192.168.1.10:1521/orcl") dst = dmPython.connect(user="TEST_USER", password="password", server="192.168.1.20", port=5236) table_name = "t_order" start_id = 0 batch_size = 10000 with src.cursor() as cur_src, dst.cursor() as cur_dst: while True: # 每次按主键范围取一批 cur_src.execute( "SELECT * FROM t_order WHERE order_id > :a AND order_id <= :b " "ORDER BY order_id", a=start_id, b=start_id + batch_size ) rows = cur_src.fetchall() if not rows: break # 列名和占位符需要根据表结构调整 cols = ["ORDER_ID", "ORDER_NO", "AMOUNT", "STATUS", "CREATE_TIME", "REMARK"] placeholders = ",".join(["?"] * len(cols)) insert_sql = ( f"INSERT INTO {table_name} " f"({','.join(cols)}) VALUES ({placeholders})" ) cur_dst.executemany(insert_sql, rows) dst.commit() start_id += batch_size print(f"已完成到 order_id={start_id}") src.close() dst.close()

这里有几个需要注意的点：

• NUMBER在 Python 读取后可能被转成Decimal或float，写入目标库时要注意精度。
• 目标库如果开启了大小写敏感，不带引号的表名、列名经常被统一转为大写，示例中列名写成大写可以省掉很多引号麻烦。
• 如果某张表没有主键或唯一键，分页式读取就不是好主意，可以改用ROWID分片或游标批量提取。

对于数据量特别大的表，官方迁移工具通常比自写脚本更稳妥，因为它内置并行、断点续传、日志记录等能力。脚本方案更适合用来补偿工具覆盖不到的特殊表。

3.3 第三步：应用适配与一致性校验

数据导完后，最重要的工作是应用适配与校验。这个阶段往往占整个迁移周期的一半以上。

应用适配主要分两类：

第一类是连接层适配。比如 Spring Boot 项目要替换驱动、连接 URL、数据库方言等。很多使用若依这类快速开发平台的项目，在国产化适配时会遇到初始化脚本直接执行报错的问题。原因通常是 SQL 脚本本身含有源数据库特有的语法，例如若依默认初始化脚本里常见的datetime默认值、sysdate、MySQL 反引号等。正确做法不是直接在业务库执行原始脚本，而是先梳理脚本中使用的方言特性，再做兼容改写。若依平台本身的核心业务表结构并不复杂，真正麻烦的是把菜单 SQL、初始管理员数据、部门数据一次执行成功，所以建议在测试库先跑初始化脚本，哪里报错改哪里，不要在生产环境试错。

第二类是 SQL 方言适配。举个例子，很多老项目会把 Oracle 的DECODE写得满天飞。Oracle 兼容模式下达梦能识别该函数，但如果团队希望长期维护低成本，建议逐步改成标准的CASE WHEN。再比如分页写法，Oracle 经典分页依赖ROWNUM，兼容模式下仍可以识别，但更推荐改成标准窗口函数：

-- 改写前的 Oracle 风格 SELECT * FROM ( SELECT t.*, ROWNUM rn FROM t_order t WHERE status = 1 ) WHERE rn > 0 AND rn <= 20; -- 可跨库的窗口函数风格 SELECT * FROM ( SELECT t.*, ROW_NUMBER() OVER (ORDER BY order_id) rn FROM t_order t WHERE status = 1 ) WHERE rn > 0 AND rn <= 20;

数据一致性校验不是只比一张表的行数，而是至少做三层比对：

• 行数比对：每张表执行COUNT(*)，源库和目标库结果一致。
• 关键字段比对：抽样比对主键、金额、状态、时间等核心字段。
• 业务逻辑比对：跑几组核心业务接口，验证查询结果、报表统计、批量任务是否和源库一致。

源库侧可以先构造一张“各表行数清单”：

-- Oracle 源库行数统计示例（单表少时可以手工执行） SELECT 't_order' AS table_name, COUNT(*) AS cnt FROM t_order UNION ALL SELECT 't_user', COUNT(*) FROM t_user;

目标库执行同样的 SQL，然后用文本对比工具比对两份输出，能快速发现差异表。

4. 一次 Oracle 到达梦的迁移实战拆解

为了让上面的三步法更有体感，下面用一个模拟场景演示整体流程。

假设某内部系统使用 Oracle 11g，核心表有t_order、t_user、t_order_item，业务应用是 Spring Boot + MyBatis，当前数据库连接配置指向 Oracle。现在计划迁移到达梦数据库，业务允许停机 4 小时。

4.1 迁移前整理对象清单

在源库执行：

-- 查看当前用户下所有表名 SELECT table_name FROM user_tables ORDER BY table_name; -- 查看表字段信息（这里只取常用信息） SELECT table_name, column_name, data_type, data_length, nullable FROM user_tab_columns WHERE table_name IN ('T_ORDER', 'T_USER', 'T_ORDER_ITEM') ORDER BY table_name, column_id;

把表结构导出后进行改写，并提前确定以下映射关系：

4.2 用官方迁移工具做存量数据迁移

这一阶段不做人工 INSERT，而是使用目标库官方迁移工具连接 Oracle 源库和达梦目标库，选择要迁移的 Schema 或表，执行“结构 + 数据”的迁移任务。过程中建议：

• 先只迁移 3 张核心表，观察数据量、速度、日志。
• 确认无误后再迁移其余表。
• 迁移完成后，让工具生成一份报告，重点看失败对象和跳过对象。

如果你的环境没有官方迁移工具，也可以先使用 DBeaver 对表结构做可视化检查。用 DBeaver 分别建立 Oracle 和达梦连接后，可以查看每张表的字段、索引、约束，并导出部分数据做抽样。需要注意，DBeaver 导出的 SQL 脚本在不同数据库间仍然存在方言问题，不能保证在目标库直接执行成功。

4.3 MyBatis Mapper 兼容改写

数据库切换后，最常见的问题不在建表，而在 MyBatis 的 XML Mapper 里。比如下面这个查询本身是跨库友好的：

<!-- 文件路径：src/main/resources/mapper/TOrderMapper.xml --> <select id="selectValidOrders" resultType="map"> SELECT order_id, order_no, amount, create_time FROM t_order WHERE status = #{status} ORDER BY order_id </select>

这段 SQL 没有NVL、没有ROWNUM、没有TO_DATE简写，Oracle 和达梦都认识。但很多老项目会写出这样的句子：

<select id="selectByCondition" resultType="map"> SELECT * FROM ( SELECT t.*, ROWNUM rn FROM t_order t WHERE t.status = #{status} ORDER BY t.create_time DESC ) WHERE rn &gt; #{offset} AND rn &lt;= #{limit} </select>

这段 SQL 使用ROWNUM做分页，如果目标库兼容模式能运行，可以暂时保留；但从可维护性角度，建议改成通用窗口函数写法。改造时尤其要注意 XML 转义，>要写成>，<写成<，否则 XML 解析阶段就会报错。

4.4 切换数据源并验证

应用侧把application.properties中的连接配置改为目标库：

spring.datasource.driver-class-name=dm.jdbc.driver.DmDriver spring.datasource.url=jdbc:dm://127.0.0.1:5236?schema=TEST spring.datasource.username=TEST_USER spring.datasource.password=xxxxxx

然后启动应用，按下面的顺序验证：

1. 登录是否成功。
2. 基础查询接口是否返回数据。
3. 带分页、带排序的列表接口是否正常。
4. 事务写入接口是否成功，包括插入、更新、删除。
5. 定时任务和后台批处理是否正常。
6. 报表统计 SQL 是否和源库结果一致。

不建议直接切生产库验证，先切到影子环境或预发环境把功能用例和对比 SQL 全部跑一遍。

5. 常见问题与排查思路

以下问题来自国产数据库迁移项目的高频踩坑点，按“现象、原因、思路”整理成表。

针对乱码问题，最理想的处理是从源头统一字符集。Oracle 侧常见字符集有ZHS16GBK、AL32UTF8，达梦创建实例时也会设置字符集。如果条件允许，尽量让目标库使用与源库一致的字符集，或者在导出时统一转换为 UTF-8，并保持应用连接参数也使用 UTF-8。

在排查问题上还有一点值得提醒：不要对着一张报错日志原地硬猜。遇到任何报错，先记录发生的场景、执行的 SQL、目标库版本、兼容模式配置，然后在测试环境用最小 SQL 复现。能复现的问题，基本都能定位。

6. 最佳实践与工程建议

6.1 先跑通一个边缘系统，再推广到核心系统

公司内部如果有很多套系统，不建议一上来就迁最核心的账务系统。先选一个边界清晰、数据量不大、业务影响范围有限的系统完整走一遍流程。这样团队可以积累一套自己的经验清单：哪些 DDL 会报错、哪些工具需要参数调整、哪些 SQL 容易踩坑、目标库参数怎么设置。等流程跑顺了，再迁移核心系统时有据可查。

6.2 建立“数据字典映射文档”

迁移过程中产生的类型映射、函数改写、SQL 替换规则，不要只存在个人笔记里。建议维护一份类似下面结构的映射文档：

这份文档既是迁移进度的跟踪表，也是后续其他系统迁移的培训材料。看见风险点提前处理，远比在测试阶段被报错推着走要高效。

6.3 坚持最小权限和账号隔离

迁移数据时不要使用目标库的系统管理员账号执行业务 SQL。DBA 可以先用管理员账号创建业务用户、表空间和基础环境，然后把导入和校验工作交给业务专用账号。业务账号只应拥有操作业务 Schema 的权限。数据库账号和密码要纳入配置管理，不能硬编码在代码仓库里。

6.4 大表操作注意锁和回滚段

如果目标库导入期间无法停业务，可能出现锁等待或回滚段膨胀。建议分批提交，避免一个超长事务运行几个小时。导入大表前，可以和外键约束、索引的创建顺序结合考虑：先导数据，再建索引和外键，能显著减少每行插入时的额外校验成本。分批提交也要考虑异常中断后的恢复点，最好记录每个分片的完成状态，这样失败后不需要从头开始。

6.5 校验脚本应纳入自动化

只用眼睛看几条数据是不够的。建议把行数比对和关键字段抽样比对写成脚本，至少能在迁移完成后自动跑一遍，并输出差异报告。如果团队有 Jenkins 或定时任务平台，可以把校验脚本做成一个可重复执行的任务，后续在并行运行阶段持续监控两边数据差异。

6.6 切换前准备回退方案

生产切换前，必须和业务方确认回退条件和联系人。目标库数据导入完成后，仍然保留源库对外只读或备份状态，直到核心业务在目标库运行稳定。万一发生不可恢复的数据问题，优先选择回退到源库，而不是在目标库继续修补。回退不是“士气低落”的表现，而是一个正式工程应有的安全阀。

7. 总结与后续实践

回到最初那句话：国产数据库迁移并非想象中难，但它确实不是“复制粘贴”就能完成的轻松任务。把整个工作拆成评估、迁移、校验三步，并且每一步都有清晰的交付物，项目的可掌控程度就会高很多。

本文分享的关键经验可以浓缩为以下几条，适合在项目启动前贴在团队共享文档里：

• 迁移方案要包含结构、数据、应用三层，不能只盯着 INSERT。
• 优先使用目标库官方迁移工具，DBeaver 和自写脚本定位是辅助与补漏。
• 先建结构、再导数据、后建约束索引，可以降低大量报错。
• 字符集、大小写、序列、ROWNUM、NVL、DECODE是异构迁移的高频风险点。
• 数据一致性必须用行数、抽样字段和业务功能三层校验。
• 任何生产变更前要备份源库，准备好回退方案，并在测试环境反复演练。

如果你们团队接下来刚好有国产数据库选型或数据库迁移需求，建议先拿一个非核心系统跑一次完整流程，把遇到的每一个报错都记录到兼容性清单里。第一批问题解决完以后，你会发现后续系统的迁移速度会快很多，因为大部分坑已经在测试环境中提前探明，真正困难的部分往往不是数据库本身，而是业务代码里那些年久失修的“方言”写法。希望这篇文章能成为你们迁移工作的一份实用参考。