一、前言

在國(guó)家層面提出加快建設(shè)科技強(qiáng)國(guó)，實(shí)現(xiàn)高水平科技自立自強(qiáng)的大背景之下，某超大型保險(xiǎn)（集團(tuán)）公司深入推進(jìn)數(shù)字化轉(zhuǎn)型，緊隨先鋒技術(shù)發(fā)展趨勢(shì)，前瞻性布局啟動(dòng)IT架構(gòu)分布式改造轉(zhuǎn)型，并于21年9月圓滿實(shí)現(xiàn)了最后一個(gè)規(guī)模高達(dá)20TB+核心數(shù)據(jù)庫(kù)的全面遷移改造工作，也為后續(xù)向云原生多活架構(gòu)演進(jìn)打下了堅(jiān)實(shí)的基礎(chǔ)。該數(shù)據(jù)庫(kù)國(guó)產(chǎn)遷移項(xiàng)目成功上線，樹立了金融行業(yè)踐行科技強(qiáng)國(guó)的標(biāo)桿實(shí)踐，也是對(duì)國(guó)家科技自立自強(qiáng)戰(zhàn)略以及國(guó)產(chǎn)技術(shù)的履責(zé)擔(dān)當(dāng)；更推動(dòng)了整個(gè)國(guó)內(nèi)數(shù)據(jù)庫(kù)管理與應(yīng)用體系科技生態(tài)建設(shè)和科技產(chǎn)業(yè)鏈的快速成熟。

對(duì)于保險(xiǎn)行業(yè)而言，短時(shí)業(yè)務(wù)并發(fā)壓力雖沒有互聯(lián)網(wǎng)企業(yè)那么大，但是在業(yè)務(wù)復(fù)雜性和對(duì)數(shù)據(jù)庫(kù)專有特性的依賴程度上，都要遠(yuǎn)大于互聯(lián)網(wǎng)企業(yè)。保險(xiǎn)業(yè)務(wù)的處理更為復(fù)雜，單一業(yè)務(wù)要多個(gè)系統(tǒng)完成，調(diào)用鏈比銀行和互聯(lián)網(wǎng)業(yè)務(wù)更長(zhǎng)、更復(fù)雜，確保復(fù)雜集合大交易量的穩(wěn)定是保險(xiǎn)業(yè)務(wù)數(shù)據(jù)庫(kù)國(guó)產(chǎn)的挑戰(zhàn)。由于金融機(jī)構(gòu)對(duì)業(yè)務(wù)連續(xù)性和數(shù)據(jù)準(zhǔn)確性的嚴(yán)苛要求，在傳統(tǒng)頭部金融機(jī)構(gòu)中始終沒能有一家完成國(guó)產(chǎn)數(shù)據(jù)庫(kù)全面遷移，直到這家保險(xiǎn)公司成功實(shí)施，并取得了五個(gè)突破。

1）突破一：遷移時(shí)間短。從2020年9月到2021年9月，僅用時(shí)一年即完成遷移， 而傳統(tǒng)金融機(jī)構(gòu)還沒有實(shí)現(xiàn)過(guò)如此大規(guī)模的核心系統(tǒng)全量遷移。

2）突破二：遷移規(guī)模破紀(jì)錄。一年內(nèi)完成了包括傳統(tǒng)核心、互聯(lián)網(wǎng)核心、個(gè)險(xiǎn)銷售、團(tuán)險(xiǎn)銷售、經(jīng)營(yíng)管理、客服管理、大數(shù)據(jù)在內(nèi)的近百個(gè)業(yè)務(wù)系統(tǒng)在線Oracle數(shù)據(jù)庫(kù)的全量搬遷工作，遷移數(shù)據(jù)規(guī)模超400TB、數(shù)據(jù)量超千億，單庫(kù)數(shù)據(jù)規(guī)模超20TB。

3）突破三：遷移全程同時(shí)保障了業(yè)務(wù)連續(xù)性和數(shù)據(jù)準(zhǔn)確性。整個(gè)遷移過(guò)程無(wú)一例回切，上線后近一年來(lái)，系統(tǒng)穩(wěn)定運(yùn)行，并歷經(jīng)2021年完整周期的“業(yè)務(wù)大考”，經(jīng)受住了開門紅高峰TPS 5萬(wàn)+、QPS 21萬(wàn)+和包括精算在內(nèi)的所有業(yè)務(wù)環(huán)節(jié)的嚴(yán)苛考驗(yàn)，完全滿足生產(chǎn)需要，實(shí)現(xiàn)國(guó)產(chǎn)數(shù)據(jù)庫(kù)從可用到好用的跨越。

4）突破四：遷移后實(shí)現(xiàn)技術(shù)100%自主創(chuàng)新?；谕耆匝袆?chuàng)新的國(guó)產(chǎn)數(shù)據(jù)庫(kù)，遷移過(guò)程中版本升級(jí)持續(xù)發(fā)版共計(jì)50余次，最長(zhǎng)需求解決時(shí)間2個(gè)月（Pro*C+Tuxedo）。同時(shí)通過(guò)系統(tǒng)培訓(xùn)與交流實(shí)現(xiàn)累計(jì)超過(guò)500位員工的數(shù)據(jù)庫(kù)專業(yè)考試認(rèn)證，實(shí)現(xiàn)了數(shù)據(jù)庫(kù)的全面自主掌控能力。

5）突破五：遷移后新一代技術(shù)成為關(guān)鍵生產(chǎn)力。遷移后，存儲(chǔ)成本顯著下降，性能也大幅度提升，數(shù)據(jù)庫(kù)由主備模式發(fā)展為支持兩地三中心多活部署，生產(chǎn)事件處理時(shí)長(zhǎng)從小時(shí)級(jí)縮短到分鐘級(jí)。

當(dāng)我們回顧這一段歷程，過(guò)程雖然艱辛，但積累了寶貴的大型金融機(jī)構(gòu)國(guó)產(chǎn)數(shù)據(jù)庫(kù)遷移實(shí)踐經(jīng)驗(yàn)。

二、國(guó)產(chǎn)金融級(jí)數(shù)據(jù)庫(kù)遷移實(shí)踐

1、前期準(zhǔn)備工作

1）數(shù)據(jù)庫(kù)選型

數(shù)據(jù)庫(kù)是企業(yè)IT基礎(chǔ)設(shè)施中皇冠上的明珠，存儲(chǔ)企業(yè)運(yùn)行核心數(shù)據(jù)資產(chǎn)，向上支撐應(yīng)用，向下屏蔽底層基礎(chǔ)設(shè)施，在金融行業(yè)“穩(wěn)定壓倒一切”的大前提下，數(shù)據(jù)庫(kù)的選型更為慎重，根據(jù)信通院《數(shù)據(jù)庫(kù)發(fā)展研究報(bào)告（2021年）》 的描述，截止2021年6月底，國(guó)產(chǎn)關(guān)系型數(shù)據(jù)庫(kù)廠商就高達(dá)81家，面對(duì)如此紛繁復(fù)雜的產(chǎn)品，如何選擇合適的數(shù)據(jù)庫(kù)是擺在該保險(xiǎn)公司面前的首要問題。雖然數(shù)據(jù)庫(kù)產(chǎn)品眾多，經(jīng)過(guò)審慎的評(píng)估后，最終選擇了OceanBase、PolarDB等三款產(chǎn)品作為先期試點(diǎn)驗(yàn)證，主要選型考量點(diǎn)如下：

