?整体选型

针对以上技术挑战，选择了和原有Oracle RAC架构更接近的PolarDB作为互联网核心数据库的替换，PolarDB作为新一代云原生数据库主要特点如下：

1. 1.计算与存储分离，使用共享分布式存储，满足业务弹性扩展的需求。极大降低用户的存储成本。

2. 2.读写分离，一写多读，PolarDB引擎采用多节点集群的架构，集群中有一个主节点（可读可写）和至少一个只读节点（最大支持15个只读节点）。写操作发送到主节点，读操作均衡地分发到多个只读节点，实现自动的读写分离。

3. 3.基于K8S形态部署，提供分钟级的配置升降级，秒级的故障恢复，全局数据一致性和完整的数据备份容灾服务。

4. 4.集中式架构，不需要进行分布式架构相关考虑设计，和原有使用习惯保持一致，性能不低于原有Oracle数据库。

5. 5.高度兼容Oracle，应用基本上不需要做SQL语法调整。

迁移方法

为了避免对原有生产业务造成影响且保证迁移数据的严格一致性，采用了DTS全量+增量的方式，对于数据规模超大的Oracle集群，如客户主数据系统，提前2周启动数据迁移链路，在全量数据迁移之前DTS会启动增量数据拉取模块，拉取源实例的增量更新数据，并解析、封装、存储在本地存储中。当全量数据迁移完成后，DTS会启动增量日志回放模块，从增量日志读取模块中获取增量数据，经过反解析、过滤、封装后迁移到目标实例，通过目标端主键保证数据的唯一性。应用切换成功后，从应用接口的响应速度上看，性能比Oracle提升约30%。到2020年底，互联网核心所有模块的迁移完成，包括服务超百万代理人的出单系统App，和注册用户超1亿的寿险App、客户主数据等共计47个业务系统。

互联网核心整体迁移技术方案

为了减少迁移过程中对下游大数据消费造成影响，到大数据的同步链路改造采用了2步走的策略。

大数据同步链路改造方案

1. 1.增加PolarDB到Oracle的反向实时同步，原有Oracle到Kafka同步链路不变，避免数据库切换带来太大的变动；

2. 2.参考SharePlex的格式对DTS进行定制化开发改造，待验证充分后，直接替换掉SharePlex原有同步链路。

?主要挑战

迁移完成后，PolarDB作为互联网核心数据库，需要稳定支撑起2021年一季度业务冲刺。而最前端的出单系统是整个性能压力的集中点，并且由于做了微服务化改造拆成了36个模块，分散在了多个数据库中，任何一个数据库都可能存在被打爆的风险，在迁移到PolarDB之前是拆在多个Oracle RAC集群中，依靠内部开发的数据库监控完成多个Oracle集群的监控，迁到PolarDB之后整体架构将更适应业务弹性的挑战：

1. 1.统一管控：通过PolarStack将多台机器组成的集群进行统一管控，提供DBaaS服务；

2. 2.弹性：实例由原来的物理机部署，变为K8S Pod部署，更为灵活和弹性；

3. 3.读写分离：通过智能代理服务实现自动的读写分离，实现分钟级扩容，故障场景下自动切换，应用不需要做任何调整。

PolarDB技术架构

业务冲刺当天经过了三个高峰时间点：12：00、17：00、21：00，每小时出单量和全天出单量进入了历史的前三位，高峰期出单笔数达到9000笔/s。

?互联网核心迁移历程回顾

2020年9月，互联网核心首批应用模块迁移到PolarDB，整个适配过程不到一个月。此后，互联网核心各个模块就开始了大规模的迁移。

2020年11月，PolarDB完成了最大的单库客户主数据迁移。

2021年1月底，PolarDB作为互联网核心出单系统的数据库，稳定支撑起该保险公司2021年一季度业务冲刺。

传统核心迁移

业务背景

该大型保险公司的传统核心系统历史悠久，既有1998年之前建成的，也有2004到2008年间建成的，时间跨度长，数据量异常庞大，单个数据库的数据规模甚至超过20TB。更具挑战的是，很多老核心按省市做了拆分，要分省市分别进行迁移，单一老核心系统需要迁移的数据库可能就要多达36个。传统核心总体来说可以分为三类系统：

