银行核心背后的落地工程体系丨Oracle – TiDB 数据迁移详解

系列导读

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

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

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

---

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

银行核心数据迁移四要素

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

• 迁移逻辑

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

• 数据一致性

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

• 迁移性能

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

• 回退方案

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

迁移逻辑

迁移需求和挑战

• 银行账务核心涉及的表多且数据量大。
• 字符集转换，Oracle 的 ZHS16GBK 到 TiDB 的 UTF8MB4 的转换。
• 数据移形，表结构和数据的移形，表结构发生变化，老数据基于新的业务规则转换为新的业务数据。
• 全程脚本化，数据要保证前后一致。
• 迁移窗口总时间 2 小时内 (数据移形 + 数据迁移 + 数据检核)。

迁移方案设计

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

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

引入