使用IBM Data Studio迁移Windows DB2数据至Linux后查询无结果

这种情况我之前排查过好几次——工具界面显示成功但实际查不到数据，多半是迁移过程里有隐性环节没落实，咱们一步步来定位：

1. 深挖迁移任务的真实执行日志 #

别只信界面的“成功”提示，先去IBM Data Studio的日志里找细节：

• 路径在 Window > Preferences > IBM Data Studio > Logging 里能找到，重点看有没有警告或隐性错误，比如某些行因约束冲突被跳过、权限不足导致写入失败，或者数据类型转换时的静默报错——有些场景下工具会忽略错误行仍显示“迁移成功”。
• 核对迁移任务的配置：是不是误选了「仅迁移表结构」而非「结构+数据」？不少新手会碰这个坑，默认选项有时候只建表不导数据。

2. 验证目标端表结构与权限 #

• 先在Linux端DB2执行 DESCRIBE TABLE <你的表名>，和Windows源端的表结构逐字段对比：字符集（Windows常用GBK，Linux默认UTF-8）、字段长度、非空约束这些如果不匹配，数据会插入失败但工具未必报错。
• 检查迁移用户的权限：执行 SELECT * FROM SYSCAT.TABAUTH WHERE TABNAME = '<你的表名>'，确认对应的用户有INSERT和UPDATE权限——如果只有读权限，界面显示的“提交行数”就是虚的，实际根本没写入数据。

3. 确认目标端事务与数据存储 #

• 先执行 SELECT COUNT(*) FROM <你的表名> 确认真的无数据，再查有没有挂起的事务：LIST ACTIVE TRANSACTIONS，如果有未提交的事务，手动执行 COMMIT 再查试试——网络波动时Data Studio可能没完成自动提交。
• 如果是分区表，检查是不是数据写到了其他分区：SELECT * FROM SYSCAT.DATAPARTITIONS WHERE TABNAME = '<你的表名>'，看看各分区的行数统计，别只查默认分区。

4. 排查数据迁移的隐性损耗 #

• 对比源端和目标端的表行数：源端执行 SELECT COUNT(*) FROM <你的表名>，和目标端的结果对比——工具显示的“迁移行数”可能是读取的行数，不是实际写入的，比如大表迁移时部分行因特殊字符、主键冲突被静默丢弃。
• 用小表做测试：挑一张只有纯数字的小表单独迁移，看能不能成功查询到数据，排除字符集兼容性问题（比如Windows端GBK的特殊字符在Linux UTF-8下无法插入）。

5. 手动插入验证 #

从源端导出一行数据，用 INSERT INTO <目标表> VALUES (...) 手动插入到Linux端，如果失败会返回具体SQL错误码，比如：

• SQLCODE=-803：主键冲突
• SQLCODE=-407：字段为空但表结构不允许空值
  这些错误往往是工具隐藏的关键线索。

内容的提问来源于stack exchange，提问作者Kirill Achramionok