第一类：2016、2017年基于Java技术栈开发的新核心系统，大概有13个。

第二类：分别在1998年之前，2004到2008年间建成的老核心系统，大概有6个。

第三类：一些可能要下线的，不在此次数据库迁移范围内的系统。

这些传统核心的数据库当时面临的主要技术挑战是：

1. 1.系统关联关系庞杂，既有保单平台管理系统也有资金类系统，系统间关系难以梳理。

2. 2.既有物理和逻辑集中的新核心，也有物理集中，逻辑分离的老核心，其中老核心分省部署，每个省都会有一套数据库，迁移工作量巨大。

3. 3.对Oracle专有特性依赖较多，大量使用存储过程、触发器、自定义类型、函数、外键等。更为挑战的是老核心大量使用Pro*C（SQL嵌入式C程序）和Tuxedo（Oracle中间件做分布式事务处理）做保单过程处理，仅某年金系统涉及到的Pro*C程序就有1500多个，约140万行代码，业务短时间难以改造。

4. 4.单库体量非常大，超过10TB的就有6个，最大单库规模有23TB，停机窗口短暂。

5. 5.交易量大，每天数据库调用几十亿次，还有大量复杂集合类精算和结算类交易。

技术方案

?选型方案

针对以上技术挑战，选择了分布式数据库OcenaBase作为传统核心的替换，OceanBase数据库主要特点如下：

1. 1.基于无共享（Shared-Nothing）的多副本架构，整个系统没有任何单点故障，保证系统的持续可用。

2. 2.基于LSM存储引擎技术，结合新硬件的能力，采用可扩展的分布式架构，提供高性能和扩展性。

3. 3.数据库针对 Oracle、MySQL 等应用最为广泛的数据库生态都给予了非常高的应用兼容性支持。

4. 4.虽然为分布式架构，一般也不需要应用层做相应的重新设计如指定分布键等，与原有Oracle使用习惯基本一致。

5. 5.OceanBase 数据库完全自主研发，不依赖外部开源代码，真正做到自主研发。

?迁移方法

针对传统核心复杂的数据库情况进行全面验证，最终形成了140页的迁移操作手册和详细的割接行事历，为后续系统的迁移和大面积推广积累了宝贵的经验，并形成了标准的迁移割接方案。整体迁移方法过程如下，从基础环境准备-迁移过程演练-正式割接-监控运维等四大环节进行逐项拆解，落实到人，精确到分。

数据库整体迁移割接流程

对于规模较大Oracle数据库的迁移，有如下四点提升迁移效率的经验：

1.冷热数据分离

一般的业务库数据中，数据具有自己的生命周期，数据的高频访问具有冷热特点。比如，流水表历史数据，日志表历史数据除了在审计回查场景之外，访问很少甚至不访问，但是通常这部分数据都会比较大，数据迁移的开销会比较高，造成数据迁移时间的延长。针对该部分数据，我们可以预先对这部分数据进行归档备份，然后采用静态迁移或者利用OMS工具全量迁移单独迁移。

2.LOB类型数据

Oracle数据表行 LOB 类型空间占用较大，每一批次的数据拉取大小会在原始行的基础上有显著增加。相比无LOB数据类型，对OMS端内存需求有数倍的需求，因此，优化的策略是单独对LOB类型的表建立新的链路，采用较小的并发，防范JVM OOM的风险，同时，为了提高整体迁移的速度，进行多链路并行迁移。

3.无LOB类型数据

相对于LOB类型数据，无LOB数据类型的表的迁移，单位迁移批次的大小较小且稳定，内存需求可控，并发度可适度加大，提高迁移速度。所以，对该部分数据可使用较高的并发度单链路或多链路迁移。

4.多个大库迁移链路通过不同OMS并发迁移

