本文作者： 张显华，孟凡辉，庄培培

系列导读：徐戟（白鳝）数据库技术专家，Oracle ACE，PostgreSQL ACE Director

当前，国内大量的关键行业的核心系统正在实现国产化替代，而与此同时，这些行业的数字化转型也正在进入深水区。在信息系统的升级换代过程中，夯实 IT 基础设施是极其关键的。从服务器、操作系统、中间件、数据库等基础软硬件选型到系统架构、应用架构的重新设计，再到数据迁移、系统迁移、系统优化、运维体系重构的一系列工作都是十分具有挑战性的。大多数工作中，都会遇到无法完全参考前人的探索和创新。

一些勇敢的先行者已经在这条荆棘丛生的道路上硬生生的创出了一条血路，而更多的人还在未知与迷茫中摸索。 “银⾏核⼼背后的落地⼯程体系”系列技术文章来自于金融行业用户真实故事，从中可以窥见的不仅是国产化替代路上的艰辛历程，更多的是对于后来者极其宝贵的实践经验。

在本系列文章中你不仅可以看到 TiDB 与 Oracle 的异构迁移、基于 TiCDC 的逻辑容灾与数据共享、构建双活数据中心的真实案例，还可以了解到混沌测试、应急预案等方面，以及利用数据库可观测性构建智能化、自动化运维体系的方案与技巧。“ 积小流，成江海 ”，希望这些案例能够对您有所裨益。

银行核心业务的数据迁移是一项既复杂又需细致操作的任务，涉及全面规划和精确执行多个关键要素。本文以某城市商业银行核心系统的数据迁移为例，详细阐述从 Oracle 到 TiDB 的迁移方案设计和具体实施步骤。

银行核心数据迁移四要素

银行核心的数据迁移，迁移时间的控制及数据准确性至关重要，为了确保数据迁移的成功，需要综合考虑迁移逻辑、数据一致性、迁移性能和回退方案这四个核心要素。

• 迁移逻辑

在迁移逻辑的设计上，首要任务是确保数据迁移的实时性和准确性。我们需要评估现有系统是否支持实时同步，并设计相应的同步机制以保证数据的实时更新。同时，对于表结构和数据模型的迁移，应制定详细的转换策略，确保数据在迁移过程中的完整性和一致性。此外，数据兜底方案和技术支持也是不可或缺的，它们为数据迁移提供了坚实的保障，确保在任何情况下数据的安全性和可靠性。

• 数据一致性

数据一致性是银行业务数据迁移中的核心问题。特别是在涉及银行核心账务系统时，每一笔交易数据、每一行记录都必须保证绝对准确。为此，我们需要制定严格的数据校验流程和一致性检查机制，确保迁移后的数据与源数据完全匹配。同时，针对可能出现的字符集不匹配问题，如从 Oracle 的 16GBK 迁移到 TiDB 的 UTF8MB4，应提前规划字符集转换方案，确保数据在迁移过程中的准确性和一致性。

• 迁移性能

迁移性能是影响数据迁移效率的关键因素。我们需要评估迁移窗口时间是否充足，以及迁移过程中涉及的表结构调整、数据模型转换等操作是否高效。此外，选择合适的数据迁移工具，并确保其具备良好的自动化能力和支持分批、分组迁移的功能，将有助于提升迁移效率。

• 回退方案

在迁移过程中，还应考虑可能出现的意外情况，并制定相应的回退方案，以便在遇到问题时能够迅速恢复到迁移前的状态。

迁移逻辑

2.1 迁移需求和挑战

• 银行账务核心涉及的表多且数据量大。

• 字符集转换，Oracle 的 ZHS16GBK 到 TiDB 的 UTF8MB4 的转换。

• 数据移形，表结构和数据的移形，表结构发生变化，老数据基于新的业务规则转换为新的业务数据。

• 全程脚本化，数据要保证前后一致。

• 迁移窗口总时间 2 小时内 (数据移形 + 数据迁移 + 数据检核)。

2.2 迁移方案设计

在制定数据迁移策略时，我们必须考虑到源系统和目标系统之间表结构的差异，以及数据在迁移过程中可能需要的逻辑转换。在评估的多个方案中，第一个实时同步的方案由于缺乏必要的数据移形能力，未能满足要求，因此被排除。第二个方案，即通过将 Oracle 中的数据导出为 CSV 格式，再导入到 TiDB 的方案，不仅在迁移工具的选择、字符集的转换、数据一致性的保障上满足了要求，而且在窗口时间内也能顺利完成迁移任务。