是否能滿足業(yè)務(wù)的平滑遷移和未來(lái)架構(gòu)的演進(jìn)。

是否具備分層解耦能力，重點(diǎn)解除數(shù)據(jù)庫(kù)與底層硬件、操作系統(tǒng)、中間件之間的耦合。

是否有足夠人才儲(chǔ)備、資金投入，保證產(chǎn)品的長(zhǎng)期演進(jìn)和商業(yè)兜底。

是否有廣泛的行業(yè)實(shí)踐案例。

是否能做到完全自主研發(fā)。

是否能兼容原有開發(fā)運(yùn)維體系，自有技術(shù)人員能否快速掌握。

2）基礎(chǔ)設(shè)施準(zhǔn)備

該保險(xiǎn)公司核心業(yè)務(wù)系統(tǒng)原先共計(jì)使用超過(guò)60多臺(tái)IBM和HP高端小型機(jī)，超過(guò)70多臺(tái)高端存儲(chǔ)，傳統(tǒng)集中式架構(gòu)耦合性強(qiáng)，難以實(shí)現(xiàn)規(guī)模和性能的線性擴(kuò)展。本次國(guó)產(chǎn)數(shù)據(jù)庫(kù)采用機(jī)架式服務(wù)器和本地存儲(chǔ)全面替代進(jìn)口小型機(jī)及傳統(tǒng)SAN存儲(chǔ)架構(gòu)，以滿足核心系統(tǒng)全量遷移的云原生分布式架構(gòu)改造。同時(shí)為了避免基礎(chǔ)設(shè)施變動(dòng)過(guò)大導(dǎo)致業(yè)務(wù)系統(tǒng)不穩(wěn)定，采用Intel+海光+鯤鵬服務(wù)器混合部署的架構(gòu)。前期仍以Intel X86為主，逐步過(guò)度到海光、鯤鵬芯片國(guó)產(chǎn)服務(wù)器。實(shí)現(xiàn)在線調(diào)整不同型號(hào)機(jī)器，解除了基礎(chǔ)設(shè)施供應(yīng)依賴。2020年9月，正式啟動(dòng)國(guó)產(chǎn)數(shù)據(jù)庫(kù)遷移項(xiàng)目之后，從硬件環(huán)境的型號(hào)選擇，到選出目標(biāo)系統(tǒng)，進(jìn)行容量規(guī)劃，不到兩個(gè)月的時(shí)間，從0開始完成國(guó)產(chǎn)數(shù)據(jù)庫(kù)的硬件和操作系統(tǒng)適配、以及整個(gè)服務(wù)器集群的搭建。

3）遷移策略制定

該保險(xiǎn)公司的業(yè)務(wù)經(jīng)過(guò)多年的發(fā)展，業(yè)務(wù)范圍覆蓋全國(guó)，特色鮮明、種類繁多、關(guān)聯(lián)關(guān)系錯(cuò)綜繁雜，核心數(shù)據(jù)庫(kù)遷移需要廣泛調(diào)研和充分的科學(xué)論證——既要求數(shù)據(jù)庫(kù)產(chǎn)品比照原有生產(chǎn)數(shù)據(jù)庫(kù)的高性能和安全可靠，也需要快速實(shí)現(xiàn)多套系統(tǒng)的平滑遷移，同時(shí)解決資源彈性和數(shù)據(jù)庫(kù)橫向擴(kuò)展的能力。因此，建立了數(shù)據(jù)庫(kù)遷移實(shí)施的統(tǒng)一規(guī)范和標(biāo)準(zhǔn)，總體遵循評(píng)估-實(shí)現(xiàn)-控制-分析改進(jìn)的科學(xué)方法論，開展有序遷移，并定下三大遷移策略：

• 先平遷再做業(yè)務(wù)和架構(gòu)改造升級(jí)，避免多個(gè)變量同時(shí)發(fā)生，影響業(yè)務(wù)的連續(xù)性。原有數(shù)據(jù)模型不做改造，主體改造工作由新數(shù)據(jù)庫(kù)來(lái)承擔(dān)。
• 遷移批次以業(yè)務(wù)系統(tǒng)為粒度，從低負(fù)載到高負(fù)載，從外圍到核心。
• 用1年時(shí)間完成所有業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫(kù)全量遷移改造，所有系統(tǒng)數(shù)據(jù)庫(kù)遷移動(dòng)作時(shí)間窗口只給周六、周日凌晨0點(diǎn)到早上6點(diǎn)，周末小流量驗(yàn)證，周一重點(diǎn)保障，不影響正常業(yè)務(wù)開展。

2、互聯(lián)網(wǎng)核心遷移

1）業(yè)務(wù)背景

該保險(xiǎn)公司核心雖然涉及系統(tǒng)眾多，但總結(jié)下來(lái)主要分為：互聯(lián)網(wǎng)核心和傳統(tǒng)核心，中間通過(guò)類似ESB的總線機(jī)制實(shí)現(xiàn)異步解耦。

核心系統(tǒng)分類

自2016年，這家保險(xiǎn)公司的互聯(lián)網(wǎng)核心和傳統(tǒng)新核心應(yīng)用開始從傳統(tǒng)單體架構(gòu)向分布式微服務(wù)架構(gòu)改造。到2020年，互聯(lián)網(wǎng)核心業(yè)務(wù)系統(tǒng)已經(jīng)拆分成了40多個(gè)微服務(wù)模塊并完成Mesh化接入，互聯(lián)網(wǎng)核心特點(diǎn)是：

• 數(shù)據(jù)庫(kù)系統(tǒng)已實(shí)現(xiàn)全國(guó)物理集中、邏輯集中，數(shù)據(jù)庫(kù)對(duì)接的關(guān)聯(lián)系統(tǒng)較多。
• 雖然做了微服務(wù)拆分，數(shù)據(jù)庫(kù)仍有一定量的存儲(chǔ)過(guò)程，另外觸發(fā)器、自定義類型、函數(shù)、外鍵、分區(qū)表等高級(jí)功能均有使用。
• 因?yàn)闃I(yè)務(wù)特點(diǎn)，要服務(wù)好100多萬(wàn)代理人，對(duì)數(shù)據(jù)庫(kù)資源彈性和性能要求更高。

因此互聯(lián)網(wǎng)核心的數(shù)據(jù)庫(kù)遷移面臨的主要技術(shù)挑戰(zhàn)是：

• 全國(guó)集中式部署下單點(diǎn)故障會(huì)影響到全國(guó)。
• 主數(shù)據(jù)系統(tǒng)作為核心業(yè)務(wù)鏈路中的整個(gè)保險(xiǎn)開戶入口，內(nèi)部對(duì)接43個(gè)關(guān)聯(lián)系統(tǒng)，數(shù)據(jù)規(guī)模超20TB，最大單表超50億條數(shù)據(jù)，每天接口調(diào)用量超2000萬(wàn)次，是該公司單體數(shù)據(jù)庫(kù)日均請(qǐng)求量最大的系統(tǒng)，因?yàn)殛P(guān)聯(lián)系統(tǒng)多，且處在業(yè)務(wù)鏈路的核心位置，因此對(duì)數(shù)據(jù)庫(kù)SQL的效率要求非常高，遷移過(guò)程不能影響原有生產(chǎn)系統(tǒng)。
• 遷移到新的數(shù)據(jù)庫(kù)平臺(tái)要具備實(shí)時(shí)同步到Kafka的能力，并兼容原有格式，供下游大數(shù)據(jù)系統(tǒng)消費(fèi)。