单台OMS可以支持多个迁移任务，但是共享数据网络出口。鉴于大库数据的持续拉取，可以将大库的迁移分散至不同OMS节点，减少大数据网络流量的争用。

?主要挑战

迁移过程中最难的是针对Pro*C的适配。PRO*C是Oracle提供的应用程序专用开发工具，应用C语言编写程序，在程序源代码中可以直接嵌入SQL语句，执行数据库操作。Pro*C既兼容了传统C语言的开发模式，又提供了强大的数据库操控能力，所以在保险行业和其他行业也有不小的用户基础。

而 Tuxedo(Transactions for Unix,Extended for Distributed Operations) 作为是最早的分布式事务产品，是AT&T在20世纪80年代推出的。传统老核心业务中，大量使用Tuxedo调用相关的Pro*C程序来做保单业务流程处理来保证跨库事务的一致性。

为了根本上解决该问题，实现应用的平滑迁移，阿里成立项目攻坚团队，用1个月时间，从头开发Pro*C兼容预编译程序和运行时库，2020年国庆节前，预编译程序成功编译了某年金业务的全部1000多个Pro*C程序，并正确跑通了两个典型批处理作业，通过了该公司的验收，进展大大超出该公司预期，也因此在赛马中成功胜出赢得了该公司对OceanBase产品研发能力的信心。

短时间完成老核心的适配，得益于：

1. 1.始终坚持自主研发，研发人员有优秀的个人能力，清楚产品每一行代码的来龙去脉，能够快速和高质量地新增和修改代码，真正做到了自主研发。

2. 2.全链路打通的研发模式，Pro*C只是外在交互模式，底层还要依赖数据库的内核能力，从SQL模式、优化器、服务端等做到了全链路打通，比如研发在批处理作业现场联调时发现SQL对to_date函数的'J'参数尚未支持时，快速反映给SQL模块，后端仅用一天完成了开发测试和发布。

3. 3.敏捷开发模式，攻坚小组的研发和测试大家坐到一起，每日随着项目进展和变化快速确定和调整当日的目标。打破研发和测试边界，研发一边在开发，测试同学已经把单测和集成测试案例写好，开发侧有一点小的进展就立即验证测试，使得开发和测试能接近同步完成。

?迁移历程

2020年10月，首个传统新核心理赔系统顺利上线。

2021年3月，完成传统老核心最小省份的迁移上线。

2021年4月，完成13个传统新核心的迁移上线。

2021年8月，完成传统老核心最后一个大省迁移上线。

2021年9月，完成传统老核心最后一个单体库迁移上线。

全面体系化迁移

该保险公司核心迁移过程中遇到的另一个问题是如何体系化全面迁移，虽然在2021年3月完成最小省份的迁移，但后面还有多个老核心分布在36个按省市独立部署的Oracle数据库中，每个省份又包括了20多个schema，如果按照老的迁移方式，每个省份都需要创建20多条迁移链路，对于资源和人力都是极大的消耗，短时间也难以完成。通过分析，工程化批量迁移最大的问题是没有做到全流程自动化，手工操作的步骤还比较多，为了解决该问题，产研和现场交付人员做了三件事情：

1. 1.数据迁移工具在底层链路上从技术层面支持多schema合并操作，从而可以将同一个省份的二十多条链路合并到一条迁移链路中。

2. 2.在产品层面将数据迁移工具的底层能力进行拆解，将原来无法自动化的步骤做了自动化，并通过API的方式暴露出来，使得前线交付同学可以根据用户的实际情况像搭积木一样进行组装使用。

3. 3.交付人员基于暴露的API和140多页的迁移操作手册，用一个月时间开发出简化迁移链路配置的快捷迁移工具。

一键自动迁移过程图

在对快捷迁移工具迭代了四个版本后，投入使用。需要人工干预的工作量减少了80%。同时一起建立了数据库迁移实施的统一规范和标准，开展有序迁移。上线实施标准流程包括8大环节，98个步骤，5倍峰值压测，体系化迁移8大环节如下：

1. 1.兼容性评估：明确改动范围，进行适配改造工作量评估并合理安排工作任务。

