一、前言

在國家層面提出加快建設科技強國，實現高水平科技自立自強的大背景之下，某超大型保險（集團）公司深入推進數字化轉型，緊隨先鋒技術發展趨勢，前瞻性布局啟動IT架構分布式改造轉型，并于21年9月圓滿實現了最后一個規模高達20TB+核心數據庫的全面遷移改造工作，也為后續向云原生多活架構演進打下了堅實的基礎。該數據庫國產遷移項目成功上線，樹立了金融行業踐行科技強國的標桿實踐，也是對國家科技自立自強戰略以及國產技術的履責擔當；更推動了整個國內數據庫管理與應用體系科技生態建設和科技產業鏈的快速成熟。

對于保險行業而言，短時業務并發壓力雖沒有互聯網企業那么大，但是在業務復雜性和對數據庫專有特性的依賴程度上，都要遠大于互聯網企業。保險業務的處理更為復雜，單一業務要多個系統完成，調用鏈比銀行和互聯網業務更長、更復雜，確保復雜集合大交易量的穩定是保險業務數據庫國產的挑戰。由于金融機構對業務連續性和數據準確性的嚴苛要求，在傳統頭部金融機構中始終沒能有一家完成國產數據庫全面遷移，直到這家保險公司成功實施，并取得了五個突破。

1）突破一：遷移時間短。從2020年9月到2021年9月，僅用時一年即完成遷移， 而傳統金融機構還沒有實現過如此大規模的核心系統全量遷移。

2）突破二：遷移規模破紀錄。一年內完成了包括傳統核心、互聯網核心、個險銷售、團險銷售、經營管理、客服管理、大數據在內的近百個業務系統在線Oracle數據庫的全量搬遷工作，遷移數據規模超400TB、數據量超千億，單庫數據規模超20TB。

3）突破三：遷移全程同時保障了業務連續性和數據準確性。整個遷移過程無一例回切，上線后近一年來，系統穩定運行，并歷經2021年完整周期的“業務大考”，經受住了開門紅高峰TPS 5萬+、QPS 21萬+和包括精算在內的所有業務環節的嚴苛考驗，完全滿足生產需要，實現國產數據庫從可用到好用的跨越。

4）突破四：遷移后實現技術100%自主創新。基于完全自研創新的國產數據庫，遷移過程中版本升級持續發版共計50余次，最長需求解決時間2個月（Pro*C+Tuxedo）。同時通過系統培訓與交流實現累計超過500位員工的數據庫專業考試認證，實現了數據庫的全面自主掌控能力。

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

當我們回顧這一段歷程，過程雖然艱辛，但積累了寶貴的大型金融機構國產數據庫遷移實踐經驗。

二、國產金融級數據庫遷移實踐

1、前期準備工作

1）數據庫選型

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

是否能滿足業務的平滑遷移和未來架構的演進。

是否具備分層解耦能力，重點解除數據庫與底層硬件、操作系統、中間件之間的耦合。

是否有足夠人才儲備、資金投入，保證產品的長期演進和商業兜底。

是否有廣泛的行業實踐案例。

是否能做到完全自主研發。

是否能兼容原有開發運維體系，自有技術人員能否快速掌握。

2）基礎設施準備

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

3）遷移策略制定

該保險公司的業務經過多年的發展，業務范圍覆蓋全國，特色鮮明、種類繁多、關聯關系錯綜繁雜，核心數據庫遷移需要廣泛調研和充分的科學論證——既要求數據庫產品比照原有生產數據庫的高性能和安全可靠，也需要快速實現多套系統的平滑遷移，同時解決資源彈性和數據庫橫向擴展的能力。因此，建立了數據庫遷移實施的統一規范和標準，總體遵循評估-實現-控制-分析改進的科學方法論，開展有序遷移，并定下三大遷移策略：