原有大數(shù)據(jù)消費(fèi)鏈路

2）技術(shù)方案

①整體選型

針對(duì)以上技術(shù)挑戰(zhàn)，選擇了和原有Oracle RAC架構(gòu)更接近的PolarDB作為互聯(lián)網(wǎng)核心數(shù)據(jù)庫(kù)的替換，PolarDB作為新一代云原生數(shù)據(jù)庫(kù)主要特點(diǎn)如下：

• 計(jì)算與存儲(chǔ)分離，使用共享分布式存儲(chǔ)，滿足業(yè)務(wù)彈性擴(kuò)展的需求。極大降低用戶的存儲(chǔ)成本。
• 讀寫分離，一寫多讀，PolarDB引擎采用多節(jié)點(diǎn)集群的架構(gòu)，集群中有一個(gè)主節(jié)點(diǎn)（可讀可寫）和至少一個(gè)只讀節(jié)點(diǎn)（最大支持15個(gè)只讀節(jié)點(diǎn)）。寫操作發(fā)送到主節(jié)點(diǎn)，讀操作均衡地分發(fā)到多個(gè)只讀節(jié)點(diǎn)，實(shí)現(xiàn)自動(dòng)的讀寫分離。
• 基于K8S形態(tài)部署，提供分鐘級(jí)的配置升降級(jí)，秒級(jí)的故障恢復(fù)，全局?jǐn)?shù)據(jù)一致性和完整的數(shù)據(jù)備份容災(zāi)服務(wù)。
• 集中式架構(gòu)，不需要進(jìn)行分布式架構(gòu)相關(guān)考慮設(shè)計(jì)，和原有使用習(xí)慣保持一致，性能不低于原有Oracle數(shù)據(jù)庫(kù)。
• 高度兼容Oracle，應(yīng)用基本上不需要做SQL語(yǔ)法調(diào)整。

②遷移方法

為了避免對(duì)原有生產(chǎn)業(yè)務(wù)造成影響且保證遷移數(shù)據(jù)的嚴(yán)格一致性，采用了DTS全量+增量的方式，對(duì)于數(shù)據(jù)規(guī)模超大的Oracle集群，如客戶主數(shù)據(jù)系統(tǒng)，提前2周啟動(dòng)數(shù)據(jù)遷移鏈路，在全量數(shù)據(jù)遷移之前DTS會(huì)啟動(dòng)增量數(shù)據(jù)拉取模塊，增量數(shù)據(jù)拉取模塊會(huì)拉取源實(shí)例的增量更新數(shù)據(jù)，并解析、封裝、存儲(chǔ)在本地存儲(chǔ)中。當(dāng)全量數(shù)據(jù)遷移完成后，DTS會(huì)啟動(dòng)增量日志回放模塊，增量日志回放模塊會(huì)從增量日志讀取模塊中獲取增量數(shù)據(jù)，經(jīng)過(guò)反解析、過(guò)濾、封裝后遷移到目標(biāo)實(shí)例，通過(guò)目標(biāo)端主鍵保證數(shù)據(jù)的唯一性。應(yīng)用切換成功后，從應(yīng)用接口的響應(yīng)速度上看，性能比Oracle提升約30%。到2020年底，雙方攜手完成了互聯(lián)網(wǎng)核心所有模塊的遷移，包括服務(wù)超百萬(wàn)代理人的出單系統(tǒng)APP，和注冊(cè)用戶超1億的壽險(xiǎn)APP、客戶主數(shù)據(jù)等共計(jì)40多個(gè)業(yè)務(wù)系統(tǒng)。

互聯(lián)網(wǎng)核心整體遷移技術(shù)方案

為了減少遷移過(guò)程中對(duì)下游大數(shù)據(jù)消費(fèi)造成影響，到大數(shù)據(jù)的同步鏈路改造采用了2步走的策略。

大數(shù)據(jù)同步鏈路改造方案

1. 增加PolarDB到Oracle的反向?qū)崟r(shí)同步，原有Oracle到Kafka同步鏈路不變，避免數(shù)據(jù)庫(kù)切換帶來(lái)太大的變動(dòng)；
2. 參考SharePlex的格式對(duì)DTS進(jìn)行定制化開發(fā)改造，待驗(yàn)證充分后，直接替換掉SharePlex原有同步鏈路。

③主要挑戰(zhàn)

遷移完成后，PolarDB作為互聯(lián)網(wǎng)核心數(shù)據(jù)庫(kù)，需要穩(wěn)定支撐起2021年一季度業(yè)務(wù)沖刺。而最前端的出單系統(tǒng)是整個(gè)性能壓力的集中點(diǎn)，并且由于做了微服務(wù)化改造拆成了30多個(gè)模塊，分散在了多個(gè)數(shù)據(jù)庫(kù)中，任何一個(gè)數(shù)據(jù)庫(kù)都可能存在被打爆的風(fēng)險(xiǎn)，在遷移到PolarDB之前是拆在多個(gè)Oracle RAC集群中，依靠?jī)?nèi)部開發(fā)的數(shù)據(jù)庫(kù)監(jiān)控完成多個(gè)Oracle集群的監(jiān)控，遷到PolarDB之后整體架構(gòu)將更適應(yīng)業(yè)務(wù)彈性的挑戰(zhàn)：

• 統(tǒng)一管控：通過(guò)PolarStack將多臺(tái)機(jī)器組成的集群進(jìn)行統(tǒng)一管控，提供DBaaS服務(wù)；
• 資源彈性：實(shí)例由原來(lái)的物理機(jī)部署，變?yōu)镵8S Pod部署，更為靈活和彈性；
• 讀寫分離：通過(guò)智能代理服務(wù)實(shí)現(xiàn)自動(dòng)的讀寫分離，實(shí)現(xiàn)分鐘級(jí)擴(kuò)容，故障場(chǎng)景下自動(dòng)切換，應(yīng)用不需要做任何調(diào)整。

PolarDB技術(shù)架構(gòu)

業(yè)務(wù)沖刺當(dāng)天經(jīng)過(guò)了三個(gè)高峰時(shí)間點(diǎn)：12:00、17:00、21:00，每小時(shí)出單量和全天出單量進(jìn)入了歷史的前三位，高峰期出單筆數(shù)達(dá)到9000筆/s。

④遷移歷程

2020年9月，互聯(lián)網(wǎng)核心首批應(yīng)用模塊遷移到PolarDB，整個(gè)適配過(guò)程不到一個(gè)月。此后，互聯(lián)網(wǎng)核心各個(gè)模塊就開始了大規(guī)模的遷移。

2020年11月，PolarDB完成了最大的單庫(kù)客戶主數(shù)據(jù)遷移。

2021年1月底，PolarDB作為互聯(lián)網(wǎng)核心出單系統(tǒng)的數(shù)據(jù)庫(kù)，穩(wěn)定支撐起該保險(xiǎn)公司2021年一季度業(yè)務(wù)沖刺。

3、傳統(tǒng)核心遷移

1）業(yè)務(wù)背景

