超大型金融机构国产数据库全面迁移成功实践

---

 刘伟光 

阿里巴巴集团副总裁

阿里云智能新金融&互联网事业部

总经理

导语

2021年9月，某超大型金融机构圆满实现最后一个规模高达20TB+核心数据库的全面迁移改造工作，也为后续向云原生多活架构演进打下了坚实的基础。该核心系统数据库全量迁移项目的成功上线，树立了金融行业践行科技强国的标杆实践。将历时一年的迁移全过程完整步骤及技术攻略做提炼梳理，便完整沉淀成了独一无二的干货、本文的全部内容。“实践出真知”，阿里云走出了助力超大型金融机构国产数据库全面迁移坚实的一步，积累了弥足珍贵的经验。因此，本文不是对于数据库替换的分析和畅想，而是真正从实际面对实际的大规模复杂的核心应用系统的技术平台替换的技术指南，过程中存在各种“分析”文章中想不到的问题，尤其对于现有运行的环境的各种适配和兼容，对应用的友好性等，关于这些问题到底该如何解决，这篇文章均一一给出了详细解法。

前言

在国家层面提出加快建设科技强国，实现高水平科技自立自强的大背景之下，某超大型保险（集团）公司深入推进数字化转型，紧随先锋技术发展趋势，前瞻性布局启动IT架构分布式改造转型，并于21年9月圆满实现了最后一个规模高达20TB+核心数据库的全面迁移改造工作，也为后续向云原生多活架构演进打下了坚实的基础。该数据库国产迁移项目成功上线，树立了金融行业践行科技强国的标杆实践，也是对国家科技自立自强战略以及国产技术的履责担当；更推动了整个国内数据库管理与应用体系科技生态建设和科技产业链的快速成熟。

对于保险行业而言，短时业务并发压力虽没有互联网企业那么大，但是在业务复杂性和对数据库专有特性的依赖程度上，都要远大于互联网企业。保险业务的处理更为复杂，单一业务要多个系统完成，调用链比银行和互联网业务更长、更复杂，确保复杂集合大交易量的稳定是保险业务数据库国产的挑战。由于金融机构对业务连续性和数据准确性的严苛要求，在传统头部金融机构中始终没能有一家完成国产数据库全面迁移，直到这家保险公司成功实施，并取得了五个突破。

突破一、迁移时间短。从2020年9月到2021年9月，仅用时一年即完成迁移， 而传统金融机构还没有实现过如此大规模的核心系统全量迁移。

突破二、迁移规模破纪录。一年内完成了包括传统核心、互联网核心、个险销售、团险销售、经营管理、客服管理、大数据在内的近百个业务系统近在线Oracle数据库的全量搬迁工作，迁移数据规模超400TB、数据量超千亿，单库数据规模超20TB。

突破三、迁移全程同时保障了业务连续性和数据准确性。整个迁移过程无一例回切，上线后近一年来，系统稳定运行，并历经2021年完整周期的“业务大考”，经受住了开门红高峰TPS 5万+、QPS 21万+和包括精算在内的所有业务环节的严苛考验，完全满足生产需要，实现国产数据库从可用到好用的跨越。

突破四、迁移后实现技术100%自主创新。基于完全自研创新的国产数据库，迁移过程中版本升级持续发版共计50余次，最长需求解决时间2个月（Pro*C+Tuxedo）。同时通过系统培训与交流实现累计超过500位员工的数据库专业考试认证，实现了数据库的全面自主掌控能力。

突破五、迁移后新一代技术成为关键生产力。迁移后，存储成本显著下降，性能也大幅度提升，数据库由主备模式发展为支持两地三中心多活部署，生产事件处理时长从小时级缩短到分钟级。

当我们回顾这一段历程，过程虽然艰辛，但积累了宝贵的大型金融机构国产数据库迁移实践经验。

国产金融级数据库迁移实践

1.1 前期准备工作

1.1.1 数据库选型

数据库是企业IT基础设施中皇冠上的明珠，存储企业运行核心数据资产，向上支撑应用，向下屏蔽底层基础设施，在金融行业“稳定压倒一切”的大前提下，数据库的选型更为慎重，根据信通院《数据库发展研究报告（2021年）》 的描述，截止2021年6月底，国产关系型数据库厂商就高达81家，面对如此纷繁复杂的产品，如何选择合适的数据库是摆在该保险公司面前的首要问题。虽然数据库产品众多，经过审慎的评估后，最终选择了OceanBase、PolarDB等三款产品作为先期试点验证，主要选型考量点如下：

