【作者介紹】祝磊，個人喜歡IT行業，目前從事資料庫工作，包括Oracle、MySQL、MongoDB、SQLServer等資料庫的維護，喜歡鑽研開發技術，尤其對Java程式的開發感興趣。曾於中國聯通系統整合公司、中公網醫療資訊科技有限公司，做過資料庫技術支援。現在海量資料，負責公司華東區客戶群體的Oracle、MySQL、MongoDB等資料庫的維護工作。

責編 | 韓楠

約 2355 字 | 5 分鐘閱讀

你好，今天我將分享一些Oracle資料庫資料遷移相關的經驗。對於資料庫日常維護，在資料庫跨版本升級、異構資料庫資料遷移、資料同步等大型專案中，資料遷移是其工作中必不可少的一環。而且，單純的資料遷移在資料庫日常維護中也非常普遍。

本文基於Oracle資料庫的資料遷移，結合個人專案中遇到的一些問題，或者注意事項進行闡述，希望對你有所幫助。

01 ⎪ 資料庫跨版本升級

某金融客戶的災備中心建設專案中 ，有三套業務系統的Oracle資料庫，涉及到生產端的改造：從惠普小型機下遷到LINUX，從HA或單例項架構調整到oracle rac，並且版本從11.2.0.4升級到19c。

這三套資料庫的改造升級，得考慮三點：

• 首先，考慮停機維護視窗（19:00到次日凌晨2:00）；

• 其次，考慮資料庫的大小（均在400G以下）；

• 再次，考慮源生產端主機檔案系統空間（資料庫壓縮備份與非壓縮備份佔用空間不同，備份與恢復所用時間也不同）。

綜合三點考慮因素，結合客戶升級實際需求跨版本、跨平臺，因此選擇oracle的資料泵進行改造升級。客戶關心的永遠是：形成的改造升級方案，是否能在有限時間內完成、改造升級之後應用業務是否完全相容、新資料庫系統是否能承受業務負載壓力。

因此，正式改造升級前的演練必不可少，根據改造升級演練初步方案實施：

1. 記錄改造升級過程中的每一步耗時；

2. 各項資源使用情況；

3. 區分哪些事項可以事先做；

4. 資料遷移後的資料校驗及善後。

三套資料庫改造升級的實際實施中，需要格外注意無效物件的處理，並不能簡單地以資料泵按全庫或者按方案方式備份，並恢復到目標環境中；需要源資料庫資料備份前檢視並記錄無效物件詳細資訊，目標資料庫資料恢復前與資料恢復後檢視，並記錄無效物件詳細資訊。

個人發現，oracle 19c根據安裝元件選擇的不同，安裝完成的新例項中會有一些原始的無效物件，這些無效物件，需要與客戶資料庫改造升級中源生產業務庫的無效物件區別開。

並且，需要了解源生產業務庫中哪些無效物件必須處理、哪些無效物件可以忽略。

02 ⎪ 異構資料庫資料遷移

某汽車製造業的OA系統升級改造專案中， 要求將業務系統資料庫從oracle 11.2.0.4遷移到mysql 8.0.x，遷移工具使用的國產遷移工具；源端業務庫mysql的大小為400G，停機維護視窗為週末兩天時間。

客戶關心的問題依然是：資料遷移能否如期完成，遷移過程中遇到的問題能否有效把控。

因此，針對該專案資料遷移前後做了兩輪測試演練，包括正式資料遷移實施，暴露出比較多的問題，有些是流程問題，有些是遷移工具問題、也有資料庫自身約束問題。

首先，專案實施過程中的流程問題 ，資料遷移兩次演練，包括正式遷移時的mysql版本均不相同，為專案實施問題排查埋下隱患。

其次，遷移工具問題 ，遷移資料轉換過時，遷移工具將oracle的varchar2 2000轉換為mysql的varchar 4000，如果單張表有多個欄位長度累加長度超過65535，將導致mysql建表失敗。

再者，mysql資料庫的自身約束問題， 資料遷移測試演練中，如果單表單欄位長度超過1024並且該欄位上有索引，那麼mysql將無法在該欄位上建立索引。

另外，在該專案遷移過程中，透過遷移測試演練發現一張日誌大表超過180G並且資料遷移很慢，後期的正式遷移前，將該表資料清空大大壓縮了資料遷移的耗時。

03 ⎪ 資料同步

某通訊客戶業務資料庫改造升級專案中 ，涉及一套oracle 11.2.0.4資料庫升級到oracle 19c，作業系統版本從rhel6升級到rhel7，資料庫資料量幾十T，停機維護視窗資料庫側2小時內完成。

基於客戶業務系統資料庫的實際情況與升級要求，只能選擇oracle的ogg資料同步工具開展工作。

由於專案從啟動到交付只有20天時間，沒有充足的時間進行測試，實際專案實施中目標端單次資料庫初始化就將近4天時間，並且專案實施過程中有比較棘手的問題，整個專案的實施也是驚心動魄。

首先，該專案實施過程中面臨的第一個問題，ogg源端資料庫抽取程式很慢，導致抽取延遲不斷增加。

為了排查問題定位引起抽取程式慢的根因，專案實施中採取的策略是將抽取程式從1個程式拆分成4個，從而定位到引起抽取慢的具體表（表中含特殊資料型別的欄位）。

其次，解決完源端抽取慢問題後，又面臨目標端應用程式同步資料緩慢問題，專案實施中採取的策略依然是程式拆分，定位資料同步報錯或者十分緩慢的表（從同步程式中剔除，爭取客戶同意後，在業務割接視窗採取資料泵方式遷移）。

再次，ogg目標端應用程式同步慢問題。有些透過程式拆分可以有效處理，有些則是透過oracle官方mos查詢後調整同步程式的部分引數解決的。由此可知，資料遷移中化整為零的策略，能夠幫助要求緊急的專案穩步推進。

針對Oracle資料庫資料遷移，專案實際實施之前，總有不可預知的問題。 那麼，怎樣儘可能多地發現並有效處理未知問題？

都說“實踐是檢驗真理的唯一標準”，測試演練最能預先探測術遷移專案中可能遇到的問題，比如：應用業務的相容性、應用業務的連線問題、資料庫伺服器檔案系統容量問題、目標環境資料庫表空間的容量問題、異構資料庫之間的約束問題、資料遷移工具效率及最佳化等等。

尤其是Oracle資料庫遷移專案，專案應預留一定的測試演練時間，在測試演練的基礎之上，將專案實施中可能出現的問題實際探測出來，並針對性地做有效的處理方法，從而有效地保證資料遷移專案順利成功實施。

04 ⎪ 結語

關於Oracle資料遷移，結合個人經驗需要考慮：異構、跨平臺、跨版本，資料庫的資料量、特殊物件、無效物件，結合資料遷移專案的總體時間要求，以及停機維護視窗，選擇合理的資料遷移工具，再輔以必要的測試演練，保證遷移專案順利成功完成。

那麼，關於Oracle資料庫資料遷移，您有什麼想說的嗎？歡迎評論區裡進一步討論交流。我們下期分享見。

拿三個專案，跟你聊聊Oracle資料庫資料遷移的一些經驗

相關文章