該大型保險(xiǎn)公司的傳統(tǒng)核心系統(tǒng)歷史悠久，既有1998年之前建成的，也有2004到2008年間建成的，時(shí)間跨度長(zhǎng)，數(shù)據(jù)量異常龐大，單個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)規(guī)模甚至超過(guò)20TB。更具挑戰(zhàn)的是，很多老核心按省市做了拆分，要分省市分別進(jìn)行遷移，單一老核心系統(tǒng)需要遷移的數(shù)據(jù)庫(kù)可能就要多達(dá)36個(gè)。傳統(tǒng)核心總體來(lái)說(shuō)可以分為三類系統(tǒng)：

• 第一類：2016、2017年基于Java技術(shù)棧開發(fā)的新核心系統(tǒng)，大概有13個(gè)。
• 第二類：分別在1998年之前，2004到2008年間建成的老核心系統(tǒng)，大概有6個(gè)。
• 第三類：一些可能要下線的，不在此次數(shù)據(jù)庫(kù)遷移范圍內(nèi)的系統(tǒng)。

這些傳統(tǒng)核心的數(shù)據(jù)庫(kù)當(dāng)時(shí)面臨的主要技術(shù)挑戰(zhàn)是：

• 系統(tǒng)關(guān)聯(lián)關(guān)系龐雜，既有保單平臺(tái)管理系統(tǒng)也有資金類系統(tǒng)，系統(tǒng)間關(guān)系難以梳理。
• 既有物理和邏輯集中的新核心，也有物理集中，邏輯分離的老核心，其中老核心分省部署，每個(gè)省都會(huì)有一套數(shù)據(jù)庫(kù)，遷移工作量巨大。
• 對(duì)Oracle專有特性依賴較多，大量使用存儲(chǔ)過(guò)程、觸發(fā)器、自定義類型、函數(shù)、外鍵等。更為挑戰(zhàn)的是老核心大量使用Pro*C（SQL嵌入式C程序）和Tuxedo（Oracle中間件做分布式事務(wù)處理）做保單過(guò)程處理，僅某年金系統(tǒng)涉及到的Pro*C程序就有1500多個(gè)，約140萬(wàn)行代碼，業(yè)務(wù)短時(shí)間難以改造。
• 單庫(kù)體量非常大，超過(guò)10TB的就有6個(gè)，最大單庫(kù)規(guī)模超20TB，停機(jī)窗口短暫。
• 交易量大，每天數(shù)據(jù)庫(kù)調(diào)用幾十億次，還有大量復(fù)雜集合類精算和結(jié)算類交易。

2）技術(shù)方案

①選型方案

針對(duì)以上技術(shù)挑戰(zhàn)，選擇了分布式數(shù)據(jù)庫(kù)OceanBase作為傳統(tǒng)核心的替換，OceanBase數(shù)據(jù)庫(kù)主要特點(diǎn)如下：

• 采用基于無(wú)共享（Shared-Nothing）的多副本架構(gòu)，整個(gè)系統(tǒng)沒有任何單點(diǎn)故障，保證系統(tǒng)的持續(xù)可用。
• 基于LSM存儲(chǔ)引擎技術(shù)，結(jié)合新硬件的能力，采用可擴(kuò)展的分布式架構(gòu)，提供高性能和擴(kuò)展性。
• 數(shù)據(jù)庫(kù)針對(duì)Oracle、MySQL等應(yīng)用最為廣泛的數(shù)據(jù)庫(kù)生態(tài)都給予了非常高的應(yīng)用兼容性支持。
• 雖然為分布式架構(gòu)，一般也不需要應(yīng)用層做相應(yīng)的重新設(shè)計(jì)如指定分布鍵等，與原有Oracle使用習(xí)慣基本一致。
• OceanBase數(shù)據(jù)庫(kù)完全自主研發(fā)，不依賴外部開源代碼，真正做到自主研發(fā)。

②遷移方法

針對(duì)傳統(tǒng)核心復(fù)雜的數(shù)據(jù)庫(kù)情況進(jìn)行全面驗(yàn)證，最終形成了140頁(yè)的遷移操作手冊(cè)和詳細(xì)的割接行事歷，為后續(xù)系統(tǒng)的遷移和大面積推廣積累了寶貴的經(jīng)驗(yàn)，并形成了標(biāo)準(zhǔn)的遷移割接方案。整體遷移方法過(guò)程如下，從基礎(chǔ)環(huán)境準(zhǔn)備-遷移過(guò)程演練-正式割接-監(jiān)控運(yùn)維等四大環(huán)節(jié)進(jìn)行逐項(xiàng)拆解，落實(shí)到人，精確到分。

數(shù)據(jù)庫(kù)整體遷移割接流程

對(duì)于規(guī)模較大Oracle數(shù)據(jù)庫(kù)的遷移，我們總結(jié)了如下四點(diǎn)幫助提升遷移效率：

• 冷熱數(shù)據(jù)分離

一般的業(yè)務(wù)庫(kù)數(shù)據(jù)中，數(shù)據(jù)具有自己的生命周期，數(shù)據(jù)的高頻訪問具有冷熱特點(diǎn)。比如，流水表歷史數(shù)據(jù)，日志表歷史數(shù)據(jù)除了在審計(jì)回查場(chǎng)景之外，訪問很少甚至不訪問，但是通常這部分?jǐn)?shù)據(jù)都會(huì)比較大，數(shù)據(jù)遷移的開銷會(huì)比較高，造成數(shù)據(jù)遷移時(shí)間的延長(zhǎng)。針對(duì)該部分?jǐn)?shù)據(jù)，我們可以預(yù)先對(duì)這部分?jǐn)?shù)據(jù)進(jìn)行歸檔備份，然后采用靜態(tài)遷移或者利用OMS工具全量遷移單獨(dú)遷移。

• LOB類型數(shù)據(jù)

Oracle數(shù)據(jù)表行LOB類型空間占用較大，每一批次的數(shù)據(jù)拉取大小會(huì)在原始行的基礎(chǔ)上有顯著增加。相比無(wú)LOB數(shù)據(jù)類型，對(duì)OMS端內(nèi)存需求有數(shù)倍的需求，因此，優(yōu)化的策略是單獨(dú)對(duì)LOB類型的表建立新的鏈路，采用較小的并發(fā)，防范JVM OOM的風(fēng)險(xiǎn)，同時(shí)，為了提高整體遷移的速度，進(jìn)行多鏈路并行遷移。

• 無(wú)LOB類型數(shù)據(jù)

相對(duì)于LOB類型數(shù)據(jù)，無(wú)LOB數(shù)據(jù)類型的表的遷移，單位遷移批次的大小較小且穩(wěn)定，內(nèi)存需求可控，并發(fā)度可適度加大，提高遷移速度。所以，對(duì)該部分?jǐn)?shù)據(jù)可使用較高的并發(fā)度單鏈路或多鏈路遷移。

• 多個(gè)大庫(kù)遷移鏈路通過(guò)不同OMS并發(fā)遷移

單臺(tái)OMS可以支持多個(gè)遷移任務(wù)，但是共享數(shù)據(jù)網(wǎng)絡(luò)出口。鑒于大庫(kù)數(shù)據(jù)的持續(xù)拉取，可以將大庫(kù)的遷移分散至不同OMS節(jié)點(diǎn)，減少大數(shù)據(jù)網(wǎng)絡(luò)流量的爭(zhēng)用。

