DB2 數據遷移與表空間重構實戰指南：從導出 DDL 到批量載入的完整流程

前言：為什麼需要這份遷移指南？

在企業級 DB2 環境中，因業務增長或架構調整，往往面臨「更換表空間類型」或「整庫遷移至新實例」的需求。本文基於實測環境（IBM x346、雙核 3.2GHz、4GB 內存、RAID 1、DB2 V8.2.4、Windows 2000 Advanced Server、DMS 表空間），整理出一套經驗證的標準化操作流程，實測載入速度可達 60–100 萬行/分鐘，供 DBA 團隊直接參考執行。

核心場景與前置條件

• 觸發場景：需變更現有表空間屬性（如由 SMS 改為 DMS），或將全庫對象遷移至全新建立的數據庫。
• 基線環境：源/目標端版本一致、字符集相同、具備足夠磁盤空間存放中間 IXF 文件。
• 權限要求：具備源庫 SELECT、目標庫 LOAD/INSERT、DBADM 或同等管理權限。

八步走標準化遷移流程

步驟 1：導出完整 DDL 結構腳本

使用 db2cc 控制中心勾選源庫所有表 → 右鍵「生成 DDL」→ 保存為 schema.ddl。
建議同時導出：表、索引、外鍵、檢查約束、視圖、觸發器、序列、權限授予語句。

步驟 2：按需調整 DDL 腳本

使用編輯器全局替換或手動修改：
• 表空間子句改為目標表空間（如 IN GATHER）
• 移除不再需要的分區鍵、壓縮屬性等
• 若目標庫 Schema 名不同，同步修改 CREATOR/SCHEMA 限定符

步驟 3：建立目標庫與 DMS 表空間

CREATE DATABASE TARGETDB AUTOMATIC STORAGE NO;
CONNECT TO TARGETDB;
CREATE LARGE TABLESPACE GATHER PAGESIZE 32 K
    MANAGED BY DATABASE
    USING (FILE '/db2data/GATHER_01' 2G, FILE '/db2data/GATHER_02' 2G)
    EXTENTSIZE 32 PREFETCHSIZE 64 BUFFERPOOL IBMDEFAULTBP;

步驟 4：執行 DDL 重建對象骨架

db2 -tvf schema.ddl -z ddl.log
執行後檢查日誌，確認無「SQL0601N 對象已存在」等阻斷性錯誤；非阻斷警告可後續處理。

步驟 5~6：自動化生成 EXPORT / LOAD 腳本

為避免手工逐表編寫，提供兩段 Java 參考代碼，分別查詢 SYSIBM.SYSTABLES 生成批量命令文件。

附錄 1：生成 EXPORT 腳本（Java 片段）

public void createExportFile(Connection conn, String creator, String filePath) throws Exception {
    String sql = "SELECT NAME FROM SYSIBM.SYSTABLES WHERE CREATOR = '" + creator + "' AND TYPE = 'T'";
    List tables = new ArrayList<>();
    try (Statement st = conn.createStatement(); ResultSet rs = st.executeQuery(sql)) {
        while (rs.next()) tables.add(rs.getString(1));
    }
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < tables.size(); i++) {
        sb.append("db2 \"EXPORT TO aa").append(i + 1).append(".ixf OF IXF SELECT * FROM ")
          .append(tables.get(i)).append("\"\r\n");
    }
    Files.write(Paths.get(filePath), sb.toString().getBytes());
}

附錄 2：生成 LOAD 腳本（Java 片段）

public void createLoadFile(Connection conn, String creator, String filePath) throws Exception {
    String sql = "SELECT NAME FROM SYSIBM.SYSTABLES WHERE CREATOR = '" + creator + "' AND TYPE = 'T'";
    List tables = new ArrayList<>();
    try (Statement st = conn.createStatement(); ResultSet rs = st.executeQuery(sql)) {
        while (rs.next()) tables.add(rs.getString(1));
    }
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < tables.size(); i++) {
        sb.append("db2 \"LOAD FROM aa").append(i + 1).append(".ixf OF IXF REPLACE INTO ")
          .append(tables.get(i)).append(" COPY NO WITHOUT PROMPTING\"\r\n");
    }
    Files.write(Paths.get(filePath), sb.toString().getBytes());
}

步驟 7：源庫端執行 EXPORT

db2 connect to SRCDB user src_user using src_pwd
db2 -tvf export_all.sql -z export.log
db2 connect reset

生成的 aa1.ixf、aa2.ixf… 依序對應各表，IXF 格式自帶列定義，跨平台遷移最穩健。

步驟 8：目標庫端執行 LOAD

db2 connect to TARGETDB user tgt_user using tgt_pwd
db2 -tvf load_all.sql -z load.log
db2 connect reset

關鍵參數說明：
• REPLACE：清空表後裝載（避免主鍵衝突）
• COPY NO：不做備份映像，適合初始裝載窗口
• WITHOUT PROMPTING：無人值守批量執行

實測性能基線與優化建議

常見坑點與應對

1. 外鍵順序：LOAD 父表先於子表，或載入後 SET INTEGRITY IMMEDIATE CHECKED。
2. 身份列：IXF 保留身份值，LOAD 需加 IDENTITYOVERRIDE 或載入後 ALTER TABLE ALTER COL RESTART WITH …。
3. LOB 大對象：若含 LOB，建議改用 CURSOR 方式 LOAD FROM CURSOR 避免中間文件膨脹。
4. 編碼不一致：跨平台時確認 CODEPAGE 參數，必要時在 EXPORT 指定 MODIFIED BY CODEPAGE=1386。

遷移後驗收清單

• 行數核對：SELECT COUNT(*) FROM src.tab MINUS SELECT COUNT(*) FROM tgt.tab
• 抽樣比對：關鍵業務字段 MD5 或 CHECKSUM 一致性
• 索引/統計：RUNSTATS ON TABLE schema.tab AND INDEXES ALL
• 權限同步：對比 SYSCAT.TABAUTH、COLAUTH 並補授

總結

本文提供的「DDL 先行 → IXF 中轉 → LOAD 批量」模式，兼顧了結構精確復刻與大數據吞吐效率，適合停機窗口較長的傳統遷移場景。若業務要求「近零停機」，請改用 DB2 HADR + 表空間滾動轉發 或 IBM InfoSphere CDC/Replication 異構同步方案。