2026 年初，某国有大型银行完成了一次关键切换：承载几十万亿元资产规模的资产托管核心系统，正式从 Oracle 迁移到平凯数据库（TiDB 企业版，以下简称 TiDB）。
资产托管核心系统每天处理申购赎回、清算核算、估值计息、风险监控等核心业务。每天凌晨，约 30 万个批量任务陆续启动，必须在上午开市前完成。作为银行内部最高安全等级的 A+ 类系统，它必须做到三件事：不能停、不能错、不能慢。
项目最终用三年半给出了答案：TiDB 以原生分布式架构、水平扩展和高可用能力承接了复杂核心负载；项目组则通过小系统先行、长周期双轨验证和可回切设计，把一次高风险替换变成了审慎、可验证的工程迁移。
上线后，核心联机交易响应时间稳定在 200 毫秒以内，关键业务 SLA 达到 99.99%。截至原案例材料统计时点，系统保持零重大故障、零数据丢失、零业务中断。
核心账本正在触及架构边界
资产托管系统是基金、年金、债券等资产的独立“账本”。基金公司公布净值之前，托管银行需要独立核算和校验。数字必须准确，系统也必须持续在线。
这套系统于 2008 年上线，长期运行在 Oracle 上，并连续多年通过 ISAE 3402 标准审计。到 2022 年，随着业务规模和数据量持续增长，原有架构逐渐逼近极限。
•首先是容量和算力压力。生产库数据量超过几十TB，含索引超过几十 TB，涉及 4,500 多张表，每月数据仍以 900GB 以上的速度增长。Oracle X86 架构的 CPU 使用率一度逼近 90%，继续依赖单机纵向扩容，空间已经越来越有限。
•其次是系统无法简单分库分表。全系统有数万条 SQL，其中 12,000 多条涉及三张及以上表关联，约四分之一关联五张表以上。业务既要按产品、科目查询，也要按交易市场等维度处理，很难找到统一的分区键。项目组曾对分库分表方案进行严格 POC 验证，最终判断不具备实施可行性。
•最后是系统停不起。A+ 类系统要求同城双活、异地灾备，同城故障场景下恢复点目标为零。与此同时，在金融信创和供应链安全要求下，核心数据库国产化也已经不再只是成本选择。
数据量大、关联查询复杂、缺少统一分区键，再叠加极高的业务连续性要求，这正是银行核心系统国产化最难处理的一类场景。
项目组对市场上的国产数据库方案进行了全面考察。最终选择 TiDB，是因为新数据库必须同时满足三项要求：数据持续增长时能扩、复杂关联业务不必拆、关键故障发生时切得快。
原生分布式，让系统可以持续扩展
TiDB 采用计算与存储分离的分布式架构。数据量增长时可以增加存储节点，并发压力上升时可以增加计算节点，计算和存储资源能够分别扩展。
这意味着，面对每月近 TB 的数据增长，系统不必再依赖单机硬件持续升级，也不必提前一次性规划多年后的最大容量。业务增长到哪里，集群就可以按需在线扩展到哪里。
保留复杂查询能力，避免分库分表改造 [相关]
对于拥有数万条 SQL、包含大量多表关联的核心系统，全面重写应用或强行分库分表，风险和成本都难以接受。
TiDB 对 MySQL 协议和常用 SQL 能力的支持，加上针对 Oracle 特有语法的改造方案，使项目组能够在保留整体业务逻辑的基础上完成迁移。例如，使用 CTE 改造 CONNECT BY，通过 LEFT JOIN 与 UNION 组合改造 FULL JOIN，并继续支持窗口函数、分区表等能力。由此，大规模 SQL 改造被控制在可执行范围内。
分布式高可用，满足核心系统连续性要求
TiDB 通过多副本机制保证数据可靠性。在该项目方案中，同城故障切换控制在 30 秒以内，并实现 RPO=0。
核心系统敢切换：先验证、再并行、始终可回退
产品能力解决“能不能承载”，严谨的实施方案解决“敢不敢切换”。面对一套运行多年的银行核心系统，项目组没有采用一次性替换，而是设置了三道安全闸门。
第一道：小系统先行，先验证方法
项目最初选择约 1TB 数据量、业务相对独立的基金估值和份额登记系统进行迁移。项目组用一年半时间跑通 Oracle 到 TiDB 的完整流程，并逐步形成 SQL 改造规范、性能调优基线、数据迁移工具链和双轨并行机制。
只有在外围系统中得到实际验证的方案，才被带入资产托管核心系统。
第二道：新老系统并行，用真实业务逐笔验证
进入核心系统阶段后，迁移规模扩大到 数十 TB 数据、28,000 条 SQL 和 3,300 张核心业务表。
项目组让 Oracle 与 TiDB 两套系统并行运行超过 18 个月，将真实生产流量同时发送到两套系统，对处理结果持续核对。与模拟测试相比，真实流量能够覆盖更多复杂业务组合和难以预设的边界场景。
在此基础上，项目还完成了功能、高可用故障模拟、资源管控和 Oracle 性能对标等四大维度共 227 项准入测试。发现的问题持续整改和复验，达到投产要求后才允许正式切换。
第三道：TiCDC 独立部署，三条通道守住退路
针对白天联机交易、夜间大批量任务和临时报表查询混合运行的特点，项目组建立了三级资源管控机制：正常 SQL 走主通道，长时间或高资源消耗 SQL 自动进入隔离通道，偶发高消耗任务进入限速的应急通道。这样既避免异常查询拖累核心业务，也不必简单中止任务。
与此并行，项目组将 TiCDC 独立部署为数据同步平台，持续读取 TiDB 已提交的数据变化，并送往三条数据通道。
•灾备通道承担跨城异步复制，确保生产中心发生严重故障时，灾备系统可以快速接管业务；
•数据湖通道将托管业务数据持续同步至分析平台，报表和查询在自己的环境中运行，不对核心交易造成干扰；
•第三条通向 Oracle 逃生通道，用于在过渡期内维持回切条件。Oracle 逃生通道则捕获增量变化，由配套工具完成格式转换后回写至 Oracle，覆盖 3,300 张表，日均同步数据约 70GB，使旧数据库在过渡期内持续保留回切条件。
这套机制让核心系统国产化从一次不可逆的选择，变成了可验证、可回退的渐进式切换，也为银行最终决策提供了关键保障。
2026 年初，资产托管核心系统正式切换至 TiDB，生产与灾备集群均采用数十台物理服务器组成。
切换后，原 Oracle 环境长期处于 90% 以上的 CPU 高压水位得到缓解，核心联机交易响应时间稳定在 200 毫秒以内。面对每月近 TB 的数据增长，系统可以通过在线增加节点扩展容量，不再依赖停机扩容窗口。
截止目前，系统保持了零重大故障、零数据丢失、零业务中断。
对于一套管理几十万亿元资产的银行核心系统，这些生产运行结果比单纯的性能测试更有说服力。
核心生产运行验证国产数据库承载能力
长期以来，行业关心的不是国产数据库能不能支持一般业务，而是能不能扛住银行最复杂、最关键、最不能出错的核心系统。
TiDB 的原生分布式架构、计算与存储分离、水平扩展、多副本高可用和数据同步能力，为核心系统提供了可扩展、可持续的技术底座；小系统先行、18 个月双轨验证、全维度准入测试和反向同步回切方案，则把实施风险逐级释放，确保切换过程谨慎、可控。
免责声明
本站转载的文章，版权归原作者所有；旨在传递信息，不代表本站的观点和立场。不对内容真实性负责，仅供用户参考之用，不构成任何投资、使用等行为的建议。如果发现有问题，请联系我们处理。
本站提供的草稿箱预览链接仅用于内容创作者内部测试及协作沟通，不构成正式发布内容。预览链接包含的图文、数据等内容均为未定稿版本，可能存在错误、遗漏或临时性修改，用户不得将其作为决策依据或对外传播。
因预览链接内容不准确、失效或第三方不当使用导致的直接或间接损失（包括但不限于数据错误、商业风险、法律纠纷等），本网站不承担赔偿责任。用户通过预览链接访问第三方资源（如嵌入的图片、外链等），需自行承担相关风险，本网站不对其安全性、合法性负责。
禁止将预览链接用于商业推广、侵权传播或违反公序良俗的行为，违者需自行承担法律责任。如发现预览链接内容涉及侵权或违规，用户应立即停止使用并通过网站指定渠道提交删除请求。
本声明受中华人民共和国法律管辖，争议解决以本网站所在地法院为管辖法院。本网站保留修改免责声明的权利，修改后的声明将同步更新至预览链接页面，用户继续使用即视为接受新条款。