2. 2.负载评估：从原数据库获取SQL负载信息并在新数据库测试环境回放，验证新数据库应用后的性能。

3. 3.测试迁移、适配改造：进行适配改造、全量回归测试、性能测试。有条件的系统（微服务化较好、重构等），可以分批改造和实施迁移。其中，性能测试可根据迁移前的关键业务容量基线，确定测试准出标准。

4. 4.生产库存量、增量式迁移：对于业务连续性要求不高的系统，一般操作一次性存量方式完成数据迁移；对于业务连续性要求高的系统，采取全量+增量迁移方式，待增量数据追平后实施切换，仅需在切换时点暂停业务（分钟级）。

5. 5.反向回流：对于关键应用，可实施数据同步回原数据库应对未知风险。

6. 6.数据验证：迁移完成后进行数据准确性验证及应用验证。

7. 7.持续监控：对可能遇到的问题进行监控、详细评估分析。

8. 8.在线压测：迁移完成后，定期开展在线压测，基于实际生产场景进行业务全链路压力测试，持续保障应用容量和性能。

2021年5月，西部某省的迁移在2小时内顺利完成，验证了Oracle端多schema合并迁移这一重要技术难点，相比之前有数倍的提升，为剩余省份的并行迁移扫清了障碍，经过优化后：

1. 测试环境：自主进行数据迁移和压测回放，并通过SQL自动优化建议工具，大大提高了迁移验证效率，可以自助解决90%以上的问题。

测试环境多次迁移演练步骤

2. 生产环境：将过程中需要人工检查费时、费力的步骤，做到了自动化。

正式迁移割接步骤

紧接着完成了东北三省+内蒙古总共四个省份的数据，过程中解决了Oracle源端出现不可见控制字符脏数据的问题，确保了数据准确无误。

2021年8月，历经前面11次的迁移后，终于完成了最后一个、最重要省份，也是数据规模最大的的数据库迁移。

2021年9月，在完成了所有核心数据库的迁移并经历了开门红大促的考验后，要完成一个保险公司一个完整的业务周期，只剩下最后一关，就是保险精算。

保险精算是保险公司业务经营的特色，指运用数学、统计学、金融学、保险学及人口学等学科的知识与原理，去解决商业保险与各种社会保障业务中需要精确计算的项目。一般会在季度末和年末进行，以衡量企业的经营状况，并制定更有市场竞争力的保险产品，是保险业务开展不可或缺的关键一环。

保险精算分析的特点在于数据量大，分析的模型复杂，过程中还有大量的数据写入，往往要持续一周甚至更长时间。并且要确保精算过程中，快照点的数据不能发生变化，基于传统IOE架构往往通过存储层的快照来实现。迁移到分布式数据库后，如何保证在不停应用的情况下完成保险精算，是整个迁移过程的最后一个障碍。经过反复评估，阿里云为此制定了最佳方案，受益于OceanBase底层数据块的快速物理备份和表级的恢复能力。经过近1个月的压测验证，集群恢复速度达到800MB/S，完全满足精算的备份恢复的时间要求。最终在2021年9月30日在规定的时间窗口完成了数据的备份并导入到了精算库，有效支撑了全面迁移后的保险精算业务。

保险精算数据准备过程

主要问题总结

当然迁移过程并不是完全一帆风顺，虽然未产生重大生产事故，但过程中也出了几次故障。而这些故障背后既反映了国产数据库在面对复杂场景上能力的提升，也反映了分布式架构带来的根本性变化。

数据库连接打满多次触发实例高可用切换

互联网核心迁移到PolarDB过程中遇到的最大一次问题是在2021年1月，当天凌晨面向C端用户的两个重要系统完成数据迁移和应用的割接。伴随着日间业务流量逐渐增加，两系统因为大量的慢查询堆积较多应用连接，将数据库服务堵塞，全天多次触发PolarDB实例自动高可用切换，执行节点重建恢复流程。