1. 是否能满足业务的平滑迁移和未来架构的演进。
   

2. 是否具备分层解耦能力，重点解除数据库与底层硬件、操作系统、中间件之间的耦合。

3. 是否有足够人才储备、资金投入，保证产品的长期演进和商业兜底。

4. 是否有广泛的行业实践案例。

5. 是否能做到完全自主研发。

6. 是否能兼容原有开发运维体系，自有技术人员能否快速掌握。

1.1.2 基础设施准备

该保险公司核心业务系统原先共计使用超过60多台IBM和HP高端小型机，超过70多台高端存储，传统集中式架构耦合性强，难以实现规模和性能的线性扩展。本次国产数据库采用机架式服务器和本地存储全面替代进口小型机及传统SAN存储架构，以满足核心系统全量迁移的云原生分布式架构改造。同时为了避免基础设施变动过大导致业务系统不稳定，采用Intel+海光+鲲鹏服务器混合部署的架构。前期仍以Intel X86为主，逐步过度到海光、鲲鹏芯片国产服务器。实现在线调整不同型号机器，解除了基础设施供应依赖。2020年9月，正式启动国产数据库迁移项目之后，从硬件环境的型号选择，到选出目标系统，进行容量规划，不到两个月的时间，从0开始完成国产数据库的硬件和操作系统适配、以及整个服务器集群的搭建。

1.1.3 迁移策略制定

该保险公司的业务经过多年的发展，业务范围覆盖全国，特色鲜明、种类繁多、关联关系错综繁杂，核心数据库迁移需要广泛调研和充分的科学论证——既要求数据库产品比照原有生产数据库的高性能和安全可靠，也需要快速实现多套系统的平滑迁移，同时解决资源弹性和数据库横向扩展的能力。因此，建立了数据库迁移实施的统一规范和标准，总体遵循评估-实现-控制-分析改进的科学方法论，开展有序迁移，并定下三大迁移策略：

1. 先平迁再做业务和架构改造升级，避免多个变量同时发生，影响业务的连续性。原有数据模型不做改造，主体改造工作由新数据库来承担。
   

2. 迁移批次以业务系统为粒度，从低负载到高负载，从外围到核心。

3. 用1年时间完成所有业务系统的数据库全量迁移改造，所有系统数据库迁移动作时间窗口只给周六、周日凌晨0点到早上6点，周末小流量验证，周一重点保障，不影响正常业务开展。

1.2 互联网核心迁移

1.2.1 业务背景

该保险公司核心虽然涉及系统众多，但总结下来主要分为：互联网核心和传统核心，中间通过类似ESB的总线机制实现异步解耦。

核心系统分类

自2016年，这家保险公司的互联网核心和传统新核心应用开始从传统单体架构向分布式微服务架构改造。到2020年，互联网核心业务系统已经拆分成了40多个微服务模块并完成Mesh化接入，互联网核心特点是：

1. 数据库系统已实现全国物理集中、逻辑集中，数据库对接的关联系统较多。
   

2. 虽然做了微服务拆分，数据库仍有一定量的存储过程，另外触发器、自定义类型、函数、外键、分区表等高级功能均有使用。

3. 因为业务特点，要服务好100多万代理人，对数据库资源弹性和性能要求更高。

因此互联网核心的数据库迁移面临的主要技术挑战是：

1. 全国集中式部署下单点故障会影响到全国。
   

2. 主数据系统作为核心业务链路中的整个保险开户入口，内部对接43个关联系统，数据规模超20TB，最大单表超50亿条数据，每天接口调用量超2000万次，是该公司单体数据库日均请求量最大的系统，因为关联系统多，且处在业务链路的核心位置，因此对数据库SQL的效率要求非常高，迁移过程不能影响原有生产系统。

3. 迁移到新的数据库平台要具备实时同步到Kafka的能力，并兼容原有格式，供下游大数据系统消费。

原有大数据消费链路

1.2.2 技术方案

• 整体选型

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

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

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

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

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

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

• 迁移方法

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

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

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

大数据同步链路改造方案

1. 增加PolarDB到Oracle的反向实时同步，原有Oracle到Kafka同步链路不变，避免数据库切换带来太大的变动 ；
2. 参考SharePlex的格式对DTS进行定制化开发改造，待验证充分后，直接替换掉SharePlex原有同步链路。

