資料移轉筆記

標籤：

最近接到任務做系統改造升級，其中一項主要工作是資料庫的遷移。

舊系統沒有測試環境，每天產生的資料約30萬，資料總量約1.5個億，130多張表，30多個預存程序，資料庫為SQL Server 2000，沒有設計文檔。

新系統使用 Oracle 11g，結構與舊系統基本不同。

新系統上線同時舊系統下線，所以要求資料在系統切換前全部匯入，客戶一如既往的著急。

操作步驟：

1. 首先備份生產環境資料庫，並在開發環境還原

2. 統計舊系統資料庫每張表的行數，先把沒有資料的表刪除

3. 探索資料庫小於100的表基本都未配置表，這類表沒必要遷移，瞭解商務規則對應關係後可直接在新系統建立

4. 對剩下的表按名稱排序，從中大概可看出各模組的劃分，刪除中間表和暫存資料表。至此，對舊庫的整理告一段落，開始研究新系統

5. 分析新系統，看看新系統如果正常運行資料應該是什麼樣，再看舊系統是否能提供相應資料，對資料對應關係做圖

6. 用 Java 寫了遷移程式，開始向測試環境遷移，但是效果不理想，因為表結構不同，查詢比較繁瑣，且插入的速度很慢，計算了一下，全部遷移完需要跑幾個星期，很失落

7. 開始從代碼上最佳化，首先考慮了批量執行，速度明顯提高，但是仍不夠理想，因為插入的是同一張表，無法多任務同時跑

8. 放棄了 Java 直接匯入的方式，改成 Java 產生 Oracle 的指令碼，再使用 SQLPLUS 的命令匯入，速度再次提升

9. 很無奈，新系統有大量的自增主鍵和外部索引鍵關聯，直接匯入資料無法通過驗證。所以調整策略，在SQL Server建立了和Oracle 一樣的表結構，通過各種 Select 和 Insert 將舊系統資料匯入建立的表，匯入的過程中建立主鍵，對於超多資料量的表，可以在此過程中直接分組，全部匯入後再通過 Update 更新關聯外鍵。至此，資料庫從異源異構變成了異源同構

10. 接下來遷移工作就順暢多了，還是用 Java 產生匯入指令碼，再產生批次檔，在目標庫直接還原，不用擔心約束和網路中斷的問題了

11. 但是超過1億條的資料匯入仍需很長時間，為了保證切換時的順暢，將資料按時間點切分，已穩定的資料預先匯入新庫，其餘資料增量插入。

最終算是矇混過關了，沒做過類似的遷移工作，沒想到會遇到這麼多坑。兩周后會有個大10倍的庫做遷移，希望順利！

資料移轉筆記