DB2 LOAD 工具使用技巧集合

核心提示： 清单 4. 示例 2 —— IXF 文件LOADfromtestofixfmodifiedbyforceininsertintotabname注：当加载的数据在表结构完全相同的情况下还出现了一些非空字符或字符被截断错误，可以选择使用 ixf 格式并指定 forcein 文

清单 4. 示例 2 —— IXF 文件

LOAD　from　test　of　ixf　modified　by　forcein　insert　into　tabname　

注：当加载的数据在表结构完全相同的情况下还出现了一些非空字符或字符被截断错误，可以选择使用 ixf 格式并指定 forcein 文件修饰符来避免这种问题。

错误行的定位

在 DB2 V8 及 DB2 V9.1 环境下，执行 load 加载数据的过程中可能会出现某些行的部分列的数据不符合目标表类型或格式的要求，从而导致其被截断或被拒绝，那么找到源数据库中的故障行和故障列分析其故障原因就比较重要。但是在这种故障情况下输出的错误信息可能如下：

表单 5. 执行错误信息

SQL3125W　因为数据比目标数据库列长，所以第　"F4-6"　行第　"5"　
列中的字符数据被截断。　
　SQL3110N　实用程序已完成处理。从输入文件读了　"13"　行。　
　SQL3519W　开始装入一致点。输入记录数　=　"13"　。　
　SQL3520W　“装入一致点”成功。　
　SQL3515W　在时间　"2009-01-04　11:18:53.301919"，实用程序已经完成了　"LOAD"　。　
　SQL3107W　消息文件中至少有一条警告消息。　

其中故障的行的标识为“ F4-6 ”，这表示 id 为 4 的 CPU 处理的第 6 行的数据出现了故障，那么通过这个信息我们是无法从源文件中找到故障行的，我们只能通过总的行号标识来找到故障行，所以在这种情况下只能通过单 CPU 的处理来找到故障行。

这就需要将 load 工具的 CPU_PARALLELISM 选项设置为 1，保证 load 在加载数据的过程中始终只适用一颗 CPU，那么此时行标识中 CPU 部分始终会是“ F0 ”，而行部分则就是总的行数了。