| 執筆專家：苑華偉 盧麗歡 楊光

| 課題組專家和社群多位會員參與此次活動分享

背景

近幾年國產資料庫以其高併發、海量資料、易擴充套件、高可用、易運維（一體化自動運維平臺）等技術優勢，以及其部署在普通硬體伺服器之上的成本優勢，在國內各個行業取得了廣泛應用，成熟度也越來越高，關注程度也越來越高，在金融行業尤其是銀行業資料庫國產化替換的趨勢越來越明顯：在銀行業數字化轉型和高質量發展過程中，IT系統的飛速發展，而傳統以Oracle為代表的集中式IT架構已經無法滿足需求，像雲平臺、大資料、AI、微服務、分散式架構、敏捷前臺、統一中臺等技術架構的發展很好的契合了銀行未來業務發展的需求，而國產資料庫作為其中重要環節貫穿了整個前中後端，重要程度不言而喻，是未來銀行IT架構轉型發展的重要趨勢；此外，金融行業國產化進一步推進並逐步進入深水區，資料庫國產化是其中一項重要內容，資料庫從傳統Oracle遷移到國產資料庫勢在必行。

本文重點圍繞企業在去O實踐過程中遇到的難題進行交流探討總結：

1、由Oracle資料庫遷移到分散式資料庫之後，關聯查詢的語句怎麼解決？

【問題描述】由Oracle資料庫遷移到分散式資料庫之後，除了讓儘量把需要關聯的表按照相同的規則分佈在一個節點外，現在系統的資料量都是5T以上的，不同的表已經按照不同的規則進行了分割槽，這些表之間的關聯查詢是應用必須要的而且頻率很高，如果需要把所有的表按照統一規則去設定分佈欄位讓同一使用者下的資料都相同的節點上，這樣的話改造就非常大，萬一要回退也會非常麻煩，請問一下專家，這個問題還有沒有其他好辦法來解決複雜的關聯查詢的問題，又不會導致應用改造過大？

@hanfeng_twt SphereEx 資料庫架構師：

解決上述問題有幾個思路：

1.產品層面

有些分散式資料庫產品，提供“自動分散式”能力，即可以實現資料自主分片，不再需要人為干預。這樣在結構設計無需做太多修改。針對語句方面，也可以免改造或低改造完成遷移。當然這種方式還是要看業務複雜度，很難做到完全規避因引入分散式帶來的改造成本。且針對複雜查詢情況下，目標資料庫是否能很好處理且保證效能也是需關注的。

2.設計層面

在設計方面，提前做好相應的改造評估工作。如對現有結構、語句透過工具掃描方式，獲得當前的工作負載，針對分散式情況下做改造評估等。這種方式不會減少改造工作量，但會提前規劃避免被動。這種也是我比較推薦的方式。

3.架構層面

針對複雜的Oracle查詢，有些場景可考慮下移到大資料技術棧解決。後者針對複雜關聯查詢，會更為適合。但兩者需解決資料同步問題且業務是否接受一定延遲，也需關注。

2、如果資料庫較大，全量遷移時間較長，如何儘可能縮短停機視窗？

【問題描述】對於資料庫容量較大的庫，從Oracle遷移到國產資料庫，全量遷移需要較長時間，而對於金融機構來說，停機視窗非常寶貴，如何可以縮短停機視窗是實施的難點之一，如果是同構資料庫的遷移，比如Oracle遷移到Oracle，有比較成熟的工具實現全量和增量的遷移，前期先進行全量遷移，停機視窗時再進行增量遷移，可以儘可能縮短停機時間，但是Oracle到國產資料庫，如何進行類似的全量和增量遷移，需要重點考慮？

@hanfeng_twt SphereEx 資料庫架構師：

總結來說，是異構資料庫間遷移的問題

1.提供常規的全量及增量資料遷移能力，這對於有效縮短時間視窗有益。目前已有很多廠商提供此類能力。但需要注意的是，從集中式架構到分散式架構還可以；反之仍有一定侷限。

2.提供全量及增量資料對比能力，滿足對資料一致性的檢驗能力，這對於實施切換是重要參考依據。此外包括差異資料的正向、反向的補償能力，也是需要的。

3.由業務邏輯方面提供一定的相容能力，可滿足短時間系統間遷移的資料補償能力，有助於縮短視窗。

4.架構設計方面，提供多種資料同步考慮，除了資料庫外，還可以考慮如應用報文、網路協議等方面的同步機制，作為有益的補充。

@huawei851120 江蘇省農村信用社聯合社 資料庫運維工程師：

有兩種思路：

