某大型保险集团核心资金交易系统信创数据库改造迁移实践
【摘要】金融行业核心资金交易场景的升级改造是数据库数字化转型改造的痛点和难点，本文分享了某大型保险集团资金交易系统信创数据库改造迁移方案的具体设计和成功实践，为金融行业同类系统的数字化升级提供了宝贵经验，具有较高参考价值。
【作者】林春，某大型保险集团数智研究院首席数据库专家。负责集团数据库数字化转型选型及全链路技术支撑工作，负责核心系统数据库国产化分布式数据库技术攻坚，实现金融行业深度绑定Oracle特性、海量核心系统数据库国产化首次里程碑突破，为推进行业数据库架构变革、国产数据库生态繁荣做出突出贡献;自研国产数据库改造工作量预评估工具“指南针”，提升应用改造效率约25%，累计节省成本超千万。
引言
目前，金融行业核心资金交易场景的升级改造是数据库数字化转型改造的痛点和难点，这是由于核心资金交易场景普遍对性能、稳定性有很高要求;同时，核心资金交易场景的连续性要求又对迁移时间窗口有严苛限制，需要根据业务特点，精心设计迁移方案，因此，头部金融企业典型核心资金交易场景的数据库改造、迁移实践案例由于数据库体量较大、业务场景复杂性较高，对金融行业数据库数字化转型有较高参考价值。
一、核心资金交易改造和迁移难点
某大型保险集团核心资金交易系统具有系统关联关系复杂、传统集中式数据库绑定程度很深、业务影响极大、海量数据等特点。集团核心资金交易系统作为公司级统一资金收付管理平台，承载着全集团的资金收付交易任务。该系统自2009年建设至今，已经与65个子公司的业务系统对接，年处理交易近1.6亿笔，总金额近7.000亿元。在峰值交易日，系统需要处理高达71万笔交易，日处理金额达到25亿元。因此，系统的稳定性和性能对于公司的正常运营至关重要。
核心资金交易系统技术攻坚难点包括：
(1) 系统核心功能大量关键业务逻辑大量使用Oracle的全局临时表进行会话逻辑隔离操作。在迁移到某国产分布式数据库时，需要兼顾全局临时表相应改造方案的稳定性和应用改造成本。
(2) 从业务层面，迁移过程需要保证服务的稳定性、连续性和数据一致性。任何数据错误都可能对企业的资金交易产生影响，造成重大损失。系统需要支持全集团7*24小时的交易，即使经过多方协调，停机切割时间也非常有限，需要在尽可能短的时间窗口完成切换。
(3) 在海量数据加工、海量并发交易场景下，确保核心资金交易系统稳定运行极为关键。国产服务器CPU性能要弱于Intel服务器，因此如何对应用程序做极致优化，大幅降低CPU负载，确保核心资金交易系统稳定运行，也是攻坚难点之一。
二、改造方案
2.1 存储过程中高频调用全局临时表优化
核心资金交易系统中使用了大量全局临时表，在迁移到某国产分布式数据库时，为了降低应用改造工作量，在保证性能稳定前提下，使用了相关数据库产品兼容全局临时表特性，但是对高频调用全局临时表场景，需要结合应用逻辑做表设计和应用极致优化，以满足性能要求。批处理高频调用全局临时表优化案例如下：
在性能压测阶段，核心资金交易系统批处理性能存在性能瓶颈。确认批处理存储过程耗时耗时3392秒，且都是执行开销。以批处理该存储过程前30位高开销SQL建立时间模型，前两位SQL1和SQL2总共耗时2985秒，占批处理时间的88%，并且都是高频扫描临时表T_CPI_TMP_SUBORDER造成，单次执行在20~50毫秒，并不算高，但是由于高频执行，导致总开销时间较高。
分析：分析发现SQL1和SQL2的执行计划并不存在问题，主要开销都是扫描临时表”JTZJGL”.”T_CPI_TMP_SUBORDER”造成，处理数据仅一条，但扫描了数万条记录，虽然单次执行介于20毫秒~50毫秒之间，但是由于执行频度过高，总耗时就很可观。
最终优化方案如下：
1)将T_CPI_TMP_SUBORDER表从全局临时表改为普通表且表模式设为queuing表，以便将删除记录做快速转储，提升查询性能。
2)T_CPI_TMP_SUBORDER增加sequence字段，字段含义为批次中每笔交易的唯一序列。
3)在sequence字段上增加组合索引如下：
4)在应用改写SQL如下：
insert和select的时候增加SEQUENCE字段，保证数据正确，不再每次都delete
5)每个批次处理完后，通过SEQ字段，一次delete清理该批次所有数据。
通过全局临时表表设计及应用程序优化，资金交易系统的批处理加工性能提升了5倍，满足了业务需求。
2.2 海量高并发、批加工混合负载场景优化
核心资金交易系统是典型的海量数据加工、海量并发交易混合负载场景，同时资金交易系统对性能、稳定性要求极高，为了克服国产服务器CPU性能的短板，需要通过对应用程序做极致优化，大幅降低CPU负载，以确保核心资金交易系统稳定运行。具体如下：
1、海量高并发场景优化。通过索引优化、Queuing表优化、Sequence cache 优化等方式提高SQL性能。以高并发插入场景优化为例，大量插入场景中使用sequence ，一般默认CACHE设置为20.而在某国产头部分布式数据库产品中，sequence加大cache缓存，避免业务高峰期额外生成sequence值对性能提升较为明显，通过将sequence的CACHE从 20优化为2000.插入性能提升了约2.7倍，满足了海量高并发插入场景性能的需求。
2、海量数据批加工场景优化。通过标量子查询改外连接、虚拟表优化 inlist 问题、索引设计、全局索引改本地索引优化并发性能、清理冗余索引优化 DML 性能、For 循环优化等方式提高SQL性能。
结合业务逻辑，从设计、应用优化角度大幅降低 CPU 负载，使核心系统性能、稳定性均获得大幅提升，在业务接近25000qps指标情况下，响应时间满足业务需求，核心资金交易系统的运行信息如下所示：
2.3 迁移方案
针对资金系统数据量达30TB、7*24小时运行、停机切割时间有限的特点，核心资金交易项目组确定了异构双活、逐步分流、分步切换、服务连续的原则，交易类功能“分批切换”，管理后台“一步切换”的总体方案。整个系统分三批次进行迁移，单次迁移中，数据迁移与校验的时长控制在3小时内，停机时间控制在4小时内。
针对交易类业务，核心资金交易项目组设计了交易路由，支持交易在国产分布式数据库环境和旧Oracle环境双活运行，可以实时在新旧环境切换交易流量，通过这种方式，即使在迁移过程中出现问题，也能够迅速切换到原数据库，保证服务的连续性。整体切换过程中，前期先引流业务量较小的公司，验证各个交易渠道的功能，待前期功能验证充分后，再做切换业务量较大的公司，降低整体切换的风险。项目组梳理出了交易量相对较小、时效要求相对较低的业务场景，在各相关团队的支持下，先利用这些业务在国产服务器上用1个月左右的时间充分验证环境和交易渠道的正确性，降低后续大批次业务流入后系统运行的整体风险。
系统管理后台，主要提供对内银行账户管理、资金划款、线上审批等非交易类功能。这些功能流程相互嵌套，单业务时间长，不宜进一步拆分，因此该模块计划一步切换。
分批次切换过程中，数据迁移也是本次升级的一大困难。原始系统的存量数据库太大，达到30TB，并且系统并未对不同公司的业务数据分库分表存储，后续双活运行的时候，存在对两个异构数据库中同一张表进行操作的情况，后续迁移的时候需要整合这些数据。针对这种情况，项目组对系统中所有的表进行了分类，分析出基础配置类表、历史归档类表、实时交易类表这三种不同的表类型。在分批次切换过程中，针对不同的类型的表，设计了不同的迁移、合并策略，以保证数据完整、正确、高效的完成各个批次的迁移。
基础配置类表在第一批次切换时同步后，信创环境需要根据新环境的信息做修改调整，之后两套环境配置信息会有差异，此类表无需再次同步。
历史归档类表为归档的交易数据，数据量大同步时间长，因此项目组评估迁移期间的数据增量，提前归档了部分数据后暂停了归档跑批，保证这类数据在整个迁移期间保证静态，只需在第一次迁移时做全量迁移，所有批次切换后再打开归档跑批，在整个切换流程中将不进行归档。
实时交易类数据因需要在国产分布式数据库环境和旧Oracle环境都修改，项目组提前规划两个数据库中相同表的sequence等信息，保证后续迁移时两份数据能顺利合并。第一批次迁移将进行全量迁移，根据业务所属公司不同，新的业务流量分别在国产分布式数据库环境和旧Oracle环境运行。第二批次根据设计好的sequence信息找切换批次公司的增量数据插入到国产分布式数据库中，并将该批次的业务流量切换到国产分布式数据库中。第三批次将全量数据迁移到国产分布式数据库中的新表中，并将国产分布式数据库中的增量数据插入到新表中，国产分布式数据库中的新表通过重命名的方式替换旧表。迁移到国产分布式数据库完成割接后，利用国产分布式数据库的OMS同步工具将数据反向回写到Oracle旧库，确保能够回退。
三、核心资金交易系统数字化转型价值
核心资金交易系统上线成功且运行稳定，从2024年1月至今稳定运行超过120天，成为金融行业数字化转型新标杆。核心资金交易从传统Oracle集中式数据库转型国产数据库分布式数据库，在稳定运行的同时，也带来了架构转型、硬件成本降低、备份恢复性能提升等价值，具体包括以下三方面：
1、实现从原来的集中式架构向分布式架构转变，具备良好的扩展性，在面对瞬时海量高并发互联网业务场景具备良好的弹性扩容能力，满足未来业务增长发展需求，并且从数据库层面提供良好的适配应用双活能力。
2、某国产头部分布式数据库兼容 Oracle 版本和兼容 MySQL 均具备非常好的存储压缩能力，在保证性能稳定的同时，平均压缩到原来 1/3.大幅减少服务器硬件扩容需求;
3、某国产头部分布式数据库由于实现了数据大幅压缩，结合备份工具的优化，备份恢复较 Oracle 约提升了 5倍性能，解决了海量大库备份以及定期恢复演练的痛点问题。
