從Oracle資料庫遷移到國産資料庫的11個難點解析

背景

近幾年國産資料庫以其高并發、海量資料、易擴充、高可用、易運維（一體化自動運維平台）等技術優勢，以及其部署在普通硬體伺服器之上的成本優勢，在國内各個行業取得了廣泛應用，成熟度也越來越高，關注程度也越來越高。

在金融行業尤其是銀行業資料庫國産化替換的趨勢越來越明顯：在銀行業數字化轉型和高品質發展過程中，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和國産資料庫，并且應用兩套代碼都支援同步開發，可以更改配置資料源後能切換資料庫。第二，兩個資料庫間資料準實時同步。

@pysx0503：

理論上是這樣。可是有些老業務因為年代久遠，缺少技術支撐，信創更新是基于業務的全新開發，在這種情況下。可能很難做到兩套代碼的同步，甚至有不少案例都是硬着頭皮在沒有應急預案的情況下進行的割接更新，更新到信創資料庫之後如果一段時間後出現了問題。老舊的業務應用和資料庫可能因為缺少技術支援和原始資料而無法做到緊急回退。這種情況請問有什麼更好的辦法避免嗎？

@lulihuan1987 回複 pysx0503：

這個不是理論上的，我們銀行2019年上線的新核心就是采用該方案并且同步運作了一年，當時投入了很多資源，包括應用廠商，資料庫廠商以及我們行方。要做到運作一段時間後還能回退，目前我們就是這麼做的。不過現在三年過去了，都在成熟，隻要做好充分測試，不需要應急回退的了，也不現實，成本太高了。

@yata52 回複 pysx0503：

還有一種思路是上線前在信創環境導入真實業務流量，充分驗證功能及性能。老系統按照現有節奏進行監管更新，驗證期間新環境可以不更新新功能，隻在驗證流程完畢後追平功能。

@hanfeng_twt SphereEx 資料庫架構師：

1.對于核心的系統，需考慮雙發機制，即并行兩套系統運作，可保證随時有後備系統可選擇。

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

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

8、Oracle中對于頻繁查詢更新的大表如何實作遷移優化？

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

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

根據經驗有以下建議：

先對Oracle庫進行優化改造，對大表改造為分區表，縮小每個分區表的大小。然後為改Oracle庫建立ADG讀庫，将讀交易改造至讀改ADG庫。優化完成後，再進行國産化改造就很友善了。甚至可以分階段先改造讀交易至國産資料庫，再改造寫交易至國産資料庫。

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

9、Oracle到國産資料庫遷移後資料如何作對比，比如大字段等？

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

@yata52 中國人壽财險 資料庫管理者：

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

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

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

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

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

10、Oracle遷移至國産資料庫後，如何保證資料的完全一緻性？并行期間，如何将資料回寫Oracle？

@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.可參考北京金融聯盟最新釋出的單元化政策指南。