1.先對Oracle的大表進行改造，分為歷史表和當前表。把歷史表先期遷移到國產資料庫，停機視窗內再把當前用的表遷移過去。這種用法比較推薦；

2.利用同步工具。幾家大廠的國產資料庫，都有自己的資料同步工具，可以先期進行資料同步，但不能同步DDL。這個階段不要進行Oracle表結構的表更。投產視窗內，把應用停掉後，等資料追平就可以了。

@劉煒鈺 城銀清算服務有限責任公司 應用維護：

1.截止到一個時間點可以提前遷移歷史資料，比如視窗前一週或者提前1、2天；

2.到了停機視窗，業務停運後補增量資料；

3.做好全量資料的檢查，補完增量後，新老庫資料量對比，做最終確認，這樣就能大大減少資料遷移時間 。

@yata52 中國人壽財險 資料庫管理員：

目前我們接觸的國產資料庫廠商都有了適合自己的全量初始化加增量同步方案，有的是利用自有工具，有的是利用常見資料遷移軟體，都能做到在切換前資料實時同步幾乎無延遲。但是總結下來，遷移的過程還需要重點考慮這幾個問題：

1.如果源庫較大，為了保障全量初始化成功，需要考慮適當調大undo表空間，為了保障遷移時對生產影響較小，儘量使用物理備庫抽取，全量遷移時合理分組初始化。如果是單表過大又沒有物理備庫的情況，可以考慮使用更高效的工具（資料泵等）將單表遷移至Oracle中轉庫（不承載業務）再慢慢匯入到國產資料庫。

2.如果遷移過程中使用了kettle、ogg、平面檔案多種技術組合實現，上線前一定要對資料做驗證，防止出現中文亂碼。

3.各家都實現了實時增量同步，目前切換過程中佔用停機時間的主要是這兩個步驟，一是資料靜態後的資料檢驗時間，二是反向同步啟動前的配置和檢查工作。

3、國產資料庫分集中式和分散式，Oracle遷移至集中式還是分散式場景？

【問題描述】國產資料庫有提供集中式模式和分散式模式兩種，集中式省去了資料分佈方面的難點，更容易實現遷移，但是效能、容量和擴充套件性受限，而分散式資料庫改造難度相對較大，但效能、容量和擴充套件性優勢明顯，因此，如何更加具體業務場景選擇合適的資料庫？

@huawei851120 江蘇省農村信用社聯合社 資料庫運維工程師：

1.首選無論是集中式還是分散式，都儘量採用大廠的產品。因為資料遷移工作，看似沒什麼大不了，一旦出問題後後果很嚴重。大廠的集中式和分散式產品一般都有資料遷移工具，並且在很多客戶那使用過，遷移都會比較方便，但沒有想象的完美。

2.如果是小庫，遷移至集中式會比較方便，透過工具直接可以遷移。如果是交易量比較大、資料量比較大的庫，推薦採用分散式資料庫，集中式的效能肯定不如大廠的分散式資料庫產品。

3.如果庫有非常多的儲存過程（幾十個，乃至幾百個），還是採用集中式比較好。分散式資料庫，尤其是基於MySQL的對儲存過程相容性不太好。

@yata52 中國人壽財險 資料庫管理員：

首先總結下我司所使用的兩種資料庫特點：

集中式資料庫：體系結構與Oracle類似，語法相容度高、對伺服器無要求、資料遷移成本小、運維規範可基本沿用。單叢集效能上限受限於X86伺服器算力，相比小型機+Oracle的組合仍存在一定差距。

分散式資料庫：使用分散式協議和LSM-Tree資料結構，需要修改為Mysql語法、對伺服器效能要求較高、資料遷移成本較高、運維規範需重新建立。單叢集庫效能可透過擴充伺服器進行擴充套件，算力可突破小型機+Oracle的組合。

針對以上兩種特點，我們的替換場景如下：

1.切換前使用虛擬機器執行資料庫的中低負載系統，替換為集中式資料庫。

2.切換前使用小型機或者多臺物理機執行資料庫的中高負載系統，替換為分散式資料庫。

@lulihuan1987 張家港行 資料庫管理員：

國產資料庫集中式模式遷移難度較小，適配容易，特別是一些特殊資料庫物件也可以支援，比如函式和儲存過程，對於效能，容量和擴充套件性要求不高，單臺資料庫伺服器足以支撐的業務場景，可以採用。而分散式模式對於資料庫比較大，高併發，需要根據業務需求可以擴充套件的業務場景，單臺伺服器無法支撐的場景。無論是集中式還是分散式模式，均支援跨機房級容災和節點高可用等特性。

@hanfeng_twt SphereEx 資料庫架構師：