• 先平遷再做業務和架構改造升級，避免多個變量同時發生，影響業務的連續性。原有數據模型不做改造，主體改造工作由新數據庫來承擔。
• 遷移批次以業務系統為粒度，從低負載到高負載，從外圍到核心。
• 用1年時間完成所有業務系統的數據庫全量遷移改造，所有系統數據庫遷移動作時間窗口只給周六、周日凌晨0點到早上6點，周末小流量驗證，周一重點保障，不影響正常業務開展。

2、互聯網核心遷移

1）業務背景

該保險公司核心雖然涉及系統眾多，但總結下來主要分為：互聯網核心和傳統核心，中間通過類似ESB的總線機制實現異步解耦。

核心系統分類

自2016年，這家保險公司的互聯網核心和傳統新核心應用開始從傳統單體架構向分布式微服務架構改造。到2020年，互聯網核心業務系統已經拆分成了40多個微服務模塊并完成Mesh化接入，互聯網核心特點是：

• 數據庫系統已實現全國物理集中、邏輯集中，數據庫對接的關聯系統較多。
• 雖然做了微服務拆分，數據庫仍有一定量的存儲過程，另外觸發器、自定義類型、函數、外鍵、分區表等高級功能均有使用。
• 因為業務特點，要服務好100多萬代理人，對數據庫資源彈性和性能要求更高。

因此互聯網核心的數據庫遷移面臨的主要技術挑戰是：

• 全國集中式部署下單點故障會影響到全國。
• 主數據系統作為核心業務鏈路中的整個保險開戶入口，內部對接43個關聯系統，數據規模超20TB，最大單表超50億條數據，每天接口調用量超2000萬次，是該公司單體數據庫日均請求量最大的系統，因為關聯系統多，且處在業務鏈路的核心位置，因此對數據庫SQL的效率要求非常高，遷移過程不能影響原有生產系統。
• 遷移到新的數據庫平臺要具備實時同步到Kafka的能力，并兼容原有格式，供下游大數據系統消費。

原有大數據消費鏈路

2）技術方案

①整體選型

針對以上技術挑戰，選擇了和原有Oracle RAC架構更接近的PolarDB作為互聯網核心數據庫的替換，PolarDB作為新一代云原生數據庫主要特點如下：

• 計算與存儲分離，使用共享分布式存儲，滿足業務彈性擴展的需求。極大降低用戶的存儲成本。
• 讀寫分離，一寫多讀，PolarDB引擎采用多節點集群的架構，集群中有一個主節點（可讀可寫）和至少一個只讀節點（最大支持15個只讀節點）。寫操作發送到主節點，讀操作均衡地分發到多個只讀節點，實現自動的讀寫分離。
• 基于K8S形態部署，提供分鐘級的配置升降級，秒級的故障恢復，全局數據一致性和完整的數據備份容災服務。
• 集中式架構，不需要進行分布式架構相關考慮設計，和原有使用習慣保持一致，性能不低于原有Oracle數據庫。
• 高度兼容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之后整體架構將更適應業務彈性的挑戰：

• 統一管控：通過PolarStack將多臺機器組成的集群進行統一管控，提供DBaaS服務；
• 資源彈性：實例由原來的物理機部署，變為K8S Pod部署，更為靈活和彈性；
• 讀寫分離：通過智能代理服務實現自動的讀寫分離，實現分鐘級擴容，故障場景下自動切換，應用不需要做任何調整。

PolarDB技術架構

業務沖刺當天經過了三個高峰時間點：12:00、17:00、21:00，每小時出單量和全天出單量進入了歷史的前三位，高峰期出單筆數達到9000筆/s。

④遷移歷程

2020年9月，互聯網核心首批應用模塊遷移到PolarDB，整個適配過程不到一個月。此后，互聯網核心各個模塊就開始了大規模的遷移。

2020年11月，PolarDB完成了最大的單庫客戶主數據遷移。

2021年1月底，PolarDB作為互聯網核心出單系統的數據庫，穩定支撐起該保險公司2021年一季度業務沖刺。

3、傳統核心遷移

1）業務背景