③主要挑戰(zhàn)

但最難的是針對(duì)Pro*C的適配。Pro*C是Oracle提供的應(yīng)用程序?qū)Ｓ瞄_發(fā)工具，應(yīng)用C語(yǔ)言編寫程序，在程序源代碼中可以直接嵌入SQL語(yǔ)句，執(zhí)行數(shù)據(jù)庫(kù)操作。Pro*C既兼容了傳統(tǒng)C語(yǔ)言的開發(fā)模式，又提供了強(qiáng)大的數(shù)據(jù)庫(kù)操控能力，所以在保險(xiǎn)行業(yè)和其他行業(yè)也有不小的用戶基礎(chǔ)。

而Tuxedo(Transactions for Unix, Extended for Distributed Operations)作為是最早的分布式事務(wù)產(chǎn)品，是AT&T在20世紀(jì)80年代推出的。傳統(tǒng)老核心業(yè)務(wù)中，大量使用Tuxedo調(diào)用相關(guān)的Pro*C程序來(lái)做保單業(yè)務(wù)流程處理來(lái)保證跨庫(kù)事務(wù)的一致性。

為了根本上解決該問題，實(shí)現(xiàn)應(yīng)用的平滑遷移，阿里成立項(xiàng)目攻堅(jiān)團(tuán)隊(duì)，用1個(gè)月時(shí)間，從頭開發(fā)Pro*C兼容預(yù)編譯程序和運(yùn)行時(shí)庫(kù)，2020年國(guó)慶節(jié)前，預(yù)編譯程序成功編譯了某年金業(yè)務(wù)的全部1000多個(gè)Pro*C程序，并正確跑通了兩個(gè)典型批處理作業(yè)，通過(guò)了該公司的驗(yàn)收，進(jìn)展大大超出該公司預(yù)期，也因此在賽馬中成功勝出贏得了該公司對(duì)OceanBase產(chǎn)品研發(fā)能力的信心。

短時(shí)間完成老核心的適配，得益于：

• 始終堅(jiān)持自主研發(fā)，研發(fā)人員有優(yōu)秀的個(gè)人能力，清楚產(chǎn)品每一行代碼的來(lái)龍去脈，能夠快速和高質(zhì)量地新增和修改代碼，真正做到了自主研發(fā)。
• 全鏈路打通的研發(fā)模式，Pro*C只是外在交互模式，底層還要依賴數(shù)據(jù)庫(kù)的內(nèi)核能力，從SQL模式、優(yōu)化器、服務(wù)端等做到了全鏈路打通，比如研發(fā)在批處理作業(yè)現(xiàn)場(chǎng)聯(lián)調(diào)時(shí)發(fā)現(xiàn)SQL對(duì)to_date函數(shù)的'J'參數(shù)尚未支持時(shí)，快速反映給SQL模塊，后端僅用一天完成了開發(fā)測(cè)試和發(fā)布。
• 敏捷開發(fā)模式，攻堅(jiān)小組的研發(fā)和測(cè)試大家坐到一起，每日隨著項(xiàng)目進(jìn)展和變化快速確定和調(diào)整當(dāng)日的目標(biāo)。打破研發(fā)和測(cè)試邊界，研發(fā)一邊在開發(fā)，測(cè)試同學(xué)已經(jīng)把單測(cè)和集成測(cè)試案例寫好，開發(fā)側(cè)有一點(diǎn)小的進(jìn)展就立即驗(yàn)證測(cè)試，使得開發(fā)和測(cè)試能接近同步完成。

④遷移歷程

2020年10月，首個(gè)傳統(tǒng)新核心理賠系統(tǒng)順利上線。

2021年3月，完成傳統(tǒng)老核心最小省份的遷移上線。

2021年4月，完成13個(gè)傳統(tǒng)新核心的遷移上線。

2021年8月，完成傳統(tǒng)老核心最后一個(gè)大省遷移上線。

2021年9月，完成傳統(tǒng)老核心最后一個(gè)單體庫(kù)遷移上線。

4、全面體系化遷移

該保險(xiǎn)公司核心遷移過(guò)程中遇到的另一個(gè)問題是如何體系化全面遷移，雖然在2021年3月完成最小省份的遷移，但后面還有多個(gè)老核心分布在36個(gè)按省市獨(dú)立部署的Oracle數(shù)據(jù)庫(kù)中，每個(gè)省份又包括了20多個(gè)schema，如果按照老的遷移方式，每個(gè)省份都需要?jiǎng)?chuàng)建20多條遷移鏈路，對(duì)于資源和人力都是極大的消耗，短時(shí)間也難以完成。通過(guò)分析，工程化批量遷移最大的問題是沒有做到全流程自動(dòng)化，手工操作的步驟還比較多，為了解決該問題，產(chǎn)研和現(xiàn)場(chǎng)交付同學(xué)做了三件事情：

1）OMS數(shù)據(jù)遷移工具在底層鏈路上從技術(shù)層面支持多schema合并操作，從而可以將同一個(gè)省份的二十多條鏈路合并到一條遷移鏈路中。

2）在產(chǎn)品層面將數(shù)據(jù)遷移工具的底層能力進(jìn)行拆解，將原來(lái)無(wú)法自動(dòng)化的步驟做了自動(dòng)化，并通過(guò)API的方式暴露出來(lái)，使得前線交付同學(xué)可以根據(jù)用戶的實(shí)際情況像搭積木一樣進(jìn)行組裝使用。

3）交付同學(xué)基于暴露的API和140多頁(yè)的遷移操作手冊(cè)，用一個(gè)月時(shí)間開發(fā)出簡(jiǎn)化遷移鏈路配置的快捷遷移工具。

一鍵自動(dòng)遷移過(guò)程圖

在對(duì)快捷遷移工具迭代了四個(gè)版本后，投入使用。需要人工干預(yù)的工作量減少了80%。同時(shí)一起建立了數(shù)據(jù)庫(kù)遷移實(shí)施的統(tǒng)一規(guī)范和標(biāo)準(zhǔn)，開展有序遷移。上線實(shí)施標(biāo)準(zhǔn)流程包括8大環(huán)節(jié)，98個(gè)步驟，5倍峰值壓測(cè)，體系化遷移8大環(huán)節(jié)如下：

1）兼容性評(píng)估：明確改動(dòng)范圍，進(jìn)行適配改造工作量評(píng)估并合理安排工作任務(wù)。

2）負(fù)載評(píng)估：從原數(shù)據(jù)庫(kù)獲取SQL負(fù)載信息并在新數(shù)據(jù)庫(kù)測(cè)試環(huán)境回放，驗(yàn)證新數(shù)據(jù)庫(kù)應(yīng)用后的性能。

3）測(cè)試遷移、適配改造：進(jìn)行適配改造、全量回歸測(cè)試、性能測(cè)試。有條件的系統(tǒng)（微服務(wù)化較好、重構(gòu)等），可以分批改造和實(shí)施遷移。其中，性能測(cè)試可根據(jù)遷移前的關(guān)鍵業(yè)務(wù)容量基線，確定測(cè)試準(zhǔn)出標(biāo)準(zhǔn)。