初步评估下来，方案二在技术上是可行的，但仍需深入探讨其实施的细节。特别是在数据从 Oracle 迁移至 CSV 的过程中，借助 Oracle 生态系统内使用较好的导出工具来实现，但此过程还涉及到从老核心数据库到中转机的 Oracle 数据库的数据迁移以及平台因素等方面的考虑。

2.3 引入中转机的技术考量

引入中转机的原因，首先老核心系统除了包含存，贷，公共及核算等核心业务模块之外，还涵盖了其他多种业务模块，是典型的传统胖核心模式。避免对原有数据库的影响及回退的考虑，直接在老核心系统上进行建表、数据迁移和转换等操作是不可行的。因此需要设置一个中转机，作为临时的中间库，完成必要的数据转换和迁移工作。中转机的引入不仅解决了数据迁移的技术难题，还为整个迁移过程提供了灵活性和安全性。在迁移过程中，老核心数据库本身保持不变，仅需要更改业务访问的地址，即可实现平滑过渡。

中转机的引入不仅为数据迁移过程中可能出现的问题提供了有效的回退机制，而且在技术层面上，它还起到了关键的兜底作用。在整个数据迁移的链路中，主要采用了 Lightning、O2T Sync-diff 以及 Oracle 导出工具 这三款工具，工具平台适配问题通过引入中转机也很好的被解决。三款工具，Lightning 和 O2T Sync-diff 是由 TiDB 官方提供的数据迁移工具，官方提供技术支持及技术兜底；为了确保迁移过程的稳定性和兼容性，在实际使用 Oracle 生态的导出工具时，主要使用工具的基本功能实现 Oracle 数据导出为 CSV 文件，尽量减少对导出工具高级特性的使用。

2.4 表结构和数据的移形

结构和数据的移形涉及表结构和数据两个部分，移形的方式大概分为四大类。

• 平移和新增

平移指表结构在迁移过程中保持不变，即字段的数量和定义均与原数据库一致，没有发生任何结构性或逻辑性的改变。在这种情况下，表的结构和数据可以无缝地迁移到新的数据库环境中。新增指的是在目标数据库中创建全新的表结构，而这些表在源数据库中并不存在。在数据割接和投产后，新数据将被插入到这些新创建的表中。

• 平移重构

相较于简单的平移，会涉及到一些细微的结构调整。例如，可能会在表中新增一个时间戳字段，以便记录数据的最后更新时间。这些简单的转换可以通过编写通用的程序脚本来完成，通过执行类似 Oracle 数据库中的“INSERT SELECT”语句来完成的，没有复杂的逻辑在里面。

• 轻度重构

通常涉及到对原有数据结构的调整，比如将老核心系统中的两张表合并成一张新表，或者对表进行分拆。这样的操作可能还会包括对字段内容的填充或修改，需要借助存储过程来进行改造。

• 完全重构

适用于当数据结构和业务逻辑发生显著变化时。在完全重构的场景下，原有的数据结构和业务流程往往经历了根本性的改造，这意味着大部分甚至所有的原有数据和逻辑都需要按照新的业务需求和数据模型来重新设计和构建。

大部分数据可以通过前述的四种方法顺利迁移到新的数据库系统中，但总会有一些数据因其业务逻辑的复杂性而难以通过简单的转换程序来处理。这部分数据在割接当天通过初始化批的方式去完成，以确保数据的时效性和准确性。

以某城市商业银行核心系统升级项目为例，我们采用了前述的五种数据迁移策略。在这个项目中，需要进行重构的数据占据了总量的近一半，这表明了项目的技术复杂性和挑战性。在项目实施的关键时刻，即投产前一个月，业务逻辑的持续变化为数据迁移的顺利执行带来了巨大的挑战。

下图是数据移形的全流程示意图，老核心 Oracle 数据库中的数据有平移数据和转换数据，还有一部分数据与新核心无关，无需迁移。

• 表结构迁移

Oracle 中间库的表结构和目标 TiDB 侧的表结构通过 DAP 平台（微服务开发平台）统一生成两份建表脚本。通过在两个不同的数据库环境中执行相同的建表语句，确保了表结构的一致性和数据迁移的准确性。

• 转换数据迁移

