先难后易，核心系统数据库升级复盘

先易后难，这是很多人做事的方法，实践证明的确非常有效。不过，凡事都有例外，有时反其道而行之也能收到奇效。在数据库国产升级过程中太平洋保险就是先难后易，选择了从最难搞的 P17 开始，快速孵化出了对数据库的升级经验方法论。

林春是一位非常资深的数据库专家，做过 Oracle OCM 讲师，先后在中国银行、兴业银行等多家金融机构负责过数据库系统的设计、建设、运维等工作，对金融行业数据库的应用有非常丰富的经验和深入的洞察。

P17 是中国太平洋保险（以下简称太保）关联关系最为复杂、商业数据库绑定程度最深、业务影响最多的核心系统之一。但就是这样一个对太保业务至关重要的系统却被选为数据库升级的“实验品”。当然，说是“实验品”只是因为这是太保第一次对关键的核心系统进行数据库升级，而并非真的只是“实验”。实际上，由于该系统十分重要，此次数据库的升级只许成功不许失败。

从去年年底项目立项，到 12 月 18 日 P17 第一个子系统成功上线，并完成了全量数据库迁移；到今年 5 月 13 日核心系统中最难的核心交易库上线。至今，P17 核心系统已经稳定运行了 200 多天。事实证明，太保不仅顺利完成了 P17 的数据库升级，还从中收获了宝贵的数据库升级经验，为后续其他系统数据库的顺利升级打下了坚实的基础。

作为太保运维保障级别最高的核心业务系统之一，P17 已经有 10 多年的历史。它是太保旗下的产、寿、健康、长江等所有子公司客户服务系统的整合，涵盖了太保几乎所有子公司业务的服务入口功能，包括车险报案、道路救援、寿险保全受理、投保预约等等，对接周边系统 200 多个，为公司 6 地 8 个电话中心超过 2500 个坐席提供系统服务。

“P17 核心系统的数据库升级是出于太保数字化转型战略的要求。”太保数智研究院数据库首席专家林春谈及 P17 数据库升级原因时表示。

数智研究院负责太保数字化转型战略的制订以及执行，同时还承担了卡点技术的攻坚克难，确保太保在核心技术的行业领先和技术可靠。林春是数据库方向的负责人。

林春介绍，随着太保业务的不断丰富，P17 需要支持越来越多互联网类型的业务，这些业务不仅数据量大，还有瞬时高并发的特点。同时，P17 的数据库体量已经达到 30TB，还在继续增长，面临扩缩容的问题。

当然，太保决定对 P17 的数据库进行升级还有一个更长远的考虑。P17 的数据库升级复杂，太保希望通过该项目沉淀出知识和工具，为后面太保其他系统的数据库升级积累经验，帮助太保最终实现对数据库的真正自主掌控。

被称为太保最复杂的核心业务系统之一，P17 的数据库升级到底有哪些难点？ “首先，这个系统要求 7x24 小时服务，务必高可靠，而且支持高并发。比如，在一些恶劣天气情况下，可能有 2500 名坐席同时在线，需要做到秒级响应，对数据库的实时性要求很高。如果处理不好的话，可能会变成一个舆情的问题。”林春说。

当然，挑战最大的还是 P17 与 Oracle 数据库的深度绑定。林春介绍，P17 对传统集中式数据库特性使用非常深入，Oracle 数据库的所有特性几乎在这个系统中都有体现，包括自定义锁、自治事务、嵌套表、索引组织表、PLSQL 包、物化视图、DBlink、触发器、系统视图。其存储过程数量庞大，总代码量近百万行。

在真正迁移之前，需要先把这些代码找出来然后再对代码进行重写，这个工作量就不小，成本高，风险大。同时，还需要对迁移的工具和流程进行优化，因为其中有大量复杂非表对象的迁移。这个过程同样成本高，风险大。

与数据库的绑定还体现在P17集成了大量周边工具软件和应用。P17 与很多周边软件协同工作，比如 IBM Datastage、IBM Cognos 等，这些软件都利用了很多 Oracle 数据库特有的功能，更换数据库后需要对这些软件重新适配。另外，高达 30TB 的数据量也放大了上述挑战的艰巨性。

正是基于这些原因，在 P17 新数据库的选型中，对高并发、高可用的支持和对 Oracle 数据库的兼容能力成为非常重要的考量指标。同时，P17中还有一些报表和数据分析的需求，这就要求新数据库不仅需要OLTP的能力，还需要有一定的OLAP的能力。另外，厂商的技术实力一定要足够强，具有技术兜底的能力，这一点在太保看来也非常关键。

显然，在市场上能够符合太保要求、足以支撑 P17 这样核心业务系统的国产数据库并不多，特别是这种能力需要已在众多金融场景中得到验证。太保从功能、性能、易用性、完整性、可移植性、可靠性、扩展性、安全性等方面对市场上的数据库进行了全方位评估，最后选择了 OceanBase。

2022 年年初项目启动，太保与 OceanBase 厂商组成联合攻坚组，用国产分布式架构彻底取代传统商用主备架构，其中解除数据库与操作系统、中间件之间的耦合是重点，而应用改造问题的识别则是重中之重，因为识别效率的高低直接影响项目的成本和工期。

好在“指南针”等工具帮了大忙，它让识别的成本降低了 60%。“指南针”是太保自研的数据库应用改造预评估工具，它能够对 Oracle 数据库进行预扫描，包括近 20 个检查大类近 200 多个检查项，评估项全面、有效、高效，并初步给出问题原因、代码位置。它还有一个特色，就是能够辅助识别冗余大表、冗余索引，有助“数据库减负”。除了“指南针”外，P17 项目组还研发了索引建议助手和优化辅助工具等，也大大提高技术人员的效率。

