众所周知,LOAD实用工具的导入效率比import/insert高许多,原因是该工具直接针对数据库的页面进行操作,因此节省了绝大部分的导入开销。但有时导入效果也并不尽如人意,下面就是一例:
一张28列,列大小为254 byte的表,该表没有任何索引和约束,导入50万条数据,原来导入时间为大约15分钟。从以往的经验来看,50万条数据应该不需要这么长的时间,于是开始优化。
首先调整数据库的参数 util_heap_sz ,从5000调整为30000 ,该参数IBM官方建议值为:10000* CPU 数量。最终结果收效甚微。
后来又依次调整load语句中的fastparse,cpu_parallelism,disk_parallelism,data_buffer等选项,依然没什么成效,导入时间保持在15分钟上下。
这时忽然想到一直没有查看load过程中给出的message信息,于是在load语句中加上messages xxxxxx,装载完成后查看该log文件,问题原来出在这里!在装入过程中,有一列的宽度为4,但是表中定义该列的宽度为2,因此针对每一行,load工具都对该列进行了截断操作,从而导致整体装入速度大幅降低。以往使用load工具时,未使用message文件查看load工具给出的提示信息,所以没有发现这一点,而load query也未能给出load进行过程中的详细信息。
重新调整完列的宽度后,load速度从原来的15分钟,降到了30秒,质的飞跃!
总结:
1、load过程中一定要指定message文件,会发现许多有用的信息,待装入过程稳定下来后再去掉该选项;
2、load实用工具的默认选项已经能够满足大部分装载的需要,在此基础上调整参数,收效甚微;
3、一定要保证被导入的文本文件中字符串的长度不超过表中定义的长度,否则load工具会进行截断操作,该操作十分耗时。
一张28列,列大小为254 byte的表,该表没有任何索引和约束,导入50万条数据,原来导入时间为大约15分钟。从以往的经验来看,50万条数据应该不需要这么长的时间,于是开始优化。
首先调整数据库的参数 util_heap_sz ,从5000调整为30000 ,该参数IBM官方建议值为:10000* CPU 数量。最终结果收效甚微。
后来又依次调整load语句中的fastparse,cpu_parallelism,disk_parallelism,data_buffer等选项,依然没什么成效,导入时间保持在15分钟上下。
这时忽然想到一直没有查看load过程中给出的message信息,于是在load语句中加上messages xxxxxx,装载完成后查看该log文件,问题原来出在这里!在装入过程中,有一列的宽度为4,但是表中定义该列的宽度为2,因此针对每一行,load工具都对该列进行了截断操作,从而导致整体装入速度大幅降低。以往使用load工具时,未使用message文件查看load工具给出的提示信息,所以没有发现这一点,而load query也未能给出load进行过程中的详细信息。
重新调整完列的宽度后,load速度从原来的15分钟,降到了30秒,质的飞跃!
总结:
1、load过程中一定要指定message文件,会发现许多有用的信息,待装入过程稳定下来后再去掉该选项;
2、load实用工具的默认选项已经能够满足大部分装载的需要,在此基础上调整参数,收效甚微;
3、一定要保证被导入的文本文件中字符串的长度不超过表中定义的长度,否则load工具会进行截断操作,该操作十分耗时。