4）生產(chǎn)庫(kù)存量、增量式遷移：對(duì)于業(yè)務(wù)連續(xù)性要求不高的系統(tǒng)，一般操作一次性存量方式完成數(shù)據(jù)遷移；對(duì)于業(yè)務(wù)連續(xù)性要求高的系統(tǒng)，采取全量+增量遷移方式，待增量數(shù)據(jù)追平后實(shí)施切換，僅需在切換時(shí)點(diǎn)暫停業(yè)務(wù)（分鐘級(jí)）。

5）反向回流：對(duì)于關(guān)鍵應(yīng)用，可實(shí)施數(shù)據(jù)同步回原數(shù)據(jù)庫(kù)應(yīng)對(duì)未知風(fēng)險(xiǎn)。

6）數(shù)據(jù)驗(yàn)證：遷移完成后進(jìn)行數(shù)據(jù)準(zhǔn)確性驗(yàn)證及應(yīng)用驗(yàn)證。

7）持續(xù)監(jiān)控：對(duì)可能遇到的問題進(jìn)行監(jiān)控、詳細(xì)評(píng)估分析。

8）在線壓測(cè)：遷移完成后，定期開展在線壓測(cè)，基于實(shí)際生產(chǎn)場(chǎng)景進(jìn)行業(yè)務(wù)全鏈路壓力測(cè)試，持續(xù)保障應(yīng)用容量和性能。

2021年5月，西部某省的遷移在2小時(shí)內(nèi)順利完成，驗(yàn)證了Oracle端多schema合并遷移這一重要技術(shù)難點(diǎn)，相比之前有數(shù)倍的提升，為剩余省份的并行遷移掃清了障礙，經(jīng)過(guò)優(yōu)化后：

測(cè)試環(huán)境：自主進(jìn)行數(shù)據(jù)遷移和壓測(cè)回放，并通過(guò)SQL自動(dòng)優(yōu)化建議工具，大大提高了遷移驗(yàn)證效率，可以自助解決90%以上的問題。

測(cè)試環(huán)境多次遷移演練步驟

生產(chǎn)環(huán)境：將過(guò)程中需要人工檢查費(fèi)時(shí)、費(fèi)力的步驟，做到了自動(dòng)化。

正式遷移割接步驟

緊接著完成了東北三省+內(nèi)蒙古總共四個(gè)省份的數(shù)據(jù)，過(guò)程中解決了Oracle源端出現(xiàn)不可見控制字符臟數(shù)據(jù)的問題，確保了數(shù)據(jù)準(zhǔn)確無(wú)誤。

2021年8月，歷經(jīng)前面11次的遷移后，終于完成了最后一個(gè)、最重要省份，也是數(shù)據(jù)規(guī)模最大的的數(shù)據(jù)庫(kù)遷移。

2021年9月，在解決了所有技術(shù)難題，完成了所有核心數(shù)據(jù)庫(kù)的遷移，經(jīng)歷了開門紅大促的考驗(yàn)后，要完成一個(gè)保險(xiǎn)公司一個(gè)完整的業(yè)務(wù)周期，只剩下最后一關(guān)，就是保險(xiǎn)精算。

保險(xiǎn)精算是保險(xiǎn)公司業(yè)務(wù)經(jīng)營(yíng)的特色，指運(yùn)用數(shù)學(xué)、統(tǒng)計(jì)學(xué)、金融學(xué)、保險(xiǎn)學(xué)及人口學(xué)等學(xué)科的知識(shí)與原理，去解決商業(yè)保險(xiǎn)與各種社會(huì)保障業(yè)務(wù)中需要精確計(jì)算的項(xiàng)目。一般會(huì)在季度末和年末進(jìn)行，以衡量企業(yè)的經(jīng)營(yíng)狀況，并制定更有市場(chǎng)競(jìng)爭(zhēng)力的保險(xiǎn)產(chǎn)品，是保險(xiǎn)業(yè)務(wù)開展不可或缺的關(guān)鍵一環(huán)。

保險(xiǎn)精算分析的特點(diǎn)在于數(shù)據(jù)量大，分析的模型復(fù)雜，過(guò)程中還有大量的數(shù)據(jù)寫入，往往要持續(xù)一周甚至更長(zhǎng)時(shí)間。并且要確保精算過(guò)程中，快照點(diǎn)的數(shù)據(jù)不能發(fā)生變化，基于傳統(tǒng)IOE架構(gòu)往往通過(guò)存儲(chǔ)層的快照來(lái)實(shí)現(xiàn)。遷移到分布式數(shù)據(jù)庫(kù)后，怎么保證在不停應(yīng)用的情況下完成保險(xiǎn)精算，是整個(gè)遷移過(guò)程的最后一個(gè)障礙。經(jīng)過(guò)反復(fù)評(píng)估，阿里云為此制定了最佳方案，受益于OceanBase底層數(shù)據(jù)塊的快速物理備份和表級(jí)的恢復(fù)能力。經(jīng)過(guò)近1個(gè)月的壓測(cè)驗(yàn)證，集群恢復(fù)速度達(dá)到800MB/S，完全滿足精算的備份恢復(fù)的時(shí)間要求。最終在2021年9月30日在規(guī)定的時(shí)間窗口完成了數(shù)據(jù)的備份并導(dǎo)入到了精算庫(kù)，有效支撐了全面遷移后的保險(xiǎn)精算業(yè)務(wù)，解決掉了最后遺留的小尾巴。

保險(xiǎn)精算數(shù)據(jù)準(zhǔn)備過(guò)程

5、主要問題總結(jié)

當(dāng)然遷移過(guò)程并不是完全一帆風(fēng)順，雖然未產(chǎn)生重大生產(chǎn)事故，但過(guò)程中也出了幾次故障。而這些故障背后既反映了國(guó)產(chǎn)數(shù)據(jù)庫(kù)在面對(duì)復(fù)雜場(chǎng)景上能力的提升，也反映了分布式架構(gòu)帶來(lái)的根本性變化。

1）數(shù)據(jù)庫(kù)連接打滿多次觸發(fā)高可用切換

互聯(lián)網(wǎng)核心遷移到PolarDB過(guò)程中遇到的最大一次問題是在2021年1月，當(dāng)天凌晨面向C端用戶的兩個(gè)重要系統(tǒng)完成數(shù)據(jù)遷移和應(yīng)用的割接。伴隨著日間業(yè)務(wù)流量逐漸增加，兩系統(tǒng)因?yàn)榇罅康穆樵兌逊e較多應(yīng)用連接，將數(shù)據(jù)庫(kù)服務(wù)堵塞，全天多次觸發(fā)PolarDB實(shí)例自動(dòng)高可用切換，執(zhí)行節(jié)點(diǎn)重建恢復(fù)流程。

以云原生容器形式部署的數(shù)據(jù)庫(kù)服務(wù)節(jié)點(diǎn)，除了受本身數(shù)據(jù)庫(kù)相關(guān)的內(nèi)存參數(shù)限制外，還受cgroup指定的CPU和內(nèi)存限制。當(dāng)時(shí)連接池打滿后，由于內(nèi)存超出限制，引起實(shí)例的多次高可用切換重建。云原生數(shù)據(jù)庫(kù)基于容器部署需要在穩(wěn)定性和自保能力方面做諸多增強(qiáng)，為了解決相關(guān)問題，后續(xù)的版本中增加了global plan cache、resource manager、并行日志回放、global  index等功能，數(shù)據(jù)庫(kù)的內(nèi)核參數(shù)也針對(duì)金融場(chǎng)景逐一做了定制化優(yōu)化。