從Oracle遷移到國產資料庫的選擇路線：

1.遷移目的：首選需要關注的是遷移目的，是為了解決效能、承載量，還是為了滿足自主可控。針對前者的話，考慮分散式架構更多；後者，則更傾向於考慮國產集中式架構產品。

2.應用適配：次之要考慮應用適配問題。如果應用對Oracle有較深度的依賴，則需優先考慮相容度好的產品，相對而言集中式架構產品在這方面有些優勢；反之，則可不將此因素作為選擇要素之一。此外，針對分散式架構，需要考慮如資料分片等問題，也需一併考慮。某些系統依賴外部廠商開發，出於儘量減少開發量的初衷，集中式架構更有優勢。

3.運維適配：現有運維體系是否對分散式架構有一定經驗或者已具備相關人員儲備，這對於選擇這一架構很重要。這其中包括從基礎設施、備份恢復、故障處理、效能調優等多方面。

4.業務連續性：相對集中式架構而言，分散式在整體穩定性等方面還需驗證。因此在選擇之初，要將整體可用性作為考慮要素之一，是否有專項預案解決需考慮。

4、正式替換原有資料庫後，如何保證國產資料庫寫庫的準確性？是否有異構資料庫之間的資料稽核？

【問題描述】在雙軌執行過程中，如何保證國產資料庫寫庫的準確性？我們之前測試的時候發現有些國產資料庫儲存的精度與Oracle不一致。是否有異構資料庫之間的資料強一致性的稽核？

@huawei851120 江蘇省農村信用社聯合社 資料庫運維工程師：

據我瞭解，應該是沒有的。本人也是希望有，這樣可以防止國產資料庫出現天大的問題（資料不一致）的時候，我們客戶能及早的發現，不至於釀成大錯。可是目前國內應該沒有這樣的異構資料庫之間的資料稽核。小廠商都是基於MySQL和PG開發的，不值得大廠去開發工具稽核它們。大廠的資料庫核心技術都是保密的，不會給別的大廠去稽核。

@我是個小胖子 國泰君安：

根據我們前面的應用經驗，這種稽核一般是有兩種方式。

一是由資料庫廠商提供相關的工具，來核對兩個庫的資料一致性，比如兩邊分別匯出csv檔案(排除自增id，時間戳等欄位)，然後進行比對，也可以以oracle資料庫基準，用唯一鍵定位國產庫的行資料，然後進行比對。

二是由業務每日匯出當日的增量資料，然後由業務方自行比對。

5、風險控制方面考慮，例如白名單灰度遷移，回退方案等？

【問題描述】遷移過程中風險必須是可控的，由於是對於重要線上業務系統，一方面要確保業務系統儘可能短暫的影響，又要確保出現問題能夠快速應對或者回退，該問題難點在於涉及資料庫的切換，如果只涉及應用，那麼可以透過灰度釋出實現，出現問題也可以及時回退，而資料庫的遷移是否可以借鑑類似的思路去實現白名單灰度遷移，出現問題快速回退，整個過程中Oracle和國產資料庫之間的資料如何處理？

@huawei851120 江蘇省農村信用社聯合社 資料庫運維工程師：

從我們的經驗看，灰度遷移是個危險的想法，哈哈！真的，容易把資料搞髒掉，不建議這樣做。雖然整體資料遷移，風險高，但是容易保持資料一致性。一旦失敗後，可以追日誌來找到資料一致點。至於您擔心的事情，我個人的意見是：

1.提前把國產資料的環境搭好，小庫要提前兩週，大庫要提前一個月。

2.在生產上，切換投產視窗前提前做幾輪的遷移測試。比如9月1日遷移，在8月中旬下旬各做兩輪的遷移，在生產上做的話，注意視窗，以防對現有系統造成影響。可以選擇深夜交易低谷進行。

3.每輪遷移完成後，對資料進行校驗和比對。

@yata52 中國人壽財險 資料庫管理員：

目前我們接觸到的國產資料庫廠商暫時還做不到同時雙向同步，即同一個表內的資料Oracle的變更向國產寫，同時國產的變更向Oracle寫。但是目前都實現了單向同步， Oracle的變更向國產寫沒問題， 切換之後國產的變更向Oracle回寫也沒有問題。針對快速回切，實踐中我們會用這兩種方式：

1.針對核心系統，切換後開啟反向實時同步。上線前準備好回切方案，資料庫部分主要是涉及序列的變更和資料校驗指令碼。資料庫切換之後立刻開啟反向回退，保障國產資料庫內的變更可以準實時的寫回原Oracle資料庫。由於中介軟體切換異構資料庫的資料來源需要重啟，所以切換後老應用的中介軟體資料來源不調整，僅從F5中摘掉，需要回切時候完成資料庫切換動作後直接把老應用掛回F5。

