在目前数据库数字化转型改造过程中，金融行业核心资金交易场景改造和迁移是痛点和难点之一，这是由于核心资金交易场景普遍对性能、稳定性有很高要求；同时，核心资金交易场景的连续性要求又对迁移时间窗口有严苛限制，需要根据业务特点，精心设计迁移方案，因此，头部金融企业核心资金交易场景的数据库改造、迁移实践案例对金融行业数据库数字化转型有较高参考价值。
一、核心资金交易改造和迁移难点
太保集团核心资金交易系统具有系统关联关系复杂、传统集中式数据库绑定程度很深、业务影响极大、海量数据等特点。太保集团核心资金交易系统作为公司级统一资金收付管理平台，承载着全集团的资金收付交易任务。该系统自 2009 年建设至今，已经与 65 个子公司的业务系统对接，年处理交易近 1.6 亿笔，总金额近 7,000 亿元。在峰值交易日，系统需要处理高达 71 万笔交易，日处理金额达到 25 亿元。因此，系统的稳定性和性能对于公司的正常运营至关重要。
核心资金交易系统技术攻坚难点包括：
第一，存储过程数量庞大，系统核心功能大量关键业务逻辑都是通过 Oracle 存储过程实现；并且对于 Oracle 数据库产品特性使用非常深入，尤其是大量使用 Oracle 的全局临时表进行会话逻辑隔离操作。在迁移到 OceanBase 时，需要兼顾全局临时表相应改造方案的稳定性和应用改造成本。
第二，从业务层面，如何保证服务的稳定性、连续性是迁移过程中的首要问题。如何确保迁移后的数据库与原数据库数据一致，是我们需要解决的关键问题。任何数据错误都可能对企业的资金交易产生影响，造成重大损失。系统需要支持全集团 7*24 小时的交易，即使经过多方协调，停机切割时间也非常有限，需要在尽可能短的时间窗口完成切换。
第三，在海量数据加工、海量并发交易场景下，国产服务器 CPU 性能要弱于 Intel 服务器，因此如何对应用程序做极致优化，大幅降低 CPU 负载，确保核心资金交易系统稳定运行，也是攻坚难点之一。
二、改造方案
（一）存储过程中高频调用全局临时表优化
核心资金交易系统中使用了大量全局临时表，在迁移到 OceanBase 时，为了降低应用改造工作量，在保证性能稳定前提下，使用了 OceanBase 兼容全局临时表特性，但是对高频调用全局临时表场景，需要结合应用逻辑做表设计和应用极致优化，以满足性能要求。批处理高频调用全局临时表优化案例如下：
在性能压测阶段，核心资金交易系统批处理性能存在性能瓶颈。确认批处理存储过程耗时耗时 3392 秒，且都是执行开销。以批处理该存储过程前 30 位高开销 SQL 建立时间模型，前两位 SQL 1 和 SQL 2 总共耗时 2985 秒，占批处理时间的 88%，并且都是高频扫描临时表 T_CPI_TMP_SUBORDER 造成，单次执行在 20~50 毫秒，并不算高，但是由于高频执行，导致总开销时间较高。
优化 SQL 1 如下，该 SQL 耗时 1499 秒：
insert into "JTZJGL"."TMS_COLLECT_BILL_ORDER_T"( "ID", "BILL_NO", "ENTRY_SEQ", "ORDER_NO", "ORDER_ORG", "ORDER_FORG_NO", "ORG_TYPE", "ORDER_AMOUNT", "CREATE_DATE", "CREATE_USER", "LAST_UPDATE", "UPDATE_USER") select "JTZJGL"."TMS_COLLECT_BILL_ORDER_T_S"."NEXTVAL",:0,:1,"TMP"."ORDERNO","TMP"."ORDERUNIT","TMP"."ORDERUNITNUM",(case when (SUBSTR("TMP"."ORDERUNITNUM",1,1) = to_nchar('L')) then 'L' when (SUBSTR("TMP"."ORDERUNITNUM",1,1) = to_nchar('J')) then 'J' else 'P' end),"TMP"."AMOUNT",sysdate,-(1),sysdate,-(1) from "JTZJGL"."T_CPI_TMP_SUBORDER" "TMP" where ("TMP"."SEQ" = :2)抓取执行计划如下：
+---------+-------------------+------------------------------+------+------+
| plan_id | operator | name | rows | cost |
+---------+-------------------+------------------------------+------+------+
| 4047904 | PHY_INSERT | NULL | 1 | 91 |
| 4047904 | PHY_SUBPLAN_SCAN | NULL | 1 | 91 |
| 4047904 | PHY_SEQUENCE | NULL | 1 | 91 |
| 4047904 | PHY_TABLE_SCAN | TMP(IDX1_T_CPI_TMP_SUBORDER) | 1 | 91 |
+---------+-------------------+------------------------------+------+------+分析发现主要开销都是扫描临时表"JTZJGL"."T_CPI_TMP_SUBORDER"造成，处理数据仅一条，但扫描了 26342 条记录。
优化 SQL 2，耗时 1486 秒如下：
delete from "JTZJGL"."T_CPI_TMP_SUBORDER" where ("JTZJGL"."T_CPI_TMP_SUBORDER"."SEQ" = :0)| plan_id | operator | name | rows | cost |
+---------+-----------------+---------------------------------------------+------+------+
| 3474177 | PHY_DELETE | NULL | 1 | 92 |
| 3474177 | PHY_TABLE_SCAN | T_CPI_TMP_SUBORDER(IDX1_T_CPI_TMP_SUBORDER) | 1 | 91 |分析发现：主要开销都是扫描临时表"JTZJGL"."T_CPI_TMP_SUBORDER"造成，扫描约 62058 条记录，处理仅一条记录。
最终优化方案如下：
第一步，将 T_CPI_TMP_SUBORDER 表从全局临时表改为普通表且表模式设为 queuing 表，以便将删除记录做快速转储，提升查询性能。
第二步，T_CPI_TMP_SUBORDER 增加 sequence 字段，字段含义为批次中每笔交易的唯一序列。
第三步，在 sequence 字段上增加组合索引如下：
CREATE INDEX "JTZJGL"."T_CPI_INCOME_SUBORDER_IDX1" on "JTZJGL"."T_CPI_INCOME_SUBORDER" (
"SEQ",
"SEQUENCE"
) GLOBAL;第四步，在应用改写 SQL 如下：
insert 和 select 的时候增加 SEQUENCE 字段，保证数据正确，不再每次都 delete
第五步，每个批次处理完后，通过 SEQ 字段，一次 delete 清理该批次所有数据。
通过全局临时表表设计及应用程序优化，资金交易系统的批处理加工性能提升了 5 倍，满足了业务需求。
（二）海量数据高并发场景优化
核心资金交易系统是典型的海量数据加工、海量并发交易混合负载场景，同时资金交易系统对性能、稳定性要求极高，为了克服国产服务器 CPU 性能的短板，需要通过对应用程序做极致优化，大幅降低 CPU 负载，以确保核心资金交易系统稳定运行。
在海量高并发场景下，通过索引优化、Queuing 表优化、Sequence cache 优化等方式提高 SQL 性能。以高并发插入场景优化为例，大量插入场景中使用 sequence ，一般默认 CACHE 设置为 20，而在 OceanBase 中，sequence 加大 cache 缓存，避免业务高峰期额外生成 sequence 值对性能提升较为明显，通过将 sequence 的 CACHE 从 20 优化为 2000，插入性能提升了约 2.7 倍，满足了海量高并发插入场景性能的需求。
在海量数据加工场景下，通过标量子查询改外连接、虚拟表优化 inlist 问题、索引设计、全局索引改本地索引优化并发性能、清理冗余索引优化 DML 性能、For 循环优化等方式提高 SQL 性能。
结合业务逻辑，从设计、应用优化角度大幅降低 CPU 负载，使核心系统性能、稳定性均获得大幅提升，核心资金交易系统的运行信息如下所示：
（三）迁移方案优化
针对资金系统 7*24 小时运行、停机切割时间有限的特点，核心资金交易项目组确定了异构双活、逐步分流、分步切换、服务连续的原则，交易类功能“分批切换”，管理后台“一步切换”的总体方案。
针对交易类业务，核心资金交易项目组设计了交易路由，支持交易在 Oceanbase 环境和旧 Oracle 环境双活运行，可以实时在新旧环境切换交易流量，通过这种方式，即使在迁移过程中出现问题，也能够迅速切换到原数据库，保证服务的连续性。整体切换过程中，前期先引流业务量较小的公司，验证各个交易渠道的功能，待前期功能验证充分后，再做切换业务量较大的公司，降低整体切换的风险。项目组梳理出了交易量相对较小、时效要求相对较低的业务场景，在各相关团队的支持下，先利用这些业务在国产服务器上充分验证环境和交易渠道的正确性，降低后续大批次业务流入后系统运行的整体风险。
系统管理后台，主要提供对内银行账户管理、资金划款、线上审批等非交易类功能。这些功能流程相互嵌套，单业务时间长，不宜进一步拆分，因此该模块计划一步切换。
分批次切换过程中，数据迁移也是本次升级的一大困难。原始系统的存量数据库太大，并且系统并未对不同公司的业务数据分库分表存储，后续双活运行的时候，存在对两个异构数据库中同一张表进行操作的情况，后续迁移的时候需要整合这些数据。针对这种情况，项目组对系统中所有的表进行了分类，分析出基础配置类表、历史归档类表、实时交易类表这三种不同的表类型。在分批次切换过程中，针对不同的类型的表，设计了不同的迁移、合并策略，已保证数据完整、正确、高效的完成各个批次的迁移。
基础配置类表在第一批次切换时同步后，XC 环境需要根据新环境的信息做修改调整，之后两套环境配置信息会有差异，此类表无需再次同步；历史归档类表为归档的交易数据，数据量大同步时间长，因此项目组评估迁移期间的数据增量，提前归档了部分数据后暂停了归档跑批，保证这类数据在整个迁移期间保证静态，只需在第一次迁移时做全量迁移，所有批次切换后再打开归档跑批；实时交易类数据因需要在 OceanBase XC 环境和旧 Oracle 环境都修改，项目组提前规划两个数据库中相同表的 sequence 等信息，保证后续迁移时两份数据能顺利合并。
三、核心资金交易系统数字化转型价值
核心资金交易系统上线成功且运行稳定，从 2024 年 1 月至今稳定运行超过 120 天，成为金融行业数字化转型新标杆。核心资金交易从传统 Oracle 集中式数据库转型 OceanBase 分布式数据库，在稳定运行的同时，也带来了可观的经济效益，包括以下三方面：
○ 实现从原来的集中式架构向分布式架构转变，具备良好的扩展性，在面对瞬时海量高并发互联网业务场景具备良好的弹性扩容能力，满足未来业务增长发展需求，并且从数据库层面提供良好的适配应用双活能力。
○ OceanBase 兼容 Oracle 版本和兼容 MySQL 均具备非常好的存储压缩能力，在保证性能稳定的同时，平均压缩到原来 1/3，大幅减少服务器硬件扩容需求；
○ OceanBase 由于实现了数据大幅压缩，结合备份工具的优化，备份恢复较 Oracle 约提升了 5 倍性能，解决了海量大库备份以及定期恢复演练的痛点问题。
