Home

DB2 分区数据库环境数据库迁移操作

866字 预计阅读时间：4.3分钟 数据库

这篇文章记录 DB2 分区数据库环境中，一种基于 db2look + db2move 的迁移方法。适合做结构重建和数据重装载，不依赖底层备份镜像直接恢复。

迁移思路

这个方案大致分成三步：

  1. 在源端导出表结构和数据
  2. 把迁移文件传到目标端
  3. 在目标端重建数据库并执行加载

它的优点是更灵活，缺点是对 DDL、表空间路径和加载后状态处理要求更高。

第一步：源端导出

先在源端准备迁移目录：

mkdir -p /db2data/migration && cd /db2data/migration

导出表结构

su - db2inst1 -c "db2look -d GXCXXTDB -e -a -l -x -m -o /db2data/migration/gxcxxtdb.sql"

导出数据

su - db2inst1 -c "cd /db2data/migration && db2move GXCXXTDB export -parallel 4"

如果当前环境不支持 parallel 参数，就把这一项去掉。

第二步：把文件传到目标端

在目标机器先创建接收目录：

ssh 10.0.1.101 "mkdir -p /db2data/migration"

然后把迁移文件整体拷过去：

scp -r /db2data/migration/* 10.0.1.101:/db2data/migration/
ssh 10.0.1.101 "chown -R db2inst1:db2iadm1 /db2data/migration"

第三步：在目标端重建数据库

方案一：基础方案

这是最直接的做法：

su - db2inst1 -c "db2 drop db GXCXXTDB"
su - db2inst1 -c "db2 \"CREATE DATABASE GXCXXTDB ON /db2data USING CODESET GBK TERRITORY CN PAGESIZE 32768\""
su - db2inst1 -c "db2 connect to GXCXXTDB && db2 -tvf /db2data/migration/gxcxxtdb.sql"
su - db2inst1 -c "cd /db2data/migration && db2move GXCXXTDB load -parallel 8"

但这个方案不够完整，真正落地时，通常还需要处理路径、日志和 check pending 等问题。

方案二：更完整的迁移方案

文中后面补全的方案更适合实际使用。

1. 先准备容器目录

在两个节点都创建好目标容器目录：

ssh db2inst1@db2dpfa "mkdir -p /db2data/containers && chown db2inst1:db2iadm1 /db2data/containers"
ssh db2inst1@db2dpfb "mkdir -p /db2data/containers && chown db2inst1:db2iadm1 /db2data/containers"

2. 清理旧库并重新创建数据库

su - db2inst1 -c "db2 drop db GXCXXTDB"
su - db2inst1 -c "db2 \"CREATE DATABASE GXCXXTDB ON /db2data USING CODESET GBK TERRITORY CN PAGESIZE 32768\""

3. 调整数据库配置

su - db2inst1 -c "db2 update db cfg for GXCXXTDB using LOGFILSIZ 25600 LOGPRIMARY 50 LOGSECOND 100 UTIL_HEAP_SZ 100000"
su - db2inst1 -c "db2 terminate"

4. 修改 DDL 里的旧路径

如果导出的建库脚本里还带着旧环境路径，就先替换成目标环境的新路径：

su - db2inst1 -c "sed -i 's/\/a\/b\/c\//\/db2data\/containers\//g' /db2data/migration/gxcxxtdb.sql"

5. 执行 DDL

su - db2inst1 -c "db2 connect to GXCXXTDB && db2 -tvf /db2data/migration/gxcxxtdb.sql"

6. 消除 Backup Pending

su - db2inst1 -c "db2 backup db GXCXXTDB to /dev/null"

7. 加载数据

su - db2inst1 -c "cd /db2data/migration && db2move GXCXXTDB load -lo identityoverride -parallel 4"

8. 处理 Check Pending

如果表进入 Check Pending，可以先生成批处理脚本：

su - db2inst1 -c "db2 -x \"select 'set integrity for '||trim(tabschema)||'.'||trim(tabname)||' immediate checked;' from syscat.tables where status='C'\" > /db2data/migration/check.sql"
su - db2inst1 -c "db2 -tvf /db2data/migration/check.sql"

如果依赖关系复杂，单条拼接式处理有时更稳：

su - db2inst1 -c "db2 -x \"select trim(tabschema)||'.'||trim(tabname) from syscat.tables where status='C'\" | tr '\n' ',' | sed 's/,$//' > /tmp/table_list.txt"
su - db2inst1 -c "db2 \"set integrity for $(cat /tmp/table_list.txt) immediate checked\""

后续建议

数据加载完成后，建议再补一轮统计信息收集。否则即使数据进来了，优化器统计信息不完整，后续性能也可能不稳定。

总结

这种迁移方式的关键，不在于“把数据导出来”，而在于目标端是否真的具备完整重建条件。实际成功率通常取决于下面几件事：

  • DDL 里的旧路径有没有改干净
  • 容器目录是否提前准备好
  • Backup Pending 和 Check Pending 是否处理完成
  • 加载后是否补做统计信息

把这些点都收住，这条路径会比想象中稳定很多。

数据库