2.針對可自行稽核並補錄資料的系統，我們是直接在新環境搭建新庫並按照業務團隊的要求匯入某一時間的資料，業務切換後資料庫層不提供資料實時同步服務，直接將Oracle資料庫的表空間設為只讀避免流量沒有切乾淨。

6、資料庫很大，遷移視窗又相對有限的資料庫遷移應該怎麼實現？每個資料庫使用者基本都在3T級別。

@huawei851120 江蘇省農村信用社聯合社 資料庫運維工程師：

這種大庫是很難辦的。常用的方法：

（1）花力氣對原Oracle庫進行改造，把表分為歷史表和當前表。比如3個月前的資料放1個表或幾十張表裡，當前交易進行增刪改查的作為一個表，給當前交易用；

（2）先對歷史表進行資料遷移；

（3）投產視窗對當前表進行遷移，可能3T裡面只有300G~800G左右，這樣才能控制投產的是遷移視窗時長。

@yata52 中國人壽財險 資料庫管理員：

可以考慮採用全量+增量的方法進行資料同步，停機視窗前將增量延時控制在分鐘級別。

達夢：自有工具HS。

Oceanbase：自有工具OMS。

TiDB：外部工具Goldengate。

7、從Oracle遷移到信創資料庫後的應急預案？

【問題描述】對於一些大企業的資料庫從傳統的Oracle遷移到信創。很多時候會存在一種顧慮。就是長久的效能和可靠性，比如在遷移到了信創資料庫，在短時間內的效能指標和功能都滿足了需求。但有些業務可能是週期性的。有些問題也可能是累積後出現的。這種情況可能會導致割接一段時間後資料庫出現問題。對於這樣的顧慮和可能發生的風險。有那些應急預案呢?

@lulihuan1987 張家港行 資料庫管理員：

上線是需要制定應急預案，出現問題要把資料倒刷回去緊急回退，對於已經上線並執行一段時間出現問題想回退，需要滿足兩個條件。第一應用支援兩種不同資料庫，支援Oracle和國產資料庫，並且應用兩套程式碼都支援同步開發，可以更改配置資料來源後能切換資料庫。第二，兩個資料庫間資料準實時同步。

@hanfeng_twt SphereEx 資料庫架構師：

1.對於核心的系統，需考慮雙發機制，即並行兩套系統執行，可保證隨時有後備系統可選擇。

2.對於非核心繫統，可考慮在異構資料庫同步方案，即保證資料不丟失有備用資料庫可用。

3.從應用角度來講，弱化對資料庫的依賴，儘量使用通用方法，有助於回切。

8、Oracle中對於頻繁查詢更新的大表如何實現遷移最佳化？

【問題描述】原來使用的Oracle資料庫時，由於其成熟的查詢最佳化器，對於頻繁查詢並更新的大表而言，效率可以接受，業務也能接受，例如交易記錄，所有的交易均需要插入該表，而部分交易可能又要頻繁查詢該表甚至頻繁更新該表，當表容量達到一定大小時，從Oracle遷移到國產資料庫可能存在效率問題，一旦該表出現卡頓，所有交易都有影響，後果非常嚴重，因此在遷移過程中對於這類頻繁查詢更新的大表需要如何考慮？

@huawei851120 江蘇省農村信用社聯合社 資料庫運維工程師：

根據經驗有以下建議：

先對Oracle庫進行最佳化改造，對大表改造為分割槽表，縮小每個分割槽表的大小。然後為改Oracle庫建立ADG讀庫，將讀交易改造至讀改ADG庫。最佳化完成後，再進行國產化改造就很方便了。甚至可以分階段先改造讀交易至國產資料庫，再改造寫交易至國產資料庫。

最後：如果一個系統在Oracle上執行就有比較多的問題，不要試圖透過改造成國產資料庫來解決改問題，可能會把問題放大。

9、Oracle到國產資料庫遷移後資料如何作對比，比如大欄位等？

【問題描述】資料遷移後需要進行源庫和目標庫的資料比對，以確保資料遷移準確性，但是由於是資料庫異構，欄位型別會發生變化，資料比對往往沒有那麼容易，記錄數比對相對來說比較容易實現，但是欄位級別的比對難度和效率很難達到平衡，例如大欄位型別等，所以遷移後資料比對如何實現，確保資料庫一條一個欄位都不能有問題？

@yata52 中國人壽財險 資料庫管理員：

.目前國產的資料同步工具已經在逐步適配國產資料庫，可以依託這些工具自帶的對比工具。

