如何从 Oracle 平滑切换到 TiDB？本文主要和大家分享在落地过程，包括应用改造、数据迁移，以及 SQL 兼容性验证的具体实践。
经过多次项目打磨，对于从 Oracle 切换到 TiDB 我们有非常完善和成熟的标准化体系，每个环节都有成熟的流程和应对方案。涉及数据库选型、可行性评估、应用适配、数据迁移、性能验证、投产切换、再到运维保障等步骤。
换句话说，我们做切换并不是“摸着石头过河”，而是有章可循，有标准可依，帮助企业可以有序、可控地完成升级演进。
作者：TiDB 解决方案架构师
Oracle 切换到 TiDB 的三大关键节点
如果从客户国产化替换的整体视角来看，整个去 O 过程有几个关键节点特别重要，只要顺顺利利跨过这些坎，后面的项目推进就会顺畅很多，进入可控又高效的阶段，做起来也得心应手。
整体来看，这一过程可以分为前、中、后三个阶段，每个阶段都有不同的挑战与重点，而正是这些阶段性的探索与突破，共同构成了国产化替换的关键路径。
-
前期，主要是应用适配改造阶段。这里的重点是语法语义的改造、应用框架的调整、对象的梳理、数据链路的设计以及对象转换规则的制定，相当于为整个项目奠定基调。一开始，我们可以选择一个体量不大但业务特征典型的系统作为试点项目。一旦语法转换规则确认，应用程序适配完成，后续的系统就基本能够沿着这套“标准”来实施，整个过程自然会高效、清晰。
-
中期，随着数据规模的不断扩大，数据迁移成为最大挑战。小规模场景还能通过停机迁移完成，但核心系统绝不可能接受长时间停机。因此，正向迁移必须采用“全量+增量准实时同步”的模式，切换时只需短暂停机即可完成，我们也在这个过程中不断迭代优化。同时，从 TiDB 到 Oracle 的反向回退方案，同样不可或缺，这是标准迁移方案里的重要一环，一旦上线后遇到不可控因素能够快速回退，保障业务连续性。
-
后期，系统切换成功后，风险逐渐集中在 SQL 性能上。我们早期也曾遇到过部分测试未覆盖的 SQL，导致网卡打满，进而影响业务稳定。为降低风险，最开始我们采用分批投产、按渠道逐步上线的方式。随着经验逐渐成熟，我们又引入了 SQL 兼容性评估工具，将 Oracle 的 SQL 抓取下来，转换为 TiDB 格式后进行真实回放，验证执行性能，从而提前规避潜在问题，方案进一步到完善和成熟。
经历了这三个关键阶段的打磨，后续的迁移工作和投产切换就会顺畅的多，可以说是真正实现了“一马平川”。
金融级核心系统如何完成去 O 演进？5 大案例拆解
目前，我们已经在不少头部客户那里完成了实践，比如某头部财产保险公司、国有大行，还有一些头部城商行等。
这些客户的系统都非常复杂，对稳定性和性能的要求可以说是最高级别的。通过完整的迁移流程和充分的验证，他们已经顺利完成了从 Oracle 到 TiDB 的切换，并且现在核心业务运行的非常稳定。这也充分证明了 TiDB 能够真正承载关键系统，为后续更多企业的国产化替换提供了信心。下面和大家具体说说几个实践案例。
某头部财险公司核心系统从 Oracle 迁移到 TiDB
首先是一家头部财险企业的核心系统迁移。其核心业务系统包括：承保、理赔、收付和再保。
自该企业 2021 年正式启动国产化替换工作以来，项目稳步推进，截至目前核心系统累计数据量 450TB+ 数据，28 套业务系统，最终落地为 15 套 TiDB 数据库集群，其中单集群最大规模达到 120TB 以上，预计到 2025 年底，该企业核心系统的国产化替代将全面完成。
这家头部财险企业的核心系统大多是基于 Oracle RAC 架构，主要运行在 AIX 小型机上，部分系统部署在 HP-UX 平台，采用的是典型的 IOE 架构，整体上高度依赖国外的高端存储设备和小型机，建设和运维成本较高，所以在国产化背景下，启动核心系统替代工作就成为那个时段的迫切任务。
此外，随着业务量不断增长，前端系统可以轻松实现横向扩展，但传统集中式数据库在存储和写入能力上逐渐遇到瓶颈，也存在一些并发冲突和扩展受限的问题。
这也促使客户开始思考是否需要引入更具弹性和可扩展性的分布式数据库架构。
最开始选型的时候，客户也充分评估了业内常见的分库分表架构。但分库分表基本意味着要重构业务，同时对开发团队的系统设计能力要求极高，还会带来系统复杂度增加和高昂的研发运维成本。一旦拆分策略不合理，系统的灵活性与扩展性也会受到严重制约。
相比之下，原生分布式数据库从底层设计上实现了计算与存储的真正解耦，具备天然的横向扩展能力。在一致性保障方面，TiDB 这类数据库通过分布式事务协议实现强一致保障，支持复杂 OLTP 与分析类混合负载；同时保留标准 SQL 能力，对上层业务基本无感知，极大降低了迁移与开发门槛。
因此，客户最终选择摒弃传统的分库分表路径，转向架构更清晰、能力更完备的原生分布式数据库。在这样的背景下，该头部财险企业将在 2025 年底通过 TiDB 数据库完成所有核心系统的国产化替换工作。
某头部财险公司保单中心系统
保单中心是整个核心系统的“核心”，它承担着对用户保单的全生命周期管理。
改造之前，该系统运行在两台 AIX 小型机上，受限于硬件和架构瓶颈，性能和扩展性都面临挑战。这次改造将数据库迁移到多台 x86 服务器组成的 TiDB 分布式集群，实现了全方位的突破：
-
性能提升显著：算力由集中式架构转向分布式架构，业务平均响应时间从 9ms 降低到 6ms，整体性能提升约 33%。
-
吞吐能力增强：原 RAC 架构受限于单服务器的进程数与内存大小，数据源最大连接数仅 5600，业务高峰期常常出现 JDBC 连接不足的问题。改造后，连接数扩展至 1 万以上，完全满足了高峰期的海量并发需求。
-
高可用与稳定性：应用与数据库全面采用分布式架构，消除了单点隐患，系统在关键场景下的稳定性大幅增强。
-
可扩展性提升：从集中式转向分布式，不仅满足了现有需求，也为后续弹性扩容奠定了基础。经测算，该架构可良好支撑保费收入增长至 5000 亿元。
-
在成本方面，项目替换了昂贵的小型机和高端存储，每年可节省硬件租用成本约 600 万元。同时，核心系统上线国产分布式数据库 TiDB 后，每年还能节约 Oracle 软件授权费用约 1200 万元。
值得一提的是，每年元旦假期后的第一个工作日，保险业都会有个“开门红活动”，此时业务量激增，而 TiDB 在业务高峰中表现极其稳定。过去在 Oracle 上运行时，开门红活动需要大量运维人员现场重保值守；而切换到 TiDB 后，即便面对数倍于日常高峰的业务压力，系统也能平稳运行，这也充分展现了分布式数据库架构的先进优势与核心价值。
某城商行新一代核心系统
某头部城商行的核心系统原来是基于 Oracle 的集中式架构，而且是一个用 C 开发的集中式系统，已经运行十多年，系统很复杂，一个转账最麻烦时要执行 300 多条 SQL。随着业务发展，原有架构逐渐遇到瓶颈，既要面对监管合规的国产化替换要求，也希望通过架构升级，提升业务敏捷性和可扩展性。
最终他们选择了基于 TiDB 的分布式架构。在部署方式上，主集群跨 A 城市两个机房部署，同时在 3000 公里外的 B 城市建设异地灾备集群，通过对等部署实现 RPO = 0。在监管抽查中，已经能够完成秒级的计划内切换，验证了架构的高可靠性。
在应用侧，这家银行也同步做了微服务化改造，把原有单体核心拆分为近 10 个微服务。无论应用拆多少，底层统一由一套 TiDB 集群支撑，实现了和企业架构更好的解耦。上线后，系统在性能和稳定性上都有明显提升：日均交易量超过 1000 万笔，平均交易耗时小于 100 毫秒，核心业务系统运行效率提升 54%，批处理效率提升到原来的 2.1 倍。
无论应用拆成多少个微服务，底层支撑的依然是一套数据库集群。意味着新的数据底座既能支撑微服务架构的灵活扩展，又能够与企业整体架构实现更好解耦，不会对上层应用形成限制或制约。TiDB 在支撑金融级的核心场景中的表现，将帮助客户在国产化的背景下实现平滑演进和长期可持续发展。
国有大行现金管理系统
现金管理系统属于对公领域里非常关键的 A+ 类系统。因为大行体量巨大，现金管理系统在这里有 50TB 级别。
最初，这家大行的现金管理系统是用三套 Oracle RAC 支撑的。切换到 TiDB 后，我们把整体架构拆成了两部分：左侧承载境内基础产品，右侧承载流动性管理，用两套系统支撑核心业务。
对于 A 类及以上的高等级关键业务系统，数据量超过 4TB 时，采用分布式架构是毋庸置疑的选择。由于客户不想进行业务大规模的重构，所以该系统没有选择分库分表，而是选择了 TiDB 数据库。大量对公业务系统最终都选了 TiDB，原因很简单：对公业务极其复杂，如果强行做分库分表，几乎等于重构，这个代价太大，难以接受。
别看这只是对公系统，它的 TPS 峰值能达到 4500。而且在日间运行时，不仅有海量的简单 SQL，还涉及大量两表、三表的复杂关联。
切换到 TiDB 后，客户获得了实在收益——支持未来 5 年的业务增长需求；满足日均交易 9000 万笔、峰值 1.3 亿笔的要求，日均 TPS1200、峰值 TPS4400 的性能要求，以及日终批量 4 小时作业的时间要求；实现了从 IBM 小机到开放分布式架构的下移，每年整体能节省软硬件、服务、开发等成本数百万元。
国有大行交易综合查询
最后分享另外一个国有大行做的 HTAP 系统案例。该系统的核心目标是通过整合替代，把原来分散在多套系统里的功能统一起来。过去客户分别依赖三到四套 Oracle RAC、两套 MongoDB 分布式版，以及一套 Hive 来支撑，现在通过 TiDB HTAP 架构实现了整体替代。
这个系统主要解决了历史数据查询和批量处理的问题，实现了 T+0 实时处理。比如大家通过手机银行、网银或柜面查询收支明细，基本都会走这套系统。数据能在秒级从核心系统（如借记卡交易）和外围渠道同步过来，再通过宽表直接为客户提供秒级服务。
架构上，我们采用 Kafka 消息中间件做实时数据同步，同时用离线文件补偿机制来保证最终一致性。我们还设计了冷热分层架构：最近一年的热数据放在高性能机器上，副本更多，保障高并发和实时查询；久远的冷数据则放在成本更低的硬件上，减少副本，以控制整体成本。
目前，这套系统已经能稳定支撑 PB 级的数据容量，并满足弹性扩展需求，日间 TPS 大约在 2.5 万，可以同时支持千万级 QPS 的 OLTP 与 OLAP 混合负载。
从业务角度看，收益非常明显：
-
TiDB HTAP 架构替代了 Oracle、MongoDB、Hive 等多种异构产品，架构简化、成本下降。
-
满足 PB 级容量和访问需求，存算分离架构保障弹性扩展。
-
支撑全行 6 亿客户、2.5 万 TPS、10 万级 QPS 的复杂业务场景。
-
业务上实现了 超 10 年的永久查询，以及单次跨越 5 年的大范围多维分析，为实时运营和业务洞察提供了坚实支撑。
从保险、银行等行业的实践案例中，我们可以清晰看到 TiDB 在核心系统中的应用价值。无论是面对高并发的交易处理，还是复杂的多表关联查询，亦或是 HTAP 架构下的实时分析，TiDB 都能够稳定支撑关键业务，并帮助客户实现性能优化和架构升级。在这些项目中，客户不仅保证了核心业务的连续性，亦在成本、灵活性和运维效率等方面获得了显著收益。**除了金融行业，TiDB 在医疗、制造等行业也打造了很多 Oracle 迁移的成功案例，**陆续再跟大家详细分享。