該大型保險公司的傳統核心系統歷史悠久，既有1998年之前建成的，也有2004到2008年間建成的，時間跨度長，數據量異常龐大，單個數據庫的數據規模甚至超過20TB。更具挑戰的是，很多老核心按省市做了拆分，要分省市分別進行遷移，單一老核心系統需要遷移的數據庫可能就要多達36個。傳統核心總體來說可以分為三類系統：

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

這些傳統核心的數據庫當時面臨的主要技術挑戰是：

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

2）技術方案

①選型方案

針對以上技術挑戰，選擇了分布式數據庫OceanBase作為傳統核心的替換，OceanBase數據庫主要特點如下：

• 采用基于無共享（Shared-Nothing）的多副本架構，整個系統沒有任何單點故障，保證系統的持續可用。
• 基于LSM存儲引擎技術，結合新硬件的能力，采用可擴展的分布式架構，提供高性能和擴展性。
• 數據庫針對Oracle、MySQL等應用最為廣泛的數據庫生態都給予了非常高的應用兼容性支持。
• 雖然為分布式架構，一般也不需要應用層做相應的重新設計如指定分布鍵等，與原有Oracle使用習慣基本一致。
• OceanBase數據庫完全自主研發，不依賴外部開源代碼，真正做到自主研發。

②遷移方法

針對傳統核心復雜的數據庫情況進行全面驗證，最終形成了140頁的遷移操作手冊和詳細的割接行事歷，為后續系統的遷移和大面積推廣積累了寶貴的經驗，并形成了標準的遷移割接方案。整體遷移方法過程如下，從基礎環境準備-遷移過程演練-正式割接-監控運維等四大環節進行逐項拆解，落實到人，精確到分。

數據庫整體遷移割接流程

對于規模較大Oracle數據庫的遷移，我們總結了如下四點幫助提升遷移效率：

• 冷熱數據分離

一般的業務庫數據中，數據具有自己的生命周期，數據的高頻訪問具有冷熱特點。比如，流水表歷史數據，日志表歷史數據除了在審計回查場景之外，訪問很少甚至不訪問，但是通常這部分數據都會比較大，數據遷移的開銷會比較高，造成數據遷移時間的延長。針對該部分數據，我們可以預先對這部分數據進行歸檔備份，然后采用靜態遷移或者利用OMS工具全量遷移單獨遷移。

• LOB類型數據

Oracle數據表行LOB類型空間占用較大，每一批次的數據拉取大小會在原始行的基礎上有顯著增加。相比無LOB數據類型，對OMS端內存需求有數倍的需求，因此，優化的策略是單獨對LOB類型的表建立新的鏈路，采用較小的并發，防范JVM OOM的風險，同時，為了提高整體遷移的速度，進行多鏈路并行遷移。

• 無LOB類型數據

相對于LOB類型數據，無LOB數據類型的表的遷移，單位遷移批次的大小較小且穩定，內存需求可控，并發度可適度加大，提高遷移速度。所以，對該部分數據可使用較高的并發度單鏈路或多鏈路遷移。

• 多個大庫遷移鏈路通過不同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產品研發能力的信心。

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

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

④遷移歷程

2020年10月，首個傳統新核心理賠系統順利上線。

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

2021年4月，完成13個傳統新核心的遷移上線。

2021年8月，完成傳統老核心最后一個大省遷移上線。

2021年9月，完成傳統老核心最后一個單體庫遷移上線。

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合并遷移這一重要技術難點，相比之前有數倍的提升，為剩余省份的并行遷移掃清了障礙，經過優化后：

測試環境：自主進行數據遷移和壓測回放，并通過SQL自動優化建議工具，大大提高了遷移驗證效率，可以自助解決90%以上的問題。

測試環境多次遷移演練步驟

生產環境：將過程中需要人工檢查費時、費力的步驟，做到了自動化。

正式遷移割接步驟

緊接著完成了東北三省+內蒙古總共四個省份的數據，過程中解決了Oracle源端出現不可見控制字符臟數據的問題，確保了數據準確無誤。

2021年8月，歷經前面11次的遷移后，終于完成了最后一個、最重要省份，也是數據規模最大的的數據庫遷移。