以云原生容器形式部署的数据库服务节点，除了受本身数据库相关的内存参数限制外，还受cgroup指定的CPU和内存限制。当时连接池打满后，触发容器OOM，引起实例的多次切换重建。云原生数据库基于容器部署需要在稳定性和自保能力方面做诸多增强，为了解决相关问题，后续的版本中增加了global plan cache、resource manager、并行日志回放、global index等功能，数据库的内核参数也针对金融场景逐一做了定制化优化。

针对金融场景对稳定性要求极高的需求，通过本次互联网核心迁移也增加了诸多管控运维能力：

1. 1.增加AWR功能，定期收集AWR报告对性能和可用性进行分析。

2. 2.增加GAWR功能，对主机、Dockers、RW/RO进行全量数据采集。

3. 3.新增online promote功能，优化在线切换，进一步缩短切换时间。

4. 4.增加Idle状态Session超时自动断开连接功能，减少后台进程数，及时释放回收Idle Session的内存资源。

5. 5.优化元信息缓存功能，Session级别元信息缓存优化为全局元信息缓存，降低后台进程的内存使用。增加内存总量资源管理控制，设置一定的阈值，到达阈值后开始Cancel Query、Kill Idle Session、Kill Active Session、拒绝新用户Session连接，避免容器OOM。

SAN交换机故障导致数据库进入无主状态

由于原有Oracle数据库都是基于SAN存储部署，在2020年9月份启动数据库迁移工作之时，针对OceanBase部署建议的本地SSD盘硬件还没有采购到位。为了快速启动相关的迁移工作，最开始OceanBase传统新核心集群还是部署在SAN存储上，这也为第一个生产问题埋下了隐患。

第一个传统新核心应用理赔上线后，系统运行比较平稳。意外出现在某天下午14点7分，系统同时收到了应用和数据库监控的告警。监控显示，应用出现了90秒的阻塞迭停。然而，当双方团队还在排查问题时，数据库已经自动完成了恢复。

应用监控系统响应时间散点图

OceanBase QPS监控截图

问题现象时间轴分析

经过深入分析，发现是SAN存储交换机到核心交换机连接的一个端口出现了故障。虽然配置了多路径转发，但由于操作系统内核的超时时间OceanBase切主时间不匹配，触发了OceanBase的自动选主操作。而选主过程中，另外一台物理机也走的同样端口也出现了IO阻塞的问题，最终导致OceanBase进入无主状态，当多路径软件成功切换后，OceanBase未经过任何干预就完成了自动恢复。本质上是因为软件超时参数与硬件超时参数不匹配所导致，也是软硬件系统磨合不够充分的表现，通过相关参数的调整能减少RTO的时间。

在此次故障之前，大家对OceanBase的了解都停留在PPT层面：RPO=0、RTO<30秒。直到这次故障才真切的感受到，故障时的快速切换和自动恢复能力是多么的重要。但是故障发生，项目组内部也有质疑声音出来：“OceanBase基于SAN存储的部署本来就是错的，我们就不该使用OceanBase。”但经过深入的分析才发现并不是OceanBase的问题，也不是SAN存储的问题，而是有没有充分的磨合，软硬件相关的参数是不是最合适的。 IOE架构之所以成为集中式架构下的 最佳组合 ，正是经过广泛的实践和各种场景的锤炼，让软硬件都能在一个最佳的状态下提供服务。 最终经过这次事件之后，大家统一认识，调整参数并不能根本性解决问题。 原来部署在SAN存储上的OceanBase迁移到了本地盘硬件设备上，随后也逐渐演进到两地三中心多活部署架构。

执行计划跳变导致业务卡顿

在11月份某个周末，理赔系统出现慢SQL，导致理赔应用系统票据汇总操作卡顿超时。为什么系统已经稳定运行了半个多月，没有任何的业务变更，反而在周末业务低峰期出现问题？现场交付专家经过分析很快定位到原因，OceanBase的执行计划发生了跳变，导致执行计划走错。