平移数据和转换数据首先通过专门的导出和导入工具迁移到我们的中间库——一个运行在 X86 环境下的 Oracle 数据库。中间库的作用是进行数据的预处理和转换工作。这些处理步骤通过存储过程来实现的，开发团队对所有迁移表进行了详细的梳理，并针对每张表制定了具体的转换前后业务逻辑。在中间库中，数据被清晰地分为三个部分：转换前的数据、转换后数据以及不需要进一步处理的平移数据。

• 初始化数据

这部分数据在系统割接当天，通过触发批处理作业的方式将数据导入到新的环境中，从而实现表结构和数据的整体迁移。

迁移性能

在讨论数据迁移的性能问题时，行方设定的整体时间窗口为两小时。这一时间限制涵盖了如下三个迁移过程：

• 老核心 Oracle 到中转机 Oracle 的数据迁移(O2O)

• 中间库中的数据转换(Convert)

• 转换后的数据迁移到 TiDB (O2T)

为了在 2 小时这一严格的时间框架内完成迁移，我们对整个迁移流程进行了细致的分阶段处理和细粒度的拆解。通过这种方式，我们能够更精确地识别每个阶段的耗时点，并针对性地进行性能优化。

3.1 O2O 迁移优化

在数据迁移的第一阶段，我们面临着 Oracle 数据库从 AIX 环境迁移数据到中间库的挑战。最初考虑的方案是利用行里面已有的存储复制技术来快速创建数据的镜像，但生成的镜像仍然位于 AIX 平台上，无法直接迁移到 Linux 平台。过程中我们还遇到了硬件方面的挑战，由于中转机使用的是较老的 AIX 硬件，我们需要额外准备性能更强大的 AIX 机器，这大大增加了项目的成本。在使用较老 AIX 硬件的初步尝试中，发现硬件性能存在明显的不足，尤其在进行数据比对时，与基于 X86 架构的系统相比，性能差距显著。

将数据迁移的中转机采用 X86 平台，实现从 AIX 到 Linux 的跨平台迁移，工具采用了 Oracle 官方提供的数据导出（Expdp）和导入（Impdp）工具。经过评估，将所有的数据从 Oracle 数据库导出并导入到中间库的时间大约需要一个小时。这一时间基本花费了一半的窗口时间，后续的数据转换工作以及将转换后的数据迁移到 TiDB 的工作在 1 个小时内基本无法完成，需要进一步优化迁移时间。

3.2 多通道迁移

在从老核心 Oracle 迁移数据至 X86 架构的 Oracle 中转机，再从 CSV 格式文件迁移到 TiDB 的过程中，我们发现采用单一通道和单一数据组的迁移方式无法在两小时的时间窗口内完成。因此，我们采取了将数据拆分成多个小组并行处理的策略，把所有迁移表和数据拆分成 9 组。拆分成多组之后，整体迁移完成的时间受限于最慢的那个组的迁移速度。

多通道分组的引入带来了新的挑战。

• 迁移表分组可行性

迁移表包含了存，贷，公共及核算几个核心的业务模块，需要考虑分组的可行性。和业务侧沟通，基于业务逻辑进行表分组的可行性，沟通下来业务侧给的反馈是可行的。

• 分组数量的确认

因各个业务表之间是存在关联关系的，分组需要结合业务关联性进行考虑，整体评估后再确认每个业务模块能分多少组。分组的选择，除了要考虑业务关联性的因素，还需要充分考虑硬件性能的最大化利用，进而最大化的缩短迁移时间。在进行初步的 4 组数据迁移验证时，我们观察到硬件资源，包括 CPU、网络和磁盘 IO，并未完全利用。逐步增加迁移组数至 6 组时，硬件资源的负载达到了一个较为饱和的状态。过程中，还需关注不同组之间负载交替的问题。某些组在迁移过程中持续保持高负载，而其他组的高负载可能仅出现在迁移开始的前两分钟或是后几分钟。通过一系列的测试和调整，最终确定了最佳的分组策略： 4 组用于处理存款数据，2 组处理贷款数据，2 组负责公共核算数据以及 1 组用于平移数据，共 9 组。

3.3 迁移脚本化

为了满足行方对数据迁移过程的要求，整个迁移过程需要实现脚本化操作，以减少人为误操作及提升迁移的效率。这涉及到脚本开发的复杂性，需要精心设计和测试以确保每个步骤都能准确无误地执行。同时，行方对迁移的时间窗口有严格的要求，整个迁移过程必须在两小时内完成（表结构转换+数据移形+数据迁移）。

