本文由 dbaplus 社羣授權轉載。
遷移背景
隨着Oracle數據庫19c在去年的發佈，越來越多之前的數據庫版本走入其生命週期的末期。企業中原來應用甚廣如Oracle 11gR2目前已經退出支持，只爲某些特殊客戶提供有限並且是付費式的技術支持。客戶需要將老舊的數據庫遷移到19c等較新版本的數據庫來獲得Oracle官方的支持。
另外，IT技術的發展使客戶的IT架構逐步走向雲化和微服務化。許多客戶的採購部門已經開始停止採購IBM、EMC之類的國外的硬件設備，轉而大量採購國產的x86架構甚至是ARM架構的PC服務器。這個變化也極大的推動了企業數據庫遷移。
最後，Oracle 19c及前面版本中引入的許多新特性以及增強屬性，例如12c中引入的cdb與pdb，19c中引入的自動化索引（Automatic indexing）等全新特性也吸引着企業逐步將老舊數據庫升級遷移到新版本，以應用全新的數據庫特性。
以上三個因素是企業Oracle數據庫升級遷移的主要動力。
方案選擇
最近，我們協助了一個電信行業的客戶將其核心繫統的數據庫，按不同的地市分三次遷移到Oracle 19c的數據庫中。整個數據庫遷移環境前後的對比如下：
源數據庫主機平臺：IBM小型機（PowerPC架構）
源庫操作系統：AIX
源庫版本：11.2.0.4
數據庫節點數：2
目標數據庫主機平臺：某國產數據庫一體機（x86架構）
目標庫操作系統：Redhat 7
目標庫版本：19.7
數據庫節點數：6
因爲涉及到核心系統數據庫的遷移升級，客戶從方案可靠性、數據一致性、停機時長以及遷移後數據庫穩定性給我們提出了相應的要求：
- 可靠性：遷移方案成熟可靠，遷移效率高且風險可控；
- 數據一致：遷移前後數據需要保持高度一致；
- 停機時長：包括應用啓停在內的停機維護窗口控制在8-10小時，能在晚上10時開始，次日8點前完成所有操作；
- 穩定性：數據庫遷移後要保持數據庫性能和穩定性。
因此，我們根據客戶的實際環境情況、遷移需求，大致對常用的五種數據遷移方式進行評估和測試，包括：
- Datapump工具： 使用數據泵工具完成源數據庫數據的導出，並傳輸目標數據庫，利用工具將數據導入，安全穩定。
- Rman備份和恢復： 利用源數據庫Rman的備份集在目標主機上進行數據庫恢復，並apply歸檔日誌實現數據完全恢復。
- DataGuard同步： 源數據庫與目標數據庫之間實現DataGuard數據同步，在遷移完成後斷開DataGuard同步，目標數據庫升級爲生產環境。
- GoldenGate同步： GoldenGate實現部分表或用戶的數據邏輯同步，確認數據一致後將數據同步斷開。
- XTTS： 在可傳輸表空間實現數據初始化，並且通過增量數據備份和恢復實現數據同步。
下表是我們經過評估和測試後的對比：
結合實際遷移前後環境以及客戶的遷移需求，我們分別排除了Rman、DataGuard、以及Data Pump三種方案，而最終選擇使用GoldenGate的方案。爲什麼要使用GoldenGate來遷移呢？主要是考慮到以下因素：
首先，GoldenGate可以通過Datapump或Rman的方式提前將所需要的數據遷移到目標數據庫，數據變化再通過GoldenGate實現秒級同步。應用停機後，只需要確認同步狀態OK，斷開GoldenGate同步，就完成了數據同步的動作，停機實際時間非常短。
其次，GoldenGate實際上是一種邏輯複製同步的方式，避免了物理複製以及Rman恢復等方式不能跨主機平臺、操作系統以及數據庫版本進行數據同步的問題。
考慮到停機時間、風險以及業務影響等因素，本次整個數據庫升級遷移實際上分三次完成，每次遷移工程遷移該數據庫中的部分地市用戶（這些地市用戶通過不同的schema加以區分）。因此，GoldenGate可以通過配置實現部分schema或者表數據的過濾，以此實現數據庫中部署數據的實時同步。數據遷移同步更加靈活且可操作性更強。
最後，GoldenGate在客戶的數據容災應急等環境中應用廣泛，因此我們技術團隊在GoldenGate數據同步，在數據災備、應急同步、數據遷移等場景下有較深厚的技術積累。
方案實施
基本方案確定後，我們還需要制定具體的實施方案。俗話說：一根針不會兩頭尖。我們在GoldenGate帶來遷移便利的同時，也需要考慮其帶來的風險。
GoldenGate本質上是基本邏輯同步的方式，相對於Rman以及DG等物理同步的方案，可靠性有所不及。因此，一方面要揚長避短，實現數據最終一致性目標，調整實施方法實現多通道分散式同步；另一方面，在同步過程中驗證測試+實時檢查保障數據同步和時延。
所以整個實施過程我們大致劃分爲四個階段：
1、前期準備
前期準備是整個實施的關鍵一環，好的前期準備工作是整個數據庫升級遷移的實施保證。前期準備的工作除了基本設備的安裝以外，我們重點要做好以下幾項工作：
首先是數據庫的測試，應用RAT等自動化測試工具以及應用聯調等人工測試手段聯合，有效地釋放由於數據庫版本升級以及硬件平臺改變所引入的風險。例如：參數設置、新特點、SQL執行計劃、性能等等可能引起升級前後重大問題。在數據遷移前，想方設法將這些問題加以解決。
另一項關注的重點是數據同步範圍的梳理及規劃。仔細梳理待遷移數據，按照數據的重要程度、業務關聯度、數據量的大小以及數據變化量，以表爲單位對數據進行分門別類，並且以此爲基礎做出OGG數據同步通道的初步規劃。
一般可參考的原則是，將小表和修改頻率較小表的抱團處理，將大表和數據變化頻率較大的表作單獨通道處理。這樣做帶來的好處是：一方面，分散數據同步的壓力，降低數據時延；另一方面，即使偶發性因素導致數據同步失敗或者數據不一致，也可以按通道重新初始化數據，避免全量數據的重新初始化。
此外，值得特別注意的是並非所有數據類型OGG都可以支持，部分數據類型不能同步或存在一些限制。儘管這些數據類型通常不太常用，但是我們在進行數據梳理的時候要對這些限制類型進行小心判別。
2、數據初始化
數據初始化是一個操作密集型的步驟，一般而言我們會視乎數據初始化的數據量在正式割接前2-3天完成數據初始化。儘早完成數據初始化並拉起OGG的數據同步，可以讓我們有充足的時間進行異常問題處理，有利於工程的順利開展。
3、監控與優化
OGG數據初始化以後，我們在割接前需要持續監控和優化數據同步通道。
監控的內容主要會涉及到：
- 同步進程的狀態
- 同步數據的時延
- 源庫以及目標庫的數據庫監控
- 源庫和目標主機的資源開銷
- ……
依照監控的結果，我們會重新調整OGG同步通道。例如，將一個變化量比較大且數據量大表從現有的OGG同步通道分離出來，獨立成爲一個同步通道降低整體同步數據時延。
此外，在這個階段我們通常還會針對一些靜態表和配置表進行全量的數據覈對，降低實際割接時數據覈對的工作量和時間。
4、數據割接
數據割接是應用停機後，停止OGG所有同步鏈路和確認數據同步完成，將目標數據庫正式啓用爲新生產環境的過程。在這個過程中，大致會分爲四個步驟：
每個步驟會涉及多個操作及檢查點，並且由於數據割接通常是在深夜（至少是晚上10點以後）才啓動，因此我們非常強調操作的準確性，一般的原則是：
- 複雜的操作過程，通過自動化腳本處理，保證高效、準確！
- 驗證後的割接方案細化到指令級別，每一條指令均責任到人！
- 採用Double Check機制，保證執行到位，如有異常及時通報。
另外，作爲數據遷移項目，我們還需要保障的是數據的準確性。爲此，我們一般會開發一些專門的腳本和工具進行前後數據的稽覈和對比。對比的範圍包括數據對象的核對、數據結構（字段、類型、長度等）的核對、數據總量（記錄行數）的核對以及實際數據記錄的核對。實際工作中，全量數據記錄我們一般採取主鍵+數據MD5值的方法進行對比。這種方式可以極大地降低數據對比的時長和實際資源開銷。
當然即使預留了一定數據稽覈時間（一般爲1小時內）以及採取MD5方法，實現全量幾十TB數據稽覈也不太現實。因此我們需要做出一些取捨，以我們這次遷移爲例：
一方面，許多數據質量的校驗和稽覈工作可以與其他過程和操作並行，這樣可以充分利用時間。例如由於我們整個遷移工程中有Oracle TT cache group重建的步驟,此時，數據庫還沒有業務接入，我們可以利用這段時間做好核心數據的稽覈工作。
另一方面，數據質量校驗還需要根據數據的重要情況做出一致性稽覈取捨。我們一般會對整體數據進行分類，如基本處於的靜態數據（如大部分的配置數據、產品定義等）之類，我們是在遷移前已經進行了校驗，只會監控是否有數據變更就OK。如核心的業務數據，則會利用遷移後進行全量的校驗。如類似於不重要的過程數據，則只會進行記錄數量以及抽樣的校驗就好了。
最後，我們會跟甲方進行有效溝通，根據測試的情況、風險等級、停機時長等因素確定最終的數據稽覈方案。
實施總結
歷時一個月分三次工程，我們將該省級電信運營商的核心繫統數據庫遷移到Oracle 19c上。數據庫運行至今非常穩定，並且數據庫的性能也得到不少提升。
當然，我們後面也將會面臨一些全新的問題需要做出應對，包括像一些巨無霸級別的地市，遷移方案估計需要做出一定的調整和修訂，這些也將是我們未來的重大考驗。但是儘管如此，我們對本次Oracle 19c的升級遷移總結爲以下幾點：
- 良好的前期準備和規劃是項目成功的一半；
- 善用同步工具，將遷移提早完成；
- 監控與不斷優化數據同步通道；
- 割接操作保持傻瓜化，雙人檢查尤爲必要；
- 有效的數據稽覈確保數據一致性；
- 謹慎，謹慎，再謹慎！
Q&A
Q1：Oracle 9i支持OGG嗎？
A： 9i是支持的，但需要舊版本的OGG，這個估計要mos申請介質。最新兩個OGG版本具體的數據庫版本支持可以參考官方鏈接下載支持列表：https://www.oracle.com/middleware/technologies/fusion-certification.html
值得注意的是，每種數據庫OGG支持的範圍有所差異，有的版本只能作爲同步的目標端（delivery），有的數據庫源端和目標端均支持，有的數據庫可以支持DDL操作。請各位使用前先確認一下。
Q2：用OGG同步數據支撐業務場景有什麼限制因素？
A：主要的限制因素我認爲如下：
- 數據庫的日誌，需要打開歸檔、附加日誌等；
- 部分數據類型和數據對像的限制，如Oracle數據庫裏面的臨時表、物化視圖；
- 同步的數據表最好有主鍵；
- 數據庫大事務以及網絡帶寬等帶來的數據時延；
- 數據庫日誌分析和過濾帶來的數據庫的額外資源開銷；
- 邏輯數據複製有可能會帶來數據不一致，需要額外關注數據一致性稽覈。
Q3：數據是如何稽覈的？
A： 我們一般數據稽覈會從以下的維度來測量：
- 數據對像的一致性；
- 數據結構的一致性；
- 數據記錄數量的一致性；
- 具體數據記錄的一致性。
Q4：TT重建怎麼理解？
A：當時講解的時候可能有點口誤，實際應該是TT cache group的重建。TT是Oracle的一種內存庫產品，cache group是一種Oracle物理庫（也就是我們現在的19c）和內存庫的一種數據同步機制。重建TT cache group的目的是將內存庫所需要的數據從物理庫裝載到內存庫中並實現數據庫之間的實時同步。
Q5：遷移完成後會和預期方案進行比較和評估嗎？
A：事後的方案覆盤是我們實施類似重大工程時必須做的。我們在每次遷移測試和實施，都會在checklist機制中記錄所有操作以及檢查點的時長、實施效果、檢查問題等關鍵要素，並對遷移過程進行全程覆盤。通過對方案進行各方面的比較和評估，我們會找到需要優化的細節點，並討論進一步具體的優化方案，以利於後續工程的開展。
作者介紹：
梁銘圖，新炬網絡首席架構師
- 十餘年數據庫運維、數據庫設計、數據治理以及系統規劃建設經驗，擁有Oracle OCM和ACE Director、Togaf企業架構師（鑑定級）、IBM CATE等認證，曾獲dbaplus年度MVP、華爲雲MVP等榮譽，並參與數據資產管理國家標準的編寫工作。
- 在數據庫運維管理和架構設計、運維體系規劃、數據資產管理方面有深入研究。
原文鏈接：