針對(duì)金融場(chǎng)景對(duì)穩(wěn)定性要求極高的需求，通過(guò)本次互聯(lián)網(wǎng)核心遷移也增加了諸多管控運(yùn)維能力：

• 增加AWR功能，定期收集AWR報(bào)告對(duì)性能和可用性進(jìn)行分析。
• 增加GAWR功能，對(duì)主機(jī)、Dockers、RW/RO進(jìn)行全量數(shù)據(jù)采集。
• 新增online promote功能，優(yōu)化在線切換，進(jìn)一步縮短切換時(shí)間。
• 增加Idle狀態(tài)Session超時(shí)自動(dòng)斷開連接功能，減少后臺(tái)進(jìn)程數(shù)，及時(shí)釋放回收Idle Session的內(nèi)存資源。
• 優(yōu)化元信息緩存功能，Session級(jí)別元信息緩存優(yōu)化為全局元信息緩存，降低后臺(tái)進(jìn)程的內(nèi)存使用。增加內(nèi)存總量資源管理控制，設(shè)置一定的閾值，到達(dá)閾值后開始Cancel Query、Kill Idle Session、Kill Active Session、拒絕新用戶Session連接，增強(qiáng)數(shù)據(jù)庫(kù)的自保能力。

2）SAN交換機(jī)故障導(dǎo)致數(shù)據(jù)庫(kù)進(jìn)入無(wú)主狀態(tài)

由于原有Oracle數(shù)據(jù)庫(kù)都是基于SAN存儲(chǔ)部署，在2020年9月份啟動(dòng)數(shù)據(jù)庫(kù)遷移工作之時(shí)，針對(duì)OceanBase部署建議的本地SSD盤硬件還沒有采購(gòu)到位。為了快速啟動(dòng)相關(guān)的遷移工作，最開始OceanBase傳統(tǒng)新核心集群還是部署在SAN存儲(chǔ)上，這也為第一個(gè)生產(chǎn)問題埋下了隱患。

第一個(gè)傳統(tǒng)新核心應(yīng)用理賠上線后，系統(tǒng)運(yùn)行比較平穩(wěn)。意外出現(xiàn)在某天下午14點(diǎn)7分，系統(tǒng)同時(shí)收到了應(yīng)用監(jiān)和數(shù)據(jù)庫(kù)監(jiān)控的告警。監(jiān)控顯示，應(yīng)用出現(xiàn)了90秒的阻塞迭停。然而，當(dāng)雙方團(tuán)隊(duì)還在排查問題時(shí)，數(shù)據(jù)庫(kù)已經(jīng)自動(dòng)完成了恢復(fù)。

OceanBase QPS監(jiān)控截圖

問題現(xiàn)象時(shí)間軸分析

經(jīng)過(guò)深入分析，發(fā)現(xiàn)是SAN存儲(chǔ)交換機(jī)到核心交換機(jī)連接的一個(gè)端口出現(xiàn)了故障。雖然配置了多路徑轉(zhuǎn)發(fā)，但由于操作系統(tǒng)內(nèi)核的超時(shí)時(shí)間OceanBase切主時(shí)間不匹配，觸發(fā)了OceanBase的自動(dòng)選主操作。而選主過(guò)程中，另外一臺(tái)物理機(jī)也走的同樣端口也出現(xiàn)了IO阻塞的問題，最終導(dǎo)致OceanBase進(jìn)入無(wú)主狀態(tài)，當(dāng)多路徑軟件成功切換后，OceanBase未經(jīng)過(guò)任何干預(yù)就完成了自動(dòng)恢復(fù)。本質(zhì)上是因?yàn)檐浖瑫r(shí)參數(shù)與硬件超時(shí)參數(shù)不匹配所導(dǎo)致，也是軟硬件系統(tǒng)磨合不夠充分的表現(xiàn)，通過(guò)相關(guān)參數(shù)的調(diào)整能減少RTO的時(shí)間。

在此次故障之前，大家對(duì)OceanBase的了解都停留在PPT層面：RPO=0、RTO<30秒。直到這次故障才真切地感受到，故障時(shí)的快速切換和自動(dòng)恢復(fù)能力是多么的重要。但是故障發(fā)生，項(xiàng)目組內(nèi)部也有質(zhì)疑聲音出來(lái)：“OceanBase基于SAN存儲(chǔ)的部署本來(lái)就是錯(cuò)的，我們就不該使用OceanBase?！钡?jīng)過(guò)深入的分析才發(fā)現(xiàn)并不是OceanBase的問題，也不是SAN存儲(chǔ)的問題，而是有沒有充分的磨合，軟硬件相關(guān)的參數(shù)是不是最合適的。IOE架構(gòu)之所以成為集中式架構(gòu)下的最佳組合，正是經(jīng)過(guò)廣泛的實(shí)踐和各種場(chǎng)景的錘煉，讓軟硬件都能在一個(gè)最佳的狀態(tài)下提供服務(wù)。最終經(jīng)過(guò)這次事件之后，大家統(tǒng)一認(rèn)識(shí)，調(diào)整參數(shù)并不能根本性解決問題。原來(lái)部署在SAN存儲(chǔ)上的OceanBase遷移到了本地盤硬件設(shè)備上，隨后也逐漸演進(jìn)到兩地三中心多活部署架構(gòu)。

3）執(zhí)行計(jì)劃跳變導(dǎo)致業(yè)務(wù)卡頓

如果一個(gè)數(shù)據(jù)庫(kù)廠商說(shuō)100%兼容Oracle，保證遷移過(guò)程不出任何問題，那一定是自吹。即便做到了事前壓測(cè)充分，且盡量覆蓋完所有業(yè)務(wù)場(chǎng)景。但對(duì)于割接上線后的系統(tǒng)穩(wěn)定性、兼容性還是要畫問號(hào)。關(guān)鍵在于是否有及時(shí)有效的監(jiān)控，以及出現(xiàn)問題后的快速應(yīng)急手段。畢竟已經(jīng)投產(chǎn)的應(yīng)用，應(yīng)急還是第一優(yōu)先級(jí)。

在11月份某個(gè)周末，理賠系統(tǒng)出現(xiàn)慢SQL，導(dǎo)致理賠應(yīng)用系統(tǒng)票據(jù)匯總操作卡頓超時(shí)。為什么系統(tǒng)已經(jīng)穩(wěn)定運(yùn)行了半個(gè)多月，沒有任何的業(yè)務(wù)變更，反而在周末業(yè)務(wù)低峰期出現(xiàn)問題？現(xiàn)場(chǎng)交付專家經(jīng)過(guò)分析很快定位到原因，OceanBase的執(zhí)行計(jì)劃發(fā)生了跳變，導(dǎo)致執(zhí)行計(jì)劃走錯(cuò)。