• 主要挑战

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

1. 统一管控：通过PolarStack将多台机器组成的集群进行统一管控，提供DBaaS服务；
   
2. 资源弹性：实例由原来的物理机部署，变为K8S Pod部署，更为灵活和弹性；

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

PolarDB技术架构

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

• 迁移历程

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

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

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

1.3 传统核心迁移

1.3.1 业务背景

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

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

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

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

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

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

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

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

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

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

1.3.2 技术方案

• 选型方案

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

1. 采用基于无共享（Shared-Nothing）的多副本架构，整个系统没有任何单点故障，保证系统的持续可用。
   
2. 基于LSM存储引擎技术，结合新硬件的能力，采用可扩展的分布式架构，提供高性能和扩展性。
3. 数据库针对 Oracle、MySQL 等应用最为广泛的数据库生态都给予了非常高的应用兼容性支持。
4. 虽然为分布式架构，一般也不需要应用层做相应的重新设计如指定分布键等，与原有Oracle使用习惯基本一致。
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. 始终坚持自主研发，研发人员有优秀的个人能力，清楚产品每一行代码的来龙去脉，能够快速和高质量地新增和修改代码，真正做到了自主研发。

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

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

• 迁移历程

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

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

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

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

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

1.4 全面体系化迁移

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

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

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

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

一键自动迁移过程图

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

1. 兼容性评估：明确改动范围，进行适配改造工作量评估并合理安排工作任务。
2. 负载评估：从原数据库获取SQL负载信息并在新数据库测试环境回放，验证新数据库应用后的性能。
3. 测试迁移、适配改造：进行适配改造、全量回归测试、性能测试。有条件的系统（微服务化较好、重构等），可以分批改造和实施迁移。其中，性能测试可根据迁移前的关键业务容量基线，确定测试准出标准。
4. 生产库存量、增量式迁移：对于业务连续性要求不高的系统，一般操作一次性存量方式完成数据迁移；对于业务连续性要求高的系统，采取全量+增量迁移方式，待增量数据追平后实施切换，仅需在切换时点暂停业务（分钟级）。
5. 反向回流：对于关键应用，可实施数据同步回原数据库应对未知风险。
6. 数据验证：迁移完成后进行数据准确性验证及应用验证。
7. 持续监控：对可能遇到的问题进行监控、详细评估分析。

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

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

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

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

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

正式迁移割接步骤

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

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

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

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

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

保险精算数据准备过程

1.5 主要问题总结

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

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

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

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

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

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

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

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

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

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

2.5.2 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迁移到了本地盘硬件设备上，随后也逐渐演进到两地三中心多活部署架构。

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

如果一个数据库厂商说100%兼容Oracle，保证迁移过程不出任何问题，那一定是自吹。即便做到了事前压测充分，且尽量覆盖完所有业务场景。但对于割接上线后的系统稳定性、兼容性还是要画问号。关键在于是否有及时有效的监控，以及出现问题后的快速应急手段。毕竟已经投产的应用，应急还是第一优先级。

在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%的兼容优化也是最难的，也不是短时间能一蹴而就。对于这种小概率事件，应急就成为了最后的兜底手段，在不动应用的大前提下，通过数据库灵活的绑定执行计划，是出现突发问题时比较有效和容易落地的手段。实际整个迁移过程中，对于偶发的执行计划跳变，项目组也已经驾轻就熟，没有给迁移带来意外影响。

1.6 整体效果

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

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

1. 100%数据库技术栈的安全可控，摆脱对Oracle数据库的依赖。
2. 摆脱对小型机和高端存储的依赖。
3. 促进云原生和分布式数据库应用成熟，从可用到好用并取得性能提升。
4. 数据库服务集中管控，显著降低硬件及整体运维成本。
5. 真正的实时扩缩容和高可用能力，轻松应对大促活动。

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

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

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

总结

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

这些年我们看过很多的文章都是对于数据库替换的分析和畅想，但是面对实际的大规模复杂的核心应用系统的技术平台替换，过程中还有很多在各种“分析”文章中想不到的问题，尤其对于现有运行的环境的各种适配和兼容，对应用的友好性等很多，关于这些，阿里走出了坚实的一步，积累了弥足珍贵的经验，这些都为今后的国产进程给出了很好的示范效应。

推荐阅读

点击“阅读原文”查看PolarDB 5周年更多信息