导语
一套运行十余年的 Oracle 核心系统，管理着几十万亿规模的托管资产。它不能停、不能错，也不能因为数据越积越多而变慢。某国有大行用了三年多时间，将这套系统迁移到平凯数据库（ TiDB企业版）。项目的看点并非换上了一个国产品牌，而是银行在不中断关键业务的前提下，完成了一次底层架构换代。
凌晨时分，大多数人还在睡觉，某国有大型银行的资产托管核心系统已经进入一天中最忙碌的时段。
数十万个批量任务陆续启动。交易要清算，资产要估值，账目要核对，投资组合要生成报表。很多工作必须在早晨业务开始前完成，因为基金净值、年金账户和各类资管产品的运营，都在等待这些结果。
普通人很少注意到资产托管。我们在手机里看到一只基金当天的净值，背后并不只是基金管理人算了一遍。托管银行还要独立保管资产、完成清算核算，并对结果进行复核和监督。它既像账房，也像裁判。
这家银行的托管系统管理着几十万亿规模的资产，覆盖清算、核算、监督和报表等关键环节。系统中的一个错误，可能影响大量产品和客户；一次长时间中断，也可能打乱整个业务日程。
过去十多年，这套系统一直运行在 Oracle 上。随着业务增长，原有架构逐渐接近极限。银行最终决定把数据库换成 TiDB（平凯数据库），但这件事远不是安装一套新软件、再把数据复制过去那么简单。
原来的扩展方式，走到了尽头
Oracle 在大型金融系统中使用多年，稳定性和功能都经过充分验证。但随着业务持续增长，集中式数据库能够提供的扩展空间越来越有限。
托管核心已经积累了几十 TB 数据，而且还在持续增长。过去遇到容量和性能压力，通常是换更大的服务器、增加更高规格的存储。但单机再强也有上限，硬件升级的成本越来越高，能够换来的余量却越来越小。
互联网系统常用的办法是分库分表：把一张大表拆开，把不同用户的数据放进不同数据库。但托管业务很难这样做。
一笔资产可能同时关联产品、账户、市场、交易、会计科目和估值日期。系统中存在数万条 SQL，大量查询需要同时关联多张表。按客户拆，跨产品查询会受影响；按产品拆，统一核算和监督又会变复杂；按市场拆，也躲不开跨市场的资产组合。
没有一个分区键可以把所有业务关系整齐切开。强行分库分表，很可能把数据库的复杂度转移到应用系统中，让开发、对账和运维变得更困难。
还有一个更现实的问题：这是一套最高等级的银行关键系统。它既要支持同城高可用，也要具备异地灾备能力。数据库扩容、升级或故障切换，都不能以长时间停机和数据损失为代价。
因此，项目的目标很明确：不再寻找一台更大的“单机”，而是建立一套可以持续生长的数据库架构。
TiDB 如何接住这套核心系统
TiDB 的核心特点是原生分布式。对应用来说，它仍然是一套可以使用 SQL 访问的关系型数据库；在内部，数据会被分散保存到多个节点，并通过多副本机制保证一致性和可靠性。
这意味着业务不必先把数据库手工切成许多小库。数据增多时，可以增加存储节点；查询和交易压力上升时，可以增加计算节点。计算与存储分别扩展，系统不再完全受制于一台服务器的容量。
对于托管系统，这一点很关键。数据库不仅要保存大量数据，还要处理复杂的关联查询、实时交易和夜间批处理。TiDB 的分布式执行能力可以让多个节点协同工作，把适合并行的计算分散处理，而不是把所有压力集中在一台机器上。
迁移也并非“完全不用改”。原系统长期使用 Oracle，部分程序依赖 Oracle 特有的语法、存储过程和函数，这些内容仍然需要改造。但 TiDB 保留了关系型数据库和 SQL 的使用方式，并支持公共表表达式、窗口函数、分区表等能力，使大量业务逻辑不必因为分库分表而重新设计。
数据库选型最终看的不是一项跑分，而是能否同时回答几个问题：数据继续增长怎么办，复杂 SQL 怎么跑，机器故障怎么办，白天交易和夜间批处理如何共存，原有应用的改造量是否可接受。TiDB 的价值，正是在同一套架构中给出了相对完整的答案。
新旧系统一起跑了一年多
核心系统迁移最难的时刻，是按下切换按钮。
测试环境可以模拟故障、压力和异常数据，却很难覆盖真实生产中的所有组合。一条使用多年的 SQL，可能只有在某个特殊产品、某个结算日或某组历史数据上，才会出现不同的执行结果。
项目组没有直接替换核心系统，而是先从规模较小的关联应用开始，把 Oracle 到 TiDB 的 SQL 改造、数据迁移、性能调优和运维流程完整走一遍。相关方法稳定后，才进入托管核心。
核心系统改造完成后，新旧两套环境持续并行运行。真实业务请求同时进入 Oracle 和 TiDB，两边各自计算，再逐笔比较结果。项目组用一年多时间反复发现差异、修正程序和补齐边界场景。
与此同时，TiDB 还经历了数百项准入验证。测试不只看正常情况下能不能跑，还包括节点故障、网络异常、磁盘问题、资源争抢、灾备切换和性能回归。只有业务结果、性能和故障处理都达到要求，系统才进入最终切换阶段。
这种做法看起来慢，却适合银行核心系统。它没有要求管理者因为一次演示或一组性能数字就相信新数据库，而是把“相信”变成了一段可以反复核对的生产证据。
切换之前，先把回去的路修好
即使完成了长期并行验证，银行仍然要面对一个问题：新系统切换后，如果发生预料之外的情况，还能不能回到 Oracle？
普通的数据迁移通常只解决从旧库到新库的单向搬运。正式切换后，新产生的交易只存在于新数据库中，旧库的数据会逐渐落后。此时再想回退，不但需要停机补数据，还可能面对复杂的数据核对。
这个项目在切换前建立了反向同步链路。TiDB 中已经提交的数据变化，由 TiCDC 持续捕获，再配合转换工具生成 Oracle 可以接收的数据，送回旧系统。Oracle 不再承担主业务，但仍能维持可用于应急回切的数据状态。
项目组还进行了完整的切换和回切演练。它不代表任何情况下都能毫无成本地瞬间返回，但至少把“回退”从纸面预案变成了一条真正跑过、检查过的数据链路。
对银行来说，这条路的意义很直接：数据库替换不再是一场只能向前的豪赌，而是一个有验证、有决策点，也有退出方案的过程。
一套独立 TiCDC，连接三条关键数据通道
在这个项目中，TiCDC 不是只在迁移时使用一次的数据工具。它负责持续读取 TiDB 中已经提交的数据变化，并将这些变化送往不同的下游系统。
第一条通道通向灾备环境。生产中心发生严重故障时，灾备系统需要尽可能接近最新的数据，才能继续承接业务。
第二条通道通向数据湖。报表和分析系统需要及时获得托管业务数据，但又不应该频繁查询核心生产库。通过持续同步，分析任务可以在自己的平台上运行，减少对交易系统的影响。
第三条通道就是 Oracle 逃生通道。TiCDC 捕获增量变化，再由配套工具完成格式转换和回写，使旧数据库在过渡期内保留回切条件。
这三条链路服务的对象不同，运行节奏和运维要求也不同。灾备强调连续性，数据湖强调吞吐，Oracle 回写还要处理两种数据库之间的差异。如果都依附在生产数据库的部署体系中，组件升级、资源调整和故障定位很容易互相牵连。
项目因此采用了 TiCDC 独立部署方式。同步系统拥有自己的部署、元数据管理、监控告警和运维边界，可以单独扩容、升级和排查问题。它仍然按照 TiDB 的标准机制读取数据变化，但不再与主数据库共用同一套组件生命周期。
一套独立部署的 TiCDC 平台，由不同同步任务支撑灾备、数据湖和 Oracle 回写。独立部署不会凭空消除同步产生的所有负载，但它把资源、监控和责任边界划分清楚，避免同步组件的日常运维直接扰动核心数据库节点。
对于非技术人员来说，可以把它理解成：主数据库负责把每一笔账记对，TiCDC 负责把已经确认的账目送到需要它的地方。记账和送账彼此配合，但各自有独立的值班、监控和故障处理体系。
白天跑交易，晚上跑批量，不能让一条慢查询堵住所有人
托管系统还有一个典型特点：不同时间、不同类型的任务都在使用同一套数据库。
白天是清算、核算和查询等联机业务，响应速度直接影响操作人员和下游系统；夜间则会集中运行大量批处理任务；业务人员还可能临时发起复杂报表查询。三类任务对数据库资源的需求完全不同。
如果一条复杂 SQL 因为数据变化或执行计划不理想而消耗大量资源，其他交易也可能被拖慢。过去很多系统只能等到告警发生后，再由运维人员寻找并终止问题 SQL。
TiDB 的资源管控能力让项目组可以为不同任务划分“车道”。正常交易留在主资源组，批量和分析任务按照设定额度运行；当系统识别到持续占用过多资源的 SQL 时，可以把它转入低优先级资源组，限制消耗，而不是任由它挤占整个集群。
资源管控不会让慢 SQL 消失，但可以阻止局部问题轻易扩散成全局故障。对于既有实时交易、又有大批量作业的托管系统，资源隔离和自动管控与单纯提升硬件性能同样重要。
数据库换了，增长方式也变了
经过三年多的分阶段改造、双轨验证和切换演练，这套托管核心最终由 TiDB 承担主要数据库服务。清算、核算、监督和报表等关键业务完成迁移，核心交易响应和批量处理达到生产要求，系统也获得了继续在线扩展的空间。
更重要的变化发生在架构层面。过去，数据增长意味着寻找更大的单机和更昂贵的扩容窗口；现在，容量和计算压力可以通过增加节点逐步消化。过去，灾备、分析和回退由不同链路分别建设；现在，TiCDC 将这些数据流纳入可以持续运行和独立监控的体系。
这个案例并不能说明任何系统只要换成分布式数据库就会成功。复杂 SQL 需要逐条验证，Oracle 特有功能需要改造，数据迁移需要长期校验，高可用也必须经过真实故障演练。越是核心的系统，越不能把产品能力当成自动生效的承诺。
这个项目给出了更进一步的答案：国产数据库进入金融核心系统，讨论的已经不应只是“能不能替代”。面对几十 TB 数据、数万条 SQL、大规模批处理和严格连续性要求，TiDB 可以在不把业务拆成大量数据库的前提下，提供水平扩展、分布式事务、高可用、资源管控和实时数据同步能力。
TiDB 在这个项目中的领先性，来自一套完整的原生分布式架构：它同时承接交易、复杂查询、批量处理、灾备和数据流通，而不是依靠某一项孤立功能完成替代。工程方法负责逐步降低风险，TiDB 的产品能力则决定了这条路本身能够走通。
当普通投资者再次打开手机查看基金净值时，大概不会知道，背后的核心数据库已经完成了一次跨越十余年技术周期的换代。对一套管理几十万亿资产的系统来说，最好的技术升级正是这样：变化发生在底层，业务依然按时开始，每一笔账依然准确到达。