将数据迁移拆分为 9 组并行执行后，迁移过程几个关键性的步骤，包括数据导出、数据导入和数据比对。为了管理这些操作，我们使用了一台控制机，它负责将任务指令下发到所有 9 组的机器上，并监控它们的执行情况。所有这些步骤都通过脚本化的方式进行，以实现高效的自动化操作。

脚本具备的能力

• 基于组的任务调度

• 基于表的任务调度

• 迁移过程的任务状态及进度监控

3.4 增量迁移优化

为了确保数据迁移工作能够在两小时的时间窗口内完成，在多通道分组迁移的基础上，还采取了增量迁移的方法作为补充策略。通常情况下，增量迁移适用于那些数据量庞大且历史数据不更新的业务表，例如在老核心系统中最大的表接近 3 亿条记录，以及一些包含大量交易流水的表。我们使用的导入工具 Lightning 往往会在处理这些大表时遇到时间瓶颈，为了缩短这些大表的迁移时间，增量迁移策略被引入以优化迁移效率。

如图所示，我们的数据迁移工作被划分为两个阶段进行。在第一阶段，我们选择在 T-3 日，也就是割接前三天，提前迁移部分大表的数据。到了割接当天，我们只迁移这些大表在过去三天内产生的新数据，显著缩短了迁移过程所需的时间。

增量迁移还需要考虑表合并的问题。例如，当我们提前三天迁移了 10 张表的数据后，我们需要确定如何在割接当天将这些数据与当天迁移的最近三天的数据进行有效合并。

第一种方式是增量表 rename。具体来说，在提前三天迁移数据时，我们将这些表 rename 为非生产环境使用的临时表名。到了割接当天，我们只迁移最近三天内产生的增量数据，使用原始的生产表名来标识。然后，我们将这些增量数据通过 insert into select 的方式同 3 天前的历史表数据进行合并，再通过 cross rename 操作，将这些合并后的表更名为最终的生产表名。Insert 操作会对分布式数据库的性能产生一定影响，可以基于增量表迁移的数据量来决定方案。评估下来，三天增量表的数据量不是很大，通过数据库 insert 方式进行数据合并高效且稳定，最终采取此种方式进行数据合并。

第二种方式，即在提前三天迁移的增量表保持原表名不变的情况下，到割接当天，利用 Lightning 工具的增量导入功能来合并数据。为了确保实施的便利性和考虑到数据量的管理，采用分步迁移。第一步，我们将增量表进行迁移，迁移后保持表名不变。第二步，继续迁移最近 3 天的增量表数据，并将这些数据追加到之前三天迁移的数据中，从而构成一份时间连续的完整数据集。

在实际执行过程中，还需要异常考虑的情况。尽管已经通过多次演练，但仍然存在在割接当晚将三天的增量数据插入到历史数据表时出现错误的风险。我们在提前三天进行数据迁移时，对这些表的数据进行了三份拷贝备份。如果遇到某张表插入失败的情况，可以迅速切换到另一张备份表，从而绕过插入过程中的异常问题。

3.5 迁移拓扑

以下是整体迁移分组及脚本化的全景流程图。整个过程从一个生产环境的 Oracle RAC 开始，数据首先被快速切换到生产 MA 镜像机。完成这一步骤后，数据将被导出并分发到 9 组 X86 机器上。在目标 TiDB 集群中，部署了 TiUP 中控机，该中控机不仅承载了脚本调度功能，还负责执行数据迁移相关的批量操作。脚本化流程主要包括几个关键环节：Oracle 数据的导出和导入、oracle 导出工具将数据转换为 CSV 文件、Lightning 工具将 CSV 文件导入到 TiDB，以及数据比对。所有这些环节都通过 TiUP 中控机和 DB compare 调度工具来协同执行。

为了应对割接当天可能出现的异常情况，脚本化流程设计了精细的控制机制。例如，如果在导出过程中，一组中的 10 张表有 9 张成功导出，而 1 张表失败。我们的调度程序不仅能够基于整个组来进行重新调度执行，还能够针对单个表进行精细的控制和重新发起。

