在数据库国产化迁移过程中，如何在不停止业务的前提下，将Oracle中的存量数据完整、高效地迁移到目标数据库，是每个DBA和架构师面临的核心挑战。本文基于金仓KFS（Kingbase FlySync）数据同步工具，详细介绍三种Oracle源端不停机迁移方案，涵盖适用场景、架构设计、关键步骤及验证方法。
一、方案概览
1.1 迁移核心目标
在数据库迁移项目中，我们追求三大核心目标：
目标 说明
零业务停机 确保在迁移过程中业务不受影响，实现无缝迁移
数据一致性保障 通过多种校验手段确保源端与目标端数据完全一致
TB级数据高效迁移 支持大规模数据的快速迁移，优化迁移效率
1.2 三大方案对比
针对不同的业务场景和数据规模，KFS提供了三种不停机迁移方案：
方案 特点 适用数据量 适用场景
ADG备库迁移 利用ADG主备库分离进行存量数据迁移 TB级以上 Oracle源库已有ADG备库环境
RMAN中间库迁移 通过RMAN物理备份创建中间库，规避ORA-01555 大于1TB 现场可提供中间库服务器
无中间库直连迁移 减少中间环节，直接从源库迁移 1TB以内 快速迁移，无额外服务器资源
1.3 KFS核心作用
KFS在整个迁移过程中扮演着增量数据同步引擎的角色，其核心能力包括：
1.增量日志解析：解析Oracle的Redo/Archive Log，实现增量数据的实时同步。
2.断点续传与一致性同步：基于SCN（System Change Number）的断点续传机制，确保数据迁移的连续性和一致性。即使迁移过程中出现中断，也能从指定SCN位置恢复同步，不会丢失数据。
二、迁移前置条件
2.1 环境要求
在开始迁移之前，必须确保Oracle源库满足以下三个前置条件：
① Oracle版本兼容性
要求Oracle版本为 10g及以上，确保系统兼容性。
② 补全日志启用
需要验证补全日志（Supplemental Logging）已启动，确保迁移过程中数据的完整记录。补全日志分为最小补全日志和主键补全日志，两者均需开启。
③ 归档模式启用
必须启用归档模式（ARCHIVELOG），以保证数据的完整性和可恢复性。归档模式是增量同步的基础，KFS需要通过归档日志来获取增量数据。
2.2 关键配置检查
在正式迁移前，需要进行以下关键配置检查：
检查归档与附加日志是否开启
通过查询 v$database 视图，检查 log_mode、supplemental_log_data_min 和 supplemental_log_data_pk 的状态：
期望结果：
log_mode = ARCHIVELOG
supplemental_log_data_min = YES
supplemental_log_data_pk = YES
如果未开启，可通过以下命令设置。先关闭数据库并启动到 MOUNT 状态：
切换为归档模式：
打开数据库：
开启最小补全日志：
开启主键补全日志：
确认归档日志是否正常生成
检查归档日志是否正常产生，保证数据迁移的连续性和一致性：
或查询归档日志信息：
三、ADG备库迁移方案
3.1 适用场景
ADG备库迁移方案适用于满足以下条件的场景：
✅ Oracle源库有大量存量数据
✅ Oracle源库已有ADG备库环境
✅ 业务不能停机
3.2 架构设计
整体架构如下：
ADG备库迁移架构图
核心思路：利用ADG备库暂停同步的时间窗口，先在暂停窗口内记录主库最小活跃事务SCN（start_scn）与备库当前SCN（current_scn），再通过KDTS工具从备库导出存量数据，最后利用KFS从指定SCN开始增量同步，实现存量与增量的无缝衔接。
3.3 关键步骤
ADG备库迁移方案的关键步骤如下：
Step 1：ADG主备库暂停同步
⚠️ 注意：暂停同步期间，主库的Redo日志会持续累积，需关注归档日志空间是否充足。
Step 2：主库查询最小活跃事务SCN
Step 3：备库获取当前SCN
💡 要点：start_scn 取自主库最小活跃事务的SCN，确保不遗漏任何在途事务；current_scn 取自备库当前SCN，作为存量迁移与增量同步的衔接点。在暂停窗口内先记录好这两个SCN，后续KDTS存量迁移与KFS增量同步均以此为准。
Step 4：KDTS从备库迁移存量数据
使用KDTS工具，从备库 current_scn 导出的存量数据迁移到目标数据库。
Step 5：ADG恢复同步
存量数据迁移完成后，恢复ADG同步：
Step 6：KFS从指定SCN开始增量同步
使用KFS的 fsrepctl 命令，从 start_scn 和 current_scn 开始增量同步：
KFS会解析从 start_scn 到 current_scn 之间的所有Redo/Archive Log，将增量数据同步到目标库。
四、RMAN中间库迁移方案
4.1 核心优势
RMAN中间库迁移方案的核心优势在于：
1.彻底规避ORA-01555错误：RMAN备份数据文件和归档不占用undo表空间，大数据量下也不会产生 ORA-01555 错误。
2.无需指定SCN备份：备份时无需指定SCN，只需在恢复时查询RMAN所备份归档日志的SCN号，即可实现基于SCN的不完全恢复。
3.备份还原速度快：物理备份效率远高于逻辑备份，适合TB级数据。
需要注意的不足：
1.操作相对复杂；
2.只能整库备份还原，不能实现单用户、单表的备份还原。
4.2 适用场景
✅ 数据库有大于1TB的存量数据
✅ 业务不能停机
✅ 现场可以提供中间库服务器
4.3 关键流程
整体流程分为三个阶段：RMAN备份与中间库搭建（迁移存量到中间库）→ KDTS存量迁移 → KFS增量同步。
RMAN中间库迁移架构图
阶段一：RMAN备份与中间库搭建
Step 1：源端查询最小活跃事务SCN（start_scn）
查询源库当前活跃事务的最小起始SCN，作为KFS增量同步的起点。如果查出来有多条，使用SCN号最小的那条：
💡 例如查出的最小start_scn为 12345678901234，后续KFS增量同步命令将用到。
Step 2：源端RMAN全量备份
备份数据库、归档日志、控制文件和spfile（多通道并行，提升备份速度）：
Step 3：备份文件传输到中间库服务器
Step 4：中间库还原spfile文件
若中间库服务器上尚无静态参数文件，执行 startup nomount; 时此处会报错，可先忽略，继续执行还原：
Step 5：生成pfile并修改对应路径
利用spfile生成pfile，编辑pfile修改数据库相关路径（pfile中配置的目录需手工在操作系统上创建）：
Step 6：从pfile重新生成spfile并启动到nomount
先关闭数据库（否则RMAN会进入DUMMY模式），再从pfile重新生成spfile并启动到nomount：
Step 7：还原控制文件并挂载数据库
Step 8：注册备份集到新库的控制文件
如果目标库的备份文件位置与源库的文件位置一致，此步可以忽略；否则需要将备份集注册到控制文件。注册单个备份片使用 catalog backuppiece；注册整个目录使用 CATALOG START WITH（本地目录路径末尾必须加 /）；有多个备份目录时注册多次：
Step 9：确定要还原的SCN
找到最大seq（序列号）归档日志对应的 lowscn，该SCN即为中间库的还原点，同时也是KFS源端解析的 current_scn。
⚠️ 例如查到的最大SCN为 17383296735847，后续 set until scn 与KFS增量同步命令均使用此值。
Step 10：定义数据文件新路径（可选）
如果数据文件路径改变，需要重新定义文件路径。先查找数据文件号与对应数据文件：
再执行 set newname（若中间库与源库的数据文件目录一致，此步可跳过）：
Step 11：恢复数据库（不完全恢复至指定SCN）
其余数据文件与 Step 10 保持一致（set newname 完整列出所有数据文件后执行恢复）：
Step 12：重置日志打开数据库
版本升级处理：如果数据库前后版本不一致，需要重新编译无效对象：
📌 备注：如果不是作为中间库，而是直接迁移到Oracle，在增量同步之前，需要关闭目标库待同步用户的触发器和Job。
阶段二：KDTS存量迁移
使用KDTS工具，将中间库的存量数据迁移至KES目标库（步骤略）。由于中间库的数据是静态的（不完全恢复后不再变化），可以安全地进行全量迁移，无需担心数据一致性。
阶段三：KFS增量同步
① 源端服务启动
💡 命令中第一个SCN（12345678901234）是 Step 1 查到的 start_scn，第二个SCN（17383296735847）是 Step 9 中 list backup of archivelog all 查到的SCN（即 current_scn）。
② 目标端服务启动
💡 关键点：中间库的还原SCN必须与KFS增量同步的 current_scn 保持一致（均为Step 9查到的SCN），start_scn 与 current_scn 严格对齐，才能确保存量数据与增量数据的无缝衔接。
五、无中间库直连迁移方案
无中间库直连迁移方案直接从源库读取数据进行迁移，省去了中间库搭建的环节。整体思路是：KDTS 指定 SCN 迁移存量数据 + KFS 从指定 SCN 开始增量同步，实现存量与增量的无缝衔接。
📖 以下流程参考腾讯文档《oracle无中间库不停机迁移》整理。
无中间库直连迁移流程图
5.1 源库准备（ORA-01555 规避）
KDTS 迁移需要防止出现 ORA-01555 快照太旧 问题。Oracle 需要根据预计迁移时间配置好 undo_retention 和 undo 表空间，并且 undo 表空间需要配置 guarantee，以保证迁移期间 undo 数据不会被覆盖。如果存在 LOB 大字段表，大字段表所在的表空间也需要留有足够的空间。
- undo_retention 和 undo 表空间
(1) 根据预估存量数据迁移时间设置 undo_retention 参数（单位：秒）。先查询当前 undo_retention：
再设置 undo_retention（示例：4小时 = 14400秒）：
(2) 根据 undo_retention 参数和 Oracle 系统统计的每秒需要的撤销块大小，使用下面语句统计需要的 undo 表空间大小。第一步：查询 undo_retention 与 db_block_size 参数：
第二步：统计 UNDO 表空间已用空间（单位：MB）：
需要的 undo 表空间大小 ≈ undo_retention（秒） × 每秒撤销块数 × db_block_size，建议在此基础上再多留 20% 的余量。
(3) 如果表空间不足，使用以下语句扩大 undo 表空间。先查询 undo 表空间数据文件位置：
再为 undo 表空间增加数据文件扩大表空间：
(4) 将 undo 表空间配置为 guarantee，以保证迁移期间 undo 数据不会被覆盖：
⚠️ 重要提示：迁移完成后，需要将 undo 表空间改回 noguarantee：
- LOB 大对象表空间
如果有 LOB 大对象，大对象表所在的表空间需要保留 10% 的剩余空间。
(1) 查询表空间利用率。第一步：查询各表空间总大小（MB）：
第二步：查询各表空间剩余空间（MB）：
以 TMS 表空间为例，利用率 = (total_mb - free_mb) / total_mb × 100%，若剩余空间不足 10% 则需要扩容（通常 UNDOTBS1、SYSAUX、SYSTEM、USER 等系统表空间不在检查范围内）。
(2) 如果 LOB 数据所在表空间剩余空间不足，使用下面语句进行扩容。a. 查看迁移用户的表空间：
b. 查看用户表空间是否是大文件表空间：
c. 如果是大文件表空间，先查询数据文件信息（resize 的数据量要大于上面查的原来的表空间的数据容量）：
再增加表空间大小：
d. 如果是小文件表空间，增加表空间大小：
5.2 KDTS 指定 SCN 迁移存量数据
Step 1：查询当前 SCN 及 start_scn
在源库执行以下 PL/SQL，查询最小活跃事务 SCN（start_scn）和当前 SCN（current_scn）。若使用 SQL*Plus 需先执行 set serveroutput on; 开启输出（PL/SQL Developer 中可省略）：
💡 SCN 含义： - current_scn：Oracle 当前的 SCN。 - start_scn：Oracle 当前 SCN 之前已开始未提交事务的最小 SCN，指定这个 SCN 防止从 current_scn 开始解析会有数据漏解析。
Step 2：KDTS 指定 current_scn 进行数据迁移
使用 KDTS 工具，指定上面查询到的 current_scn 进行存量数据迁移。
5.3 KFS 从指定 SCN 开始增量数据同步
Step 1：安装部署 KFS（略，参考《KFS安装部署手册》）
Step 2：启动 KFS 到 offline 状态
Step 3：KFS 服务进行重置，先源端后目标端
Step 4：源端服务从指定 SCN 开始解析
指定 SCN 就是上面 KDTS 步骤查到的 current_scn 和 start_scn：
💡 要点： - current_scn：Oracle 当前的 SCN； - start_scn：Oracle 当前 SCN 之前已开始未提交事务的最小 SCN，指定这个 SCN 防止从 current_scn 开始解析会有数据漏解析； - 源端解析可以与 KDTS 存量数据迁移同时进行。
Step 5：目标端服务 online
目标端服务需要等 KDTS 存量数据迁移完成后才能 online：
⚠️ 注意：目标端必须在 KDTS 存量数据迁移完成后再启动，避免存量数据与增量数据冲突。
六、迁移验证方案
迁移完成后，数据一致性验证是确保迁移质量的关键环节。KFS提供四种验证方式，可组合使用：
验证方式 说明 适用场景
精简比对 只比对两边表数据量的差异 快速验证，发现明显数据缺失
详细比对 比对表详细数据的差异 精确验证每条记录的一致性
增量比对 比对指定时间点之后的增量数据差异 验证增量同步的准确性
不停机比对 业务不停机情况下进行数据比对并修复 生产环境持续验证
建议验证流程：
1.先精简比对：快速定位数据量差异较大的表。
2.再详细比对：对差异表进行逐条数据比对。
3.增量比对：验证增量同步链路的正确性。
4.不停机比对：在业务持续运行期间，进行最终的一致性确认。
七、总结
三种方案选型决策树
三种方案选型决策树
各方案核心要点回顾
方案 核心原理 优势 注意事项
ADG备库迁移 利用ADG备库暂停窗口导出存量 无需额外服务器，利用现有环境 需有ADG备库；暂停期间需关注归档空间
RMAN中间库迁移 RMAN不完全恢复创建中间库 彻底规避ORA-01555；无需指定SCN备份；备份还原快；中间库数据静态可安全迁移 需额外中间库服务器；只能整库备份还原、操作复杂；还原SCN须与KFS的current_scn精确对齐
无中间库直连迁移 KDTS指定SCN迁移存量 + KFS从指定SCN增量同步 架构简单，减少中间环节，无额外服务器 需配置undo_retention/guarantee规避ORA-01555；LOB表空间预留10%余量；适合1TB以内数据
迁移通用原则
无论选择哪种方案，都需要遵循以下通用原则：
1.SCN对齐：存量迁移的SCN与增量同步的起始SCN必须严格对齐，这是数据一致性的基石。
2.增量日志保留：从存量迁移开始到KFS增量同步启动期间，Oracle的归档日志必须保留完整，不能被清理。
3.充分验证：迁移完成后，务必通过精简比对 → 详细比对 → 增量比对的流程，确保数据完全一致。
4.回滚预案：迁移前制定详细的回滚预案，确保在出现问题时能够快速回退。
本文总结：Oracle不停机迁移的核心思路是"存量迁移 + 增量同步"的组合拳。通过KDTS完成存量数据的批量迁移，利用KFS基于SCN的断点续传能力衔接增量数据，最终实现业务零感知的数据迁移。根据数据规模和环境条件选择合适的方案，是迁移成功的关键。
参考资料：金仓KFS（Kingbase FlySync）Oracle源端不停机迁移方案