2.在沒有外部工具的情況下如何平衡效率和全面性，可以考慮上線前的測試階段對資料進行全面校驗，在正式遷移停機視窗內效率優先（目前國產資料庫廠商已有對比指令碼，僅對比物件數量、狀態、條數、主鍵）。

3.測試階段可以要求開發團隊或者業務團隊聯合驗證，一些由於遷移引起的大欄位丟失、亂碼、精度錯誤等問題暴露的會比較快，排查起來更高效。

@lulihuan1987 張家港行 資料庫管理員：

一方面可以依靠資料庫廠商提供的同步平臺，但是目前大欄位的比對沒有太好的辦法，可以試著增加欄位求該行md5值的方法試試。

10、0racle遷移至國產資料庫後，如何保證資料的完全一致性？並行期間，如何將資料回寫0racle？

@lulihuan1987 張家港行 資料庫管理員：

Oracle遷移到國產資料庫後，如果Oracle想要作為備份繼續使用，那麼雙寫和資料同步都是可以的，具體的方案也需要結合業務系統去做。兩個資料庫間資料的完全一致性需要靠同步工具或者編寫指令碼去檢驗，一般以同步工具為主，指令碼為輔。

@yata52 中國人壽財險 資料庫管理員：

具體哪種方式需要看應用支援雙寫的難度。說一個我們碰到的應用雙寫難點，部分流水號是透過序列生成的。為了加速序列的使用Oracle和國產庫都加了cache，如果是簡單的透過nginx將業務流量映象，兩邊取到的序列值就難於保障是一致的。建立訂單的流程都能完成，只是生成的流水號不一樣，但是對於根據流水號修改的業務，流量複製到備端就會異常。

11、遷移至國產分散式資料庫後分表實踐方案？

【問題描述】各位老師，遷移至國產分散式資料庫後的分庫分表方案，一直困擾著我。也查閱了很多相關資料，但是還是感覺沒有一個滿意的可落地方案。因此提出幾個具體問題，希望各位老師能夠解答，也希望各位同業一起交流。

1.儘量保證單庫查詢的原則是指的一個交易事務範圍內，還是單個sql範圍內呢？

2.一筆記賬交易涉及多類表:如賬戶表，參數列，憑證表，流水錶，機構表等。如何合理劃分分片鍵呢，保證儘量單庫處理。能否有具體的案例參考？

3.如何衡量分庫分表策略合理呢？是否有類似單庫sql佔比，兩分片sql佔比等類似的指標進行衡量呢？

4.是否可以提供某個具體案例，交易描述，分片策略等，幫助我們進行參考？

@huhu097 雲南紅塔銀行 DBA：

先考慮表的性質，是線上交易型（存放線上交易資料），還是分析型（歷史資料歸檔和交易日誌等），線上交易型的表分割槽優先考慮事務處理邏輯，避免分散式事務，考慮和其他表關聯的情況，來確定分割槽鍵以及分割槽的方式，索引的建立和使用需要考慮表分割槽鍵，線上交易系統單筆交易涉及sql數量一般都比較多，單個事務內包含多條sql，建議分析交易處理邏輯以及sql涉及的表結構，再做分割槽。分析型的表優先考慮歷史資料歸檔以及清理的問題，另外還有歷史資料查詢的效率問題，OceanBase現有的表組，支援全域性唯一性索引（可以不帶分割槽鍵），廣播表，對分表非常的友好。

@lulihuan1987 張家港行 資料庫管理員：

通常單sql查詢索引合理的情況下不會有問題，這裡的單sql指的是單表的sql，如果帶上分片欄位的話是最優解，只操作單節點。單sql的更新，update和delete需要帶上分片欄位，否則存在跨節點更新，會有效率問題，對於不支援全域性一致性的資料庫來說，可能還有一致性問題。insert時涉及跨節點更新時也要注意。兩個以上表操作sql設計是難點，總得原則就是避免跨節點資料流動，能拆就拆，不能拆的關鍵欄位必須是分片欄位。

@hanfeng_twt SphereEx 資料庫架構師：

1.所謂單庫查詢，是指語句查詢可以精確到某個分片中，這樣的效率最高。從事務處理角度來看，能否限制在某個分片內（即本地事務），也是效率最高的。

2.具體的分片策略沒有一定之規，一方面可選擇業務的共性部分作為分片鍵，一方面資料量不大又參與到業務中的，也可考慮全域性表（或廣播表）的方式。

3.無法完全杜絕分庫分表，只能儘量減少。具體比例取決於業務及分片策略。

4.可參考北京金融聯盟最新發布的單元化策略指南。