2,000 個表遷移的方法

轉換或遷移包含 2,000 多個表的數據庫時，最好的方法是什麼？你會從哪裡開始解決這樣的問題？在設計的最初幾週內採取的步驟？風險？假設幾乎沒有關於舊（目前）數據庫的任何資訊？

我採取的方法大致如下（這絕不是完整的）：

1. 要求 您需要了解目前情況的目標。

• 平台（硬體、軟體）的細節，這些版本的版本。在功能可用性方面可能存在依賴性

• 在“從”情況下使用並在“到”情況下需要的功能。考慮到

  • 排隊
  • 分群
  • 高可用性
  • 備份和恢復

2. 分析現狀

• 上面缺少的要求
• 正在使用的 DBMS 或平台特定功能

3. 為完全自動化和可重複的方法而設計。這使它

• 可測試的
• 如果過程較長，可以通宵/週末執行
• 允許迭代解決方案，其中數據庫在項目生命週期內變得越來越完整

4. 在“從”端和“到”端確定係統之間的依賴關係。這將影響遷移的“流程”。
5. 決定如何遷移數據。其中，選擇包括：

• 轉儲和重新載入，可能是通過一些與數據庫無關的格式

  • 如果重新載入，通過“臨時”表然後從臨時表中填充真正的目標表可能會更容易。我對這種方法有很好的經驗。
  • 這也使得允許在切換後手動更正的“輻射”變得更容易（但您也需要控制它）。

• 使用一些數據庫連接技術（例如 Oracle 網關、PostgreSQL 外部數據包裝器）將數據從“來自”數據庫“吸”到“到”數據庫中。當要執行目標 DBMS 與源相同的遷移時，這種方法通常也是最好的。

• 決定是否使用腳本（主要是 SQL 腳本，但也可能是 Perl/awk 等）或工具（例如，Oracle 曾經有一個名為 Migration Workbench 的產品或 ETL 工具可用於此目的），甚至是“程式”解決方案Java/C# 等。這個決定很大程度上取決於手頭的技能。我的偏好是盡可能使用 SQL。

6. 建構它。

• 如果目標數據模型不同，則確定映射。在這些情況下，ETL 工具可能很方便，但編寫良好的 SQL 也同樣清晰。像所有程式碼一樣，盡量將文件與程式碼映射在一起，而不是放在單獨的文件中。

引用自：https://dba.stackexchange.com/questions/39981