对于 P17 系统集成的中间件和周边软件也进行了与 OceanBase 的重新适配。有些软件因为与 Oracle 绑定太紧就替换为对应的国产软件，比如，用帆软替换了 Cognos。有些无法完全替换也进行了功能剥离，比如 DataStage 中的加载功能用 OceanBase 的加载工具替代，调度功能也拆分出来用 Java 进行了改造。

当然，有些与数据库的绑定实在太深入，就需要技术人员来甄别，这也是最耗时和考验项目组技术实力的地方。

P17 项目就遇到了一个卡点，为此攻坚了半个月，就是在调用 hibernate 的框架时，出现了一个无法发现 V$SESSION 的报错。当时问题 SQL 识别不出来，后面在 Oracle 侧调用这个问题模块才定位出了这个 SQL。在对这个 SQL 进行分析后，判断这是一个语义级的报错，技术人员设法构造了 2 个虚拟的表和虚拟视图，其中没有任何数据，把它转化成了一个 SQL 层面的 NO_DATA_FOUND 异常。当抛出 NO_DATA_FOUND 的异常时也把这个模块的名字抛出来了，发现这是一个触发器的模块，后面技术人员据此定位到这个触发器模块，再对它进行了优化改造，才解决了这个问题。

在这个过程中还遇到了操作系统及内存方面的问题。技术人员通过对操作系统的底层进行跟踪，抓取了一些关键数据，发现问题出在 OceanBase 为了兼容 Oracle 数据库某些功能特性而开发的一个自定义函数，找到症结之后这个问题很快就解决了。

在此过程中，太保一直强调的厂商技术兜底作用也体现出了重要性。比如，定位到内存存在的问题之后，OceanBase 一天后就给出了修复方案和补丁包，这也让林春印象深刻。

核心客服系统 P17 自 2022 年底上线，实现了业务成功交易率不低于 99.99%、交易总平均响应时间小于 1 秒、整体并发量 1500 人等预期指标。P17 在保持高性能、高可用能力的同时，还为太保带来了成本的节约和运维的方便等诸多好处，这些都为后续业务发展奠定了坚实的技术基础。

数据库软硬件成本的节约是本次数据库升级后最为明显的好处。林春介绍，P17 数据库通过 OceanBase 的高级压缩技术，结合“数据库瘦身”，存储容量节省 80% 以上，同时，分析型数据加工处理能力提升 10 倍，升级后的应用系统弹性扩缩容、处理速度、数据加工能力均实现大幅提升。

尤为值得一提的是，数据库瘦身带来的不只是存储空间的节省，还有计算能力的节省、网络的节省以及其他关联收益。比如，原来由于数据量太大不得不考虑进行分库分表，而现在通过瘦身就无需考虑这个问题。类似的，在进行数据迁移和备份这些操作时，10TB 与 5TB 或者 1TB，在执行难度上也有很大不同。

当然，太保的“数据库瘦身”并不单靠 OceanBase 的压缩功能。这次数据库的升级也不是简单的一对一替换，而是对数据库使用的一次梳理和对应用的一次改造，借此进一步推动了数据库使用的规范化。

林春介绍，过去由于 Oracle 数据库在市场上的占有率颇高，在使用中有很多不当之处。趁此对“瓶瓶罐罐”整理的机会，太保对不合理之处进行了调整。比如，原来有个高达 20TB 的保单系统，其中有字段存储的是大对象。在改造过程中，太保将这些大对象转移到对象存储中，原来的数据库中只是存放存储路径，调整后的数据库不到 2TB，应用程序的性能也得到了极大提升。

另外，由于 OceanBase 可以同时兼容 MySQL 和 Oracle 版，这样两类系数据库都可以迁移到 OceanBase 中统一进行纳管，提高了运维效率。

除了上述有形的收益，P17 项目另一个非常重要的收益是为后续的数据库升级积累了经验、培养了人才，这些对于太保的数字化转型非常重要，这也是当初太保甘愿冒险选择 P17“开刀”的重要原因。

据悉，为配合数据库的升级，太保完成了 1127 人的国产数据库的认证。今天在太保不管是研发侧还是运维侧都已经普遍掌握了国产数据库的相关知识，这笔“财富”也是相当难得。

同样宝贵的还有在 P17 项目中打磨出来的工具和方法论。比如，“指南针”这个工具现在已经在太保集团，包括产险、寿险、科技，还有长江养老以及健康险等系统得到应用，对迁移成本的降低起到了非常关键的作用。

随着数据库迁移的完成，今天 P17 系统的工作重点已经转向了日常运维。林春说，对于已经熟悉集中式数据库的太保运维人员这也是一个不小的挑战，因为分布式数据库对运维人员的能力要求比原来更高，他要具备全链路快速问题诊断的能力。好在 AIGC 技术的不断进步，智能化诊断工具的能力越来越强大，一定程度上扮演数字化助手的角色。

不过，林春提醒说，有些工作是 AI 替代不了的，比如对业务的理解，这也是 DBA 的核心价值所在，DBA 也需要对资深能力升级。

“自主掌控，最核心的就是人对产品和技术能力的掌握。用只是基础，更重要的是要在用的过程中沉淀出本地化的知识体系，能真正把产品用好，这才是真正的自主掌控。P17 系统的成功升级加速了太保的这一进程。”林春说。