2021年9月，在解決了所有技術難題，完成了所有核心數據庫的遷移，經歷了開門紅大促的考驗后，要完成一個保險公司一個完整的業務周期，只剩下最后一關，就是保險精算。

保險精算是保險公司業務經營的特色，指運用數學、統計學、金融學、保險學及人口學等學科的知識與原理，去解決商業保險與各種社會保障業務中需要精確計算的項目。一般會在季度末和年末進行，以衡量企業的經營狀況，并制定更有市場競爭力的保險產品，是保險業務開展不可或缺的關鍵一環。

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

保險精算數據準備過程

5、主要問題總結

當然遷移過程并不是完全一帆風順，雖然未產生重大生產事故，但過程中也出了幾次故障。而這些故障背后既反映了國產數據庫在面對復雜場景上能力的提升，也反映了分布式架構帶來的根本性變化。

1）數據庫連接打滿多次觸發高可用切換

互聯網核心遷移到PolarDB過程中遇到的最大一次問題是在2021年1月，當天凌晨面向C端用戶的兩個重要系統完成數據遷移和應用的割接。伴隨著日間業務流量逐漸增加，兩系統因為大量的慢查詢堆積較多應用連接，將數據庫服務堵塞，全天多次觸發PolarDB實例自動高可用切換，執行節點重建恢復流程。

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

針對金融場景對穩定性要求極高的需求，通過本次互聯網核心遷移也增加了諸多管控運維能力：

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

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遷移到了本地盤硬件設備上，隨后也逐漸演進到兩地三中心多活部署架構。

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%的兼容優化也是最難的，也不是短時間能一蹴而就。對于這種小概率事件，應急就成為了最后的兜底手段，在不動應用的大前提下，通過數據庫靈活的綁定執行計劃，是出現突發問題時比較有效和容易落地的手段。實際整個遷移過程中，對于偶發的執行計劃跳變，項目組也已經駕輕就熟，沒有給遷移帶來意外影響。

6、整體效果

歷時一年，近100個業務系統全面實現國產數據庫遷移，成為首家完成100%核心業務系統國產數據庫遷移的大型金融企業，數據庫OceanBase和PolarDB用量占比超過97%。

通過數據庫的全面替換，實現了對數據資產的的全面安全保障能力，做到了：

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

從完全封閉的體系架構到逐步開放再到全面開放，真正實現了對數據庫核心技術的自主掌控。得益于云原生架構和分布式架構的彈性和資源池化能力，也自此能實現“一庫多芯”，只需一條命令就可以把租戶切換到海光服務器節點，實現了國產硬件的平滑替換。

遷移后由于分布式數據庫提供的高效壓縮能力，存儲容量的大小只有原來的1/3，加上高端小型機遷移到國產機架式服務器，設備投入節省近2億元。

數據庫服務器及存儲機柜數量利用率提高了300%。設備功率下降至原有1/3。經測算，全年可節約電力約近千萬度，為該公司數字化轉型提供了源源不斷的綠色動能，有力踐行了國家雙碳戰略，減少公司由于自建數據中心帶來的碳排放增量。

三、總結

今天國內大部分金融機構的核心業務仍然運行在國外的數據庫上，這是一個我們無法回避的現實，數據庫的替換不僅是一個產品的替換，替換的目的不單純為了“國產”兩個字，更重要的是：技術必須進步；替換后的新系統必須具備老系統和國外產品不具備的能力，不僅是性能和穩定，更多是對業務的敏捷支撐能力，和面對海量業務和不確定性的業務高峰時刻的處理能力，以及更上一層樓的金融級高可用能力。

這些年我們看過很多的文章都是對于數據庫替換的分析和暢想，但是面對實際的大規模復雜的核心應用系統的技術平臺替換，過程中還有很多在各種“分析”文章中想不到的問題，尤其對于現有運行的環境的各種適配和兼容、對應用的友好性等很多，關于這些，阿里走出了堅實的一步，積累了彌足珍貴的經驗，這些都為今后的國產進程給出了很好的示范效應。