SQL Server DBA 30 題實戰解析：第 7 題 — 線上系統 5,000 萬筆資料遷移 2,000 萬並刪除源資料方案

針對「SQL Server DBA 三十問」第 7 題，筆者基於 SQL Server 2000 實務環境 (假設表有主鍵 ID) 提供完整作業方案與風險控制細節。

核心三步走策略

步驟 1：建立變更追蹤表

建立 t_update_log 記錄遷移期間發生的 INSERT/UPDATE/DELETE 操作主鍵 ID，作為後續資料一致性補償依據。

步驟 2：高效匯出 2,000 萬筆至目標伺服器

使用 DTS 匯出至新資料庫新表 t_2000w。無大欄位約 3 小時完成；含 varchar/text/ntext 等大物件則視資料量而定。

步驟 3：源表原地重建保留 3,000 萬筆

1. 建立同結構新表 t_3000w。
2. 將需保留的 3,000 萬筆匯入 t_3000w。
3. 使用 sp_rename 互換表名：t_5000w → t_5000w_bak、t_3000w → t_5000w，瞬間完成切換，避免大量 DELETE 產生海量日誌與鎖升級。

關鍵風險點與應對方案

Q1：遷移期間資料被更新如何保證準確性？

A1：利用步驟 1 的 t_update_log，將遷移期間的異動記錄補充匯入目標表 t_2000w；對被刪除的 ID，從 t_2000w 中對應刪除，確保目標端資料與遷移起始點一致。

Q2：sp_rename 切換耗時較長且有新資料寫入怎麼辦？

A2：修改應用寫入路徑。新建 t_6000w (結構同 t_5000w)，Identity 種子設為 6,000 萬，新增資料導向此表。若資料存取統一經由存儲過程，僅需修改 SP 即可實現不停機熱切換；若為散落的動態 SQL，建議安排停機窗口，寧可暫停服務也不可接受資料遺失。

上線前必做：演練與回滾預案

• 在測試環境完整演練一次，記錄每步耗時。
• 準備回滾腳本，確保失敗時能在 RTO 內恢復原狀態。
• 雖方案支援熱切換，但仍建議爭取停機窗口，以換取絕對資料安全。

此方案展示了 DBA 在海量資料操作中，兼顧效能、一致性與業務連續性的系統性思維。