经过深入分析，OceanBase和其他数据库一样，通过使用执行计划缓存 (Plan Cache)，对于相同的SQL（参数不同），跳过解析阶段，避免重新生成执行计划，以提升SQL的性能。但是实际场景中传入的参数往往是不同的，就像淘宝双11有热点库存，在保险行业也有大小机构号。虽然SQL看起来一样，但因为传入的参数不同，优化的手段和执行的路径也不一样。传统数据库（比如 Oracle）为了选择最优的执行计划，会定期进行数据对象统计信息的收集（如每天夜间的维护窗口（maintenance window）），淘汰旧的执行计划，使新的执行计划能够按照实际的数据统计信息生成更准确更优的执行计划。OceanBase采用类似的方法，但由于OceanBase 每天进行数据冻结合并，增量数据落盘，数据库对象的实际数据信息（行，列，平均值等）会发生较大的变化。因此合并以后，计划缓存会进行清理，并根据第一次传入的参数生成执行计划进行缓存，默认情况下，只会保留一个执行计划。由于周末当时第一次传入的参数不具备普遍代表性，导致后续执行计划走错，产生了性能问题。

执行计划跳变是一个比较常见的数据库性能现象，Oracle先后推出了Cursor Sharing，Outline，Bind peeking，ACS，SPM等手段来优化改进，然而生产上也无法彻底规避执行计划走错的问题，新的数据库产品从Oracle 99%到100%的兼容优化也是最难的，也不是短时间能一蹴而就。对于这种小概率事件，应急就成为了最后的兜底手段，在不动应用的大前提下，通过数据库灵活的绑定执行计划，是出现突发问题时比较有效和容易落地的手段。实际整个迁移过程中，对于偶发的执行计划跳变，项目组也已经驾轻就熟，没有给迁移带来意外影响。

整体效果

历时一年，100个业务系统的近700套数据库全面实现国产数据库迁移，成为首家完成100%核心业务系统国产数据库迁移的大型金融企业，数据库OceanBase和PolarDB用量占比超过97%。

通过数据库的全面替换，实现了对数据资产的的全面安全保障能力，做到了：

1. 1.100%数据库技术栈的安全可控，摆脱对Oracle数据库的依赖。

2. 2.摆脱对小型机和高端存储的依赖。

3. 3.促进云原生和分布式数据库应用成熟，从可用到好用并取得性能提升。

4. 4.数据库服务集中管控，显著降低硬件及整体运维成本。

5. 5.真正的实时扩缩容和高可用能力，轻松应对大促活动。

从完全封闭的体系架构到逐步开放再到全面开放，真正实现了对数据库核心技术的自主研发。得益于云原生架构和分布式架构的弹性和资源池化能力，也自此能实现“一库多芯”，只需一条命令就可以把租户切换到海光服务器节点，实现了国产硬件的平滑替换。

迁移后由于分布式数据库提供的高效压缩能力，存储容量的大小只有原来的1/3，加上高端小型机迁移到国产机架式服务器，设备投入节省近2亿元。

数据库服务器及存储机柜数量从近200个缩减至60个，利用率提高了300%。设备功率由1557KW大幅降低至471.35KW。经测算，全年可节约电力约近千万度，为该公司数字化转型提供了源源不断的绿色动能，有力践行了国家双碳战略，减少公司由于自建数据中心带来的碳排放增量。

总结

今天国内大部分金融机构的核心业务仍然运行在国外的数据库上，这是一个我们无法回避的现实，数据库的替换不仅是一个产品的替换，替换的目的不单纯为了“国产”两个字，更重要的是：技术必须进步；替换后的新系统必须具备老系统和国外产品不具备的能力，不仅是性能和稳定，更是对业务的敏捷支撑能力，和面对海量业务和不确定性的业务高峰时刻的处理能力，以及更上一层楼的金融级高可用能力。

这些年对数据库替换的分析和畅想很多，但是面对实际大规模、复杂的核心应用系统的技术平台替换，过程中还有很多事前想不到的问题，尤其对于现有运行环境的各种适配和兼容，对应用的友好性等方面。关于这些，本次迁移实践走出了坚实的一步，积累了弥足珍贵的经验，希望能为今后的国产进程给出很好的示范效应。