在数据迁移工程中，我们采用了 Oracle 导出工具、Lightning 和 O2T Sync-diff 三种工具的协同工作，以实现对数据进行细致的表级别导出操作。Lightning 在导入数据时是基于目录进行导入，我们为每一张表创建了一个独立的目录，这样每个目录就可以代表一个数据组或者单独的一张表。O2T Sync-diff 同样支持表级别的操作，在数据比对过程中，如果发现某张表的数据比对失败，我们会对其进行修复，并在修复后针对这张特定表进行重新比对。

Oracle 导出工具 charset 参数设置建议和 Oracle 16GBK 字符集保持一致，避免不必要的转码操作。在运用 Oracle 导出为 CSV 的导出工具时，尽量减少对高级特性的使用，优先选择基本功能的使用方法。针对导出的 CSV 文件的字段分隔符，建议设置一个较长的分隔符，避免分隔符同表内容碰撞引发导入异常。从 Lightning 性能考虑再结合最佳实践，单文件大小设置为 256M。为了适配老核心的运营环境，Lightning 的字符集设置为 GB18030。sql-mode 需要开启数据严格要求的参数。

在上线当天，O2O 迁移过程表现出色，整个迁移仅用时 30 分钟，数据转换环节耗时 20 分钟，从 Oracle 数据库迁移至 TiDB 数据库的过程耗时 38 分钟，完美达成了两小时的时间窗口要求。

数据一致性

4.1 数据检核

数据一致性是数据迁移过程中至关重要的一环，确保了迁移后的数据准确无误，采取了双层数据比对策略。

• 技术检核

关注数据库层面的准确性，通过计算数据内容的 CRC32 校验和来验证数据的一致性。

• 业务检核

关注业务逻辑，比如使用记录数、业务项、记录状态、表间关系等基于业务考虑的指标进行核对。

在老核心 Oracle 向中转库迁移数据的过程中，使用 Oracle 成熟工具来执行，迁移过程执行严格的表记录数比对。在中转库阶段，转换前和转换后数据的核查由业务团队负责。数据从中间库迁移到最终的目标库 TiDB，这个过程中技术层面的检核至关重要，基于表内容进行 CRC32 校验。

4.2 乱码处理

正常字符集编码范围划分

• 正常编码区（符号 & 汉字）

• 用户自定义区（Private Use Area）

• 保留区（Reserved Zone）

乱码数据主要来自 IB2 协议层 GB18030 到数据库 ZHS16GBK 转码范围差异，用户自定义区的自定义字，跨系统数据处理阶段以及历史遗留的乱码，处理方式见下表。

对于第二类的内容失真问题，ICONV 转码工具在技术层面可以解决用户自定义编码的失真问题 。

乱码数据的应对方案包括以下几个步骤：

第一，预处理，通过扫描工具提前发现，形成乱码清单。

第二，对乱码数据预分析和分类处理。

第三，基于十六进制编码进行异步修复。

迁移成效

下图是从 Oracle 老核心到 TiDB 新核心的迁移全景图。左边是 Oracle 生产，分为 9 组，迁移当天 O2O 的迁移耗时 30 分钟，数据转换耗时 20 分钟，从 Oracle 到 TiDB 耗时 38 分钟，满足行方两小时的时间窗口要求。割接当天，TiDB 新核心所有的下游的同步，比如到近线库、逻辑库、镜像库以及 Kafka 的同步均异步实施，不占用窗口时间，包括到 DSG 逃生库的搭建也是异步实施的。

欢迎体验 TMS

在 2022 年的迁移方案设计与实施过程中，我们面临的挑战是在 TMS（TiDB Migration Service）全链路数据迁移平台尚未发布的情况下，如何有效地从 Oracle 数据库迁移至 TiDB。TMS 是一个专为 Oracle 到 TiDB 迁移场景量身打造的平台，它集成了应用对象兼容性评估、对象结构迁移、数据全量迁移、数据校验以及应用 SQL 兼容性评估等关键功能模块。

TMS 的出现，标志着迁移工作从依赖手工操作和多种工具组合的复杂方式，转变为一个白屏化、用户友好的流程。这种转变极大地降低了用户的使用门槛，提高了迁移的效率，并且增强了整个迁移过程的可靠性。随着 TMS 平台的不断优化和迭代，它已经在多个金融机构的 O2T（Oracle to TiDB）迁移项目中得到了成功应用。未来，我们期待与大家分享这些客户的实际使用体验，让更多用户了解 TMS 在实际操作中的优势和效果。通过这些案例分享，我们相信 TMS 将继续在数据迁移领域发挥重要作用，帮助更多企业实现平滑、高效的数据库迁移。