經(jīng)過(guò)深入分析，OceanBase和其他數(shù)據(jù)庫(kù)一樣，通過(guò)使用執(zhí)行計(jì)劃緩存 (Plan Cache)，對(duì)于相同的SQL（參數(shù)不同），跳過(guò)解析階段，避免重新生成執(zhí)行計(jì)劃，以提升SQL的性能。但是實(shí)際場(chǎng)景中傳入的參數(shù)往往是不同的，就像淘寶雙11有熱點(diǎn)庫(kù)存，在保險(xiǎn)行業(yè)也有大小機(jī)構(gòu)號(hào)。雖然SQL看起來(lái)一樣，但因?yàn)閭魅氲膮?shù)不同，優(yōu)化的手段和執(zhí)行的路徑也不一樣。傳統(tǒng)數(shù)據(jù)庫(kù)（比如 Oracle）為了選擇最優(yōu)的執(zhí)行計(jì)劃，會(huì)定期進(jìn)行數(shù)據(jù)對(duì)象統(tǒng)計(jì)信息的收集（如每天夜間的維護(hù)窗口（maintenance window）），淘汰舊的執(zhí)行計(jì)劃，使新的執(zhí)行計(jì)劃能夠按照實(shí)際的數(shù)據(jù)統(tǒng)計(jì)信息生成更準(zhǔn)確更優(yōu)的執(zhí)行計(jì)劃。OceanBase采用類似的方法，但由于OceanBase 每天進(jìn)行數(shù)據(jù)凍結(jié)合并，增量數(shù)據(jù)落盤，數(shù)據(jù)庫(kù)對(duì)象的實(shí)際數(shù)據(jù)信息（行，列，平均值等）會(huì)發(fā)生較大的變化。因此合并以后，計(jì)劃緩存會(huì)進(jìn)行清理，并根據(jù)第一次傳入的參數(shù)生成執(zhí)行計(jì)劃進(jìn)行緩存，默認(rèn)情況下，只會(huì)保留一個(gè)執(zhí)行計(jì)劃。由于周末當(dāng)時(shí)第一次傳入的參數(shù)不具備普遍代表性，導(dǎo)致后續(xù)執(zhí)行計(jì)劃走錯(cuò)，產(chǎn)生了性能問題。

執(zhí)行計(jì)劃跳變是一個(gè)比較常見的數(shù)據(jù)庫(kù)性能現(xiàn)象，Oracle先后推出了Cursor Sharing，Outline，Bind peeking，ACS，SPM等手段來(lái)優(yōu)化改進(jìn)，然而生產(chǎn)上也無(wú)法徹底規(guī)避執(zhí)行計(jì)劃走錯(cuò)的問題，新的數(shù)據(jù)庫(kù)產(chǎn)品從Oracle 99%到100%的兼容優(yōu)化也是最難的，也不是短時(shí)間能一蹴而就。對(duì)于這種小概率事件，應(yīng)急就成為了最后的兜底手段，在不動(dòng)應(yīng)用的大前提下，通過(guò)數(shù)據(jù)庫(kù)靈活的綁定執(zhí)行計(jì)劃，是出現(xiàn)突發(fā)問題時(shí)比較有效和容易落地的手段。實(shí)際整個(gè)遷移過(guò)程中，對(duì)于偶發(fā)的執(zhí)行計(jì)劃跳變，項(xiàng)目組也已經(jīng)駕輕就熟，沒有給遷移帶來(lái)意外影響。

6、整體效果

歷時(shí)一年，近100個(gè)業(yè)務(wù)系統(tǒng)全面實(shí)現(xiàn)國(guó)產(chǎn)數(shù)據(jù)庫(kù)遷移，成為首家完成100%核心業(yè)務(wù)系統(tǒng)國(guó)產(chǎn)數(shù)據(jù)庫(kù)遷移的大型金融企業(yè)，數(shù)據(jù)庫(kù)OceanBase和PolarDB用量占比超過(guò)97%。

通過(guò)數(shù)據(jù)庫(kù)的全面替換，實(shí)現(xiàn)了對(duì)數(shù)據(jù)資產(chǎn)的的全面安全保障能力，做到了：

• 100%數(shù)據(jù)庫(kù)技術(shù)棧的安全可控，擺脫對(duì)Oracle數(shù)據(jù)庫(kù)的依賴。
• 擺脫對(duì)小型機(jī)和高端存儲(chǔ)的依賴。
• 促進(jìn)云原生和分布式數(shù)據(jù)庫(kù)應(yīng)用成熟，從可用到好用并取得性能提升。
• 數(shù)據(jù)庫(kù)服務(wù)集中管控，顯著降低硬件及整體運(yùn)維成本。
• 真正的實(shí)時(shí)擴(kuò)縮容和高可用能力，輕松應(yīng)對(duì)大促活動(dòng)。

從完全封閉的體系架構(gòu)到逐步開放再到全面開放，真正實(shí)現(xiàn)了對(duì)數(shù)據(jù)庫(kù)核心技術(shù)的自主掌控。得益于云原生架構(gòu)和分布式架構(gòu)的彈性和資源池化能力，也自此能實(shí)現(xiàn)“一庫(kù)多芯”，只需一條命令就可以把租戶切換到海光服務(wù)器節(jié)點(diǎn)，實(shí)現(xiàn)了國(guó)產(chǎn)硬件的平滑替換。

遷移后由于分布式數(shù)據(jù)庫(kù)提供的高效壓縮能力，存儲(chǔ)容量的大小只有原來(lái)的1/3，加上高端小型機(jī)遷移到國(guó)產(chǎn)機(jī)架式服務(wù)器，設(shè)備投入節(jié)省近2億元。

數(shù)據(jù)庫(kù)服務(wù)器及存儲(chǔ)機(jī)柜數(shù)量利用率提高了300%。設(shè)備功率下降至原有1/3。經(jīng)測(cè)算，全年可節(jié)約電力約近千萬(wàn)度，為該公司數(shù)字化轉(zhuǎn)型提供了源源不斷的綠色動(dòng)能，有力踐行了國(guó)家雙碳戰(zhàn)略，減少公司由于自建數(shù)據(jù)中心帶來(lái)的碳排放增量。

三、總結(jié)

今天國(guó)內(nèi)大部分金融機(jī)構(gòu)的核心業(yè)務(wù)仍然運(yùn)行在國(guó)外的數(shù)據(jù)庫(kù)上，這是一個(gè)我們無(wú)法回避的現(xiàn)實(shí)，數(shù)據(jù)庫(kù)的替換不僅是一個(gè)產(chǎn)品的替換，替換的目的不單純?yōu)榱恕皣?guó)產(chǎn)”兩個(gè)字，更重要的是：技術(shù)必須進(jìn)步；替換后的新系統(tǒng)必須具備老系統(tǒng)和國(guó)外產(chǎn)品不具備的能力，不僅是性能和穩(wěn)定，更多是對(duì)業(yè)務(wù)的敏捷支撐能力，和面對(duì)海量業(yè)務(wù)和不確定性的業(yè)務(wù)高峰時(shí)刻的處理能力，以及更上一層樓的金融級(jí)高可用能力。

這些年我們看過(guò)很多的文章都是對(duì)于數(shù)據(jù)庫(kù)替換的分析和暢想，但是面對(duì)實(shí)際的大規(guī)模復(fù)雜的核心應(yīng)用系統(tǒng)的技術(shù)平臺(tái)替換，過(guò)程中還有很多在各種“分析”文章中想不到的問題，尤其對(duì)于現(xiàn)有運(yùn)行的環(huán)境的各種適配和兼容、對(duì)應(yīng)用的友好性等很多，關(guān)于這些，阿里走出了堅(jiān)實(shí)的一步，積累了彌足珍貴的經(jīng)驗(yàn)，這些都為今后的國(guó)產(chǎn)進(jìn)程給出了很好的示范效應(yīng)。