本文作者： 張顯華，孟凡輝，莊培培
系列導讀：徐戟（白鱔）數據庫技術專家，Oracle ACE，PostgreSQL ACE Director
當前，國內大量的關鍵行業的核心繫統正在實現國產化替代，而與此同時，這些行業的數字化轉型也正在進入深水區。在信息系統的升級換代過程中，夯實 IT 基礎設施是極其關鍵的。從服務器、操作系統、中間件、數據庫等基礎軟硬件選型到系統架構、應用架構的重新設計，再到數據遷移、系統遷移、系統優化、運維體系重構的一系列工作都是十分具有挑戰性的。大多數工作中，都會遇到無法完全參考前人的探索和創新。
一些勇敢的先行者已經在這條荊棘叢生的道路上硬生生的創出了一條血路，而更多的人還在未知與迷茫中摸索。 “銀⾏核⼼背後的落地⼯程體系”系列技術文章來自於金融行業用戶真實故事，從中可以窺見的不僅是國產化替代路上的艱辛歷程，更多的是對於後來者極其寶貴的實踐經驗。
在本系列文章中你不僅可以看到 TiDB 與 Oracle 的異構遷移、基於 TiCDC 的邏輯容災與數據共享、構建雙活數據中心的真實案例，還可以瞭解到混沌測試、應急預案等方面，以及利用數據庫可觀測性構建智能化、自動化運維體系的方案與技巧。“ 積小流，成江海 ”，希望這些案例能夠對您有所裨益。
銀行核心業務的數據遷移是一項既複雜又需細緻操作的任務，涉及全面規劃和精確執行多個關鍵要素。本文以某城市商業銀行核心系統的數據遷移爲例，詳細闡述從 Oracle 到 TiDB 的遷移方案設計和具體實施步驟。
銀行核心數據遷移四要素
銀行核心的數據遷移，遷移時間的控制及數據準確性至關重要，爲了確保數據遷移的成功，需要綜合考慮遷移邏輯、數據一致性、遷移性能和回退方案這四個核心要素。
- 遷移邏輯
在遷移邏輯的設計上，首要任務是確保數據遷移的實時性和準確性。我們需要評估現有系統是否支持實時同步，並設計相應的同步機制以保證數據的實時更新。同時，對於表結構和數據模型的遷移，應制定詳細的轉換策略，確保數據在遷移過程中的完整性和一致性。此外，數據兜底方案和技術支持也是不可或缺的，它們爲數據遷移提供了堅實的保障，確保在任何情況下數據的安全性和可靠性。
- 數據一致性
數據一致性是銀行業務數據遷移中的核心問題。特別是在涉及銀行核心賬務系統時，每一筆交易數據、每一行記錄都必須保證絕對準確。爲此，我們需要制定嚴格的數據校驗流程和一致性檢查機制，確保遷移後的數據與源數據完全匹配。同時，針對可能出現的字符集不匹配問題，如從 Oracle 的 16GBK 遷移到 TiDB 的 UTF8MB4，應提前規劃字符集轉換方案，確保數據在遷移過程中的準確性和一致性。
- 遷移性能
遷移性能是影響數據遷移效率的關鍵因素。我們需要評估遷移窗口時間是否充足，以及遷移過程中涉及的表結構調整、數據模型轉換等操作是否高效。此外，選擇合適的數據遷移工具，並確保其具備良好的自動化能力和支持分批、分組遷移的功能，將有助於提升遷移效率。
- 回退方案
在遷移過程中，還應考慮可能出現的意外情況，並制定相應的回退方案，以便在遇到問題時能夠迅速恢復到遷移前的狀態。
遷移邏輯
2.1 遷移需求和挑戰
- 銀行賬務核心涉及的表多且數據量大。
- 字符集轉換，Oracle 的 ZHS16GBK 到 TiDB 的 UTF8MB4 的轉換。
- 數據移形，表結構和數據的移形，表結構發生變化，老數據基於新的業務規則轉換爲新的業務數據。
- 全程腳本化，數據要保證前後一致。
- 遷移窗口總時間 2 小時內 (數據移形 + 數據遷移 + 數據檢核)。
2.2 遷移方案設計
在制定數據遷移策略時，我們必須考慮到源系統和目標系統之間表結構的差異，以及數據在遷移過程中可能需要的邏輯轉換。在評估的多個方案中，第一個實時同步的方案由於缺乏必要的數據移形能力，未能滿足要求，因此被排除。第二個方案，即通過將 Oracle 中的數據導出爲 CSV 格式，再導入到 TiDB 的方案，不僅在遷移工具的選擇、字符集的轉換、數據一致性的保障上滿足了要求，而且在窗口時間內也能順利完成遷移任務。
初步評估下來，方案二在技術上是可行的，但仍需深入探討其實施的細節。特別是在數據從 Oracle 遷移至 CSV 的過程中，藉助 Oracle 生態系統內使用較好的導出工具來實現，但此過程還涉及到從老核心數據庫到中轉機的 Oracle 數據庫的數據遷移以及平臺因素等方面的考慮。
2.3 引入中轉機的技術考量
引入中轉機的原因，首先老核心系統除了包含存，貸，公共及覈算等核心業務模塊之外，還涵蓋了其他多種業務模塊，是典型的傳統胖核心模式。避免對原有數據庫的影響及回退的考慮，直接在老核心系統上進行建表、數據遷移和轉換等操作是不可行的。因此需要設置一箇中轉機，作爲臨時的中間庫，完成必要的數據轉換和遷移工作。中轉機的引入不僅解決了數據遷移的技術難題，還爲整個遷移過程提供了靈活性和安全性。在遷移過程中，老核心數據庫本身保持不變，僅需要更改業務訪問的地址，即可實現平滑過渡。
中轉機的引入不僅爲數據遷移過程中可能出現的問題提供了有效的回退機制，而且在技術層面上，它還起到了關鍵的兜底作用。在整個數據遷移的鏈路中，主要採用了 Lightning、O2T Sync-diff 以及 Oracle 導出工具 這三款工具，工具平臺適配問題通過引入中轉機也很好的被解決。三款工具，Lightning 和 O2T Sync-diff 是由 TiDB 官方提供的數據遷移工具，官方提供技術支持及技術兜底；爲了確保遷移過程的穩定性和兼容性，在實際使用 Oracle 生態的導出工具時，主要使用工具的基本功能實現 Oracle 數據導出爲 CSV 文件，儘量減少對導出工具高級特性的使用。
2.4 表結構和數據的移形
結構和數據的移形涉及表結構和數據兩個部分，移形的方式大概分爲四大類。
- 平移和新增
平移指表結構在遷移過程中保持不變，即字段的數量和定義均與原數據庫一致，沒有發生任何結構性或邏輯性的改變。在這種情況下，表的結構和數據可以無縫地遷移到新的數據庫環境中。新增指的是在目標數據庫中創建全新的表結構，而這些表在源數據庫中並不存在。在數據割接和投產後，新數據將被插入到這些新創建的表中。
- 平移重構
相較於簡單的平移，會涉及到一些細微的結構調整。例如，可能會在表中新增一個時間戳字段，以便記錄數據的最後更新時間。這些簡單的轉換可以通過編寫通用的程序腳本來完成，通過執行類似 Oracle 數據庫中的“INSERT SELECT”語句來完成的，沒有複雜的邏輯在裏面。
- 輕度重構
通常涉及到對原有數據結構的調整，比如將老核心系統中的兩張表合併成一張新表，或者對錶進行分拆。這樣的操作可能還會包括對字段內容的填充或修改，需要藉助存儲過程來進行改造。
- 完全重構
適用於當數據結構和業務邏輯發生顯著變化時。在完全重構的場景下，原有的數據結構和業務流程往往經歷了根本性的改造，這意味着大部分甚至所有的原有數據和邏輯都需要按照新的業務需求和數據模型來重新設計和構建。
大部分數據可以通過前述的四種方法順利遷移到新的數據庫系統中，但總會有一些數據因其業務邏輯的複雜性而難以通過簡單的轉換程序來處理。這部分數據在割接當天通過初始化批的方式去完成，以確保數據的時效性和準確性。
以某城市商業銀行核心系統升級項目爲例，我們採用了前述的五種數據遷移策略。在這個項目中，需要進行重構的數據佔據了總量的近一半，這表明了項目的技術複雜性和挑戰性。在項目實施的關鍵時刻，即投產前一個月，業務邏輯的持續變化爲數據遷移的順利執行帶來了巨大的挑戰。
下圖是數據移形的全流程示意圖，老核心 Oracle 數據庫中的數據有平移數據和轉換數據，還有一部分數據與新核心無關，無需遷移。
- 表結構遷移
Oracle 中間庫的表結構和目標 TiDB 側的表結構通過 DAP 平臺（微服務開發平臺）統一生成兩份建表腳本。通過在兩個不同的數據庫環境中執行相同的建表語句，確保了表結構的一致性和數據遷移的準確性。
- 轉換數據遷移
平移數據和轉換數據首先通過專門的導出和導入工具遷移到我們的中間庫——一個運行在 X86 環境下的 Oracle 數據庫。中間庫的作用是進行數據的預處理和轉換工作。這些處理步驟通過存儲過程來實現的，開發團隊對所有遷移表進行了詳細的梳理，並針對每張表制定了具體的轉換前後業務邏輯。在中間庫中，數據被清晰地分爲三個部分：轉換前的數據、轉換後數據以及不需要進一步處理的平移數據。
- 初始化數據
這部分數據在系統割接當天，通過觸發批處理作業的方式將數據導入到新的環境中，從而實現表結構和數據的整體遷移。
遷移性能
在討論數據遷移的性能問題時，行方設定的整體時間窗口爲兩小時。這一時間限制涵蓋了如下三個遷移過程：
- 老核心 Oracle 到中轉機 Oracle 的數據遷移(O2O)
- 中間庫中的數據轉換(Convert)
- 轉換後的數據遷移到 TiDB (O2T)
爲了在 2 小時這一嚴格的時間框架內完成遷移，我們對整個遷移流程進行了細緻的分階段處理和細粒度的拆解。通過這種方式，我們能夠更精確地識別每個階段的耗時點，並針對性地進行性能優化。
3.1 O2O 遷移優化
在數據遷移的第一階段，我們面臨着 Oracle 數據庫從 AIX 環境遷移數據到中間庫的挑戰。最初考慮的方案是利用行裏面已有的存儲複製技術來快速創建數據的鏡像，但生成的鏡像仍然位於 AIX 平臺上，無法直接遷移到 Linux 平臺。過程中我們還遇到了硬件方面的挑戰，由於中轉機使用的是較老的 AIX 硬件，我們需要額外準備性能更強大的 AIX 機器，這大大增加了項目的成本。在使用較老 AIX 硬件的初步嘗試中，發現硬件性能存在明顯的不足，尤其在進行數據比對時，與基於 X86 架構的系統相比，性能差距顯著。
將數據遷移的中轉機採用 X86 平臺，實現從 AIX 到 Linux 的跨平臺遷移，工具採用了 Oracle 官方提供的數據導出（Expdp）和導入（Impdp）工具。經過評估，將所有的數據從 Oracle 數據庫導出並導入到中間庫的時間大約需要一個小時。這一時間基本花費了一半的窗口時間，後續的數據轉換工作以及將轉換後的數據遷移到 TiDB 的工作在 1 個小時內基本無法完成，需要進一步優化遷移時間。
3.2 多通道遷移
在從老核心 Oracle 遷移數據至 X86 架構的 Oracle 中轉機，再從 CSV 格式文件遷移到 TiDB 的過程中，我們發現採用單一通道和單一數據組的遷移方式無法在兩小時的時間窗口內完成。因此，我們採取了將數據拆分成多個小組並行處理的策略，把所有遷移表和數據拆分成 9 組。拆分成多組之後，整體遷移完成的時間受限於最慢的那個組的遷移速度。
多通道分組的引入帶來了新的挑戰。
- 遷移表分組可行性
遷移表包含了存，貸，公共及覈算幾個核心的業務模塊，需要考慮分組的可行性。和業務側溝通，基於業務邏輯進行表分組的可行性，溝通下來業務側給的反饋是可行的。
- 分組數量的確認
因各個業務表之間是存在關聯關係的，分組需要結合業務關聯性進行考慮，整體評估後再確認每個業務模塊能分多少組。分組的選擇，除了要考慮業務關聯性的因素，還需要充分考慮硬件性能的最大化利用，進而最大化的縮短遷移時間。在進行初步的 4 組數據遷移驗證時，我們觀察到硬件資源，包括 CPU、網絡和磁盤 IO，並未完全利用。逐步增加遷移組數至 6 組時，硬件資源的負載達到了一個較爲飽和的狀態。過程中，還需關注不同組之間負載交替的問題。某些組在遷移過程中持續保持高負載，而其他組的高負載可能僅出現在遷移開始的前兩分鐘或是後幾分鐘。通過一系列的測試和調整，最終確定了最佳的分組策略： 4 組用於處理存款數據，2 組處理貸款數據，2 組負責公共覈算數據以及 1 組用於平移數據，共 9 組。
3.3 遷移腳本化
爲了滿足行方對數據遷移過程的要求，整個遷移過程需要實現腳本化操作，以減少人爲誤操作及提升遷移的效率。這涉及到腳本開發的複雜性，需要精心設計和測試以確保每個步驟都能準確無誤地執行。同時，行方對遷移的時間窗口有嚴格的要求，整個遷移過程必須在兩小時內完成（表結構轉換+數據移形+數據遷移）。
將數據遷移拆分爲 9 組並行執行後，遷移過程幾個關鍵性的步驟，包括數據導出、數據導入和數據比對。爲了管理這些操作，我們使用了一臺控制機，它負責將任務指令下發到所有 9 組的機器上，並監控它們的執行情況。所有這些步驟都通過腳本化的方式進行，以實現高效的自動化操作。
腳本具備的能力
- 基於組的任務調度
- 基於表的任務調度
- 遷移過程的任務狀態及進度監控
3.4 增量遷移優化
爲了確保數據遷移工作能夠在兩小時的時間窗口內完成，在多通道分組遷移的基礎上，還採取了增量遷移的方法作爲補充策略。通常情況下，增量遷移適用於那些數據量龐大且歷史數據不更新的業務表，例如在老核心系統中最大的表接近 3 億條記錄，以及一些包含大量交易流水的表。我們使用的導入工具 Lightning 往往會在處理這些大表時遇到時間瓶頸，爲了縮短這些大表的遷移時間，增量遷移策略被引入以優化遷移效率。
如圖所示，我們的數據遷移工作被劃分爲兩個階段進行。在第一階段，我們選擇在 T-3 日，也就是割接前三天，提前遷移部分大表的數據。到了割接當天，我們只遷移這些大表在過去三天內產生的新數據，顯著縮短了遷移過程所需的時間。
增量遷移還需要考慮表合併的問題。例如，當我們提前三天遷移了 10 張表的數據後，我們需要確定如何在割接當天將這些數據與當天遷移的最近三天的數據進行有效合併。
第一種方式是增量表 rename。具體來說，在提前三天遷移數據時，我們將這些表 rename 爲非生產環境使用的臨時表名。到了割接當天，我們只遷移最近三天內產生的增量數據，使用原始的生產表名來標識。然後，我們將這些增量數據通過 insert into select 的方式同 3 天前的歷史表數據進行合併，再通過 cross rename 操作，將這些合併後的表更名爲最終的生產表名。Insert 操作會對分佈式數據庫的性能產生一定影響，可以基於增量表遷移的數據量來決定方案。評估下來，三天增量表的數據量不是很大，通過數據庫 insert 方式進行數據合併高效且穩定，最終採取此種方式進行數據合併。
第二種方式，即在提前三天遷移的增量表保持原表名不變的情況下，到割接當天，利用 Lightning 工具的增量導入功能來合併數據。爲了確保實施的便利性和考慮到數據量的管理，採用分步遷移。第一步，我們將增量表進行遷移，遷移後保持表名不變。第二步，繼續遷移最近 3 天的增量表數據，並將這些數據追加到之前三天遷移的數據中，從而構成一份時間連續的完整數據集。
在實際執行過程中，還需要異常考慮的情況。儘管已經通過多次演練，但仍然存在在割接當晚將三天的增量數據插入到歷史數據表時出現錯誤的風險。我們在提前三天進行數據遷移時，對這些表的數據進行了三份拷貝備份。如果遇到某張表插入失敗的情況，可以迅速切換到另一張備份表，從而繞過插入過程中的異常問題。
3.5 遷移拓撲
以下是整體遷移分組及腳本化的全景流程圖。整個過程從一個生產環境的 Oracle RAC 開始，數據首先被快速切換到生產 MA 鏡像機。完成這一步驟後，數據將被導出並分發到 9 組 X86 機器上。在目標 TiDB 集羣中，部署了 TiUP 中控機，該中控機不僅承載了腳本調度功能，還負責執行數據遷移相關的批量操作。腳本化流程主要包括幾個關鍵環節：Oracle 數據的導出和導入、oracle 導出工具將數據轉換爲 CSV 文件、Lightning 工具將 CSV 文件導入到 TiDB，以及數據比對。所有這些環節都通過 TiUP 中控機和 DB compare 調度工具來協同執行。
爲了應對割接當天可能出現的異常情況，腳本化流程設計了精細的控制機制。例如，如果在導出過程中，一組中的 10 張表有 9 張成功導出，而 1 張表失敗。我們的調度程序不僅能夠基於整個組來進行重新調度執行，還能夠針對單個表進行精細的控制和重新發起。
在數據遷移工程中，我們採用了 Oracle 導出工具、Lightning 和 O2T Sync-diff 三種工具的協同工作，以實現對數據進行細緻的表級別導出操作。Lightning 在導入數據時是基於目錄進行導入，我們爲每一張表創建了一個獨立的目錄，這樣每個目錄就可以代表一個數據組或者單獨的一張表。O2T Sync-diff 同樣支持表級別的操作，在數據比對過程中，如果發現某張表的數據比對失敗，我們會對其進行修復，並在修復後針對這張特定表進行重新比對。
Oracle 導出工具 charset 參數設置建議和 Oracle 16GBK 字符集保持一致，避免不必要的轉碼操作。在運用 Oracle 導出爲 CSV 的導出工具時，儘量減少對高級特性的使用，優先選擇基本功能的使用方法。針對導出的 CSV 文件的字段分隔符，建議設置一個較長的分隔符，避免分隔符同表內容碰撞引發導入異常。從 Lightning 性能考慮再結合最佳實踐，單文件大小設置爲 256M。爲了適配老核心的運營環境，Lightning 的字符集設置爲 GB18030。sql-mode 需要開啓數據嚴格要求的參數。
在上線當天，O2O 遷移過程表現出色，整個遷移僅用時 30 分鐘，數據轉換環節耗時 20 分鐘，從 Oracle 數據庫遷移至 TiDB 數據庫的過程耗時 38 分鐘，完美達成了兩小時的時間窗口要求。
數據一致性
4.1 數據檢核
數據一致性是數據遷移過程中至關重要的一環，確保了遷移後的數據準確無誤，採取了雙層數據比對策略。
- 技術檢核
關注數據庫層面的準確性，通過計算數據內容的 CRC32 校驗和來驗證數據的一致性。
- 業務檢核
關注業務邏輯，比如使用記錄數、業務項、記錄狀態、表間關係等基於業務考慮的指標進行覈對。
在老核心 Oracle 向中轉庫遷移數據的過程中，使用 Oracle 成熟工具來執行，遷移過程執行嚴格的表記錄數比對。在中轉庫階段，轉換前和轉換後數據的核查由業務團隊負責。數據從中間庫遷移到最終的目標庫 TiDB，這個過程中技術層面的檢核至關重要，基於表內容進行 CRC32 校驗。
4.2 亂碼處理
正常字符集編碼範圍劃分
- 正常編碼區（符號 & 漢字）
- 用戶自定義區（Private Use Area）
- 保留區（Reserved Zone）
亂碼數據主要來自 IB2 協議層 GB18030 到數據庫 ZHS16GBK 轉碼範圍差異，用戶自定義區的自定義字，跨系統數據處理階段以及歷史遺留的亂碼，處理方式見下表。
對於第二類的內容失真問題，ICONV 轉碼工具在技術層面可以解決用戶自定義編碼的失真問題 。
亂碼數據的應對方案包括以下幾個步驟：
第一，預處理，通過掃描工具提前發現，形成亂碼清單。
第二，對亂碼數據預分析和分類處理。
第三，基於十六進制編碼進行異步修復。
下圖是從 Oracle 老核心到 TiDB 新核心的遷移全景圖。左邊是 Oracle 生產，分爲 9 組，遷移當天 O2O 的遷移耗時 30 分鐘，數據轉換耗時 20 分鐘，從 Oracle 到 TiDB 耗時 38 分鐘，滿足行方兩小時的時間窗口要求。割接當天，TiDB 新核心所有的下游的同步，比如到近線庫、邏輯庫、鏡像庫以及 Kafka 的同步均異步實施，不佔用窗口時間，包括到 DSG 逃生庫的搭建也是異步實施的。
在 2022 年的遷移方案設計與實施過程中，我們面臨的挑戰是在 TMS（TiDB Migration Service）全鏈路數據遷移平臺尚未發佈的情況下，如何有效地從 Oracle 數據庫遷移至 TiDB。TMS 是一個專爲 Oracle 到 TiDB 遷移場景量身打造的平臺，它集成了應用對象兼容性評估、對象結構遷移、數據全量遷移、數據校驗以及應用 SQL 兼容性評估等關鍵功能模塊。
TMS 的出現，標誌着遷移工作從依賴手工操作和多種工具組合的複雜方式，轉變爲一個白屏化、用戶友好的流程。這種轉變極大地降低了用戶的使用門檻，提高了遷移的效率，並且增強了整個遷移過程的可靠性。隨着 TMS 平臺的不斷優化和迭代，它已經在多個金融機構的 O2T（Oracle to TiDB）遷移項目中得到了成功應用。未來，我們期待與大家分享這些客戶的實際使用體驗，讓更多用戶瞭解 TMS 在實際操作中的優勢和效果。通過這些案例分享，我們相信 TMS 將繼續在數據遷移領域發揮重要作用，幫助更多企業實現平滑、高效的數據庫遷移。