首批通过分布式安全可靠测评，为关键业务系统打造
方案概述
保险机构的寿险核心业务系统很多都有超过 10 年甚至 20 年的历史，这些业务代码完全推翻重构难度和风险极高，可以说既是宝贵财富也是沉重负担。过去，寿险核心系统基本 90% 以上使用 Oracle 数据库，面对业务场景复杂、数据量大、突发流量高的业务特点，传统集中式数据库在容量、性能、云化、多模等方面都愈发力不从心。OceanBase 已经在头部保险公司如中国人寿、中国太平洋保险等核心业务系统大量使用，支撑寿险业务发展。
业务挑战
业务场景复杂
保险寿险业务模式更复杂，业务流程更长，复杂查询更多。例如，寿险业务通常会有数分钟的长流程事务，各类多层次嵌套子查询、关联子查询、多表关联比比皆是。
业务数据量大
寿险业务从客户开户、参保以来所有的历史数据都是“热数据”，要参与计算，存量数据生命周期长，数据量的增长对业务性能有明显影响。
业务突发流量高
保险寿险业务因其行业特性，经常有开门红这样的促销活动，虽然日常资源使用率不高，但某些特定日期业务量突增，可能达到平常的 10 倍以上甚至更高。
应用重度依赖 Oracle 特殊特性，改造成本高
绝大部分寿险核心业务系统以 Oracle 为主，并且大量业务功能在数据库中通过存储过程实现，深度使用 Oracle PL/SQL 能力和多种 Oracle 特有的语法特性，要求在替换过程中需要尽量减少代码改造量，降低成本，同时减少迁移风险。
方案架构
寿险业务的核心系统通常会将传统集中式、竖井式的业务处理功能进行微服务拆分，包括契约、核保、保全、理赔、保单服务等关键业务模块，上游通过应用服务层接入到前端应用。这种架构可以快速响应市场变化，同时利用 OceanBase 的高可用和容灾能力保证寿险整体业务的连续性。
方案优势
面对复杂 SQL、大数据量的性能挑战
OceanBase 在大多数场景，均能获得和 Oracle 相似的性能；在某些特定场景，可以通过并发获得比 Oracle 更佳的性能。甚至，在 OceanBase 中做优化时，可以直接参考 Oracle 的执行计划，将之以 hint 的方式直接应用于 OceanBase 中，用于固化执行计划不准的 SQL 语句，大大降低性能问题带来的生产运行风险。
面对突发流量的挑战
如果按照流量最高峰来配置集群资源，显然是一种极大的资源浪费。在长期支持“双11”的过程中，OceanBase 锻炼出透明扩缩容的能力。在促销活动前，可以提前将准备好的物理服务器或云上 ECS 动态扩容到集群中；活动结束后，再缩容将机器归还，从容应对业务流量高峰。
面对重度依赖 Oracle 的挑战
OceanBase 高度兼容 Oracle，支持 Oracle 中绝大多数用法，应用只需很小改动，甚至无需改动，便可迁移至 OceanBase，尤其是具备平滑迁移 Oracle 存储过程和常见特有语法特性的能力，为企业节约大量的人力和时间成本。
