互联网服务 数据库
DMS表空间数据插入效率
DB2 DMS表空间。操作：
我做数据插入。第一次表刚建立完成，数据为空，插入，1g数据，需要20min。
但是truncate后，第二次插入，1g数据只需要8min，同样的表。
还请各位专家能够帮忙分析下？需要提供啥就和我说
补充我的测试结果和现象：
假如首次先插入1g的数据，那么是1g 20min。重复插入则1g 8min
假如先插入1g的数据，再插入512M，那么512m的数据，是10min
假如先插入1g的数据，然后删掉该表，那么再插入512M的数据，是5min
那么表明：是否有可能是DMS向系统申请空间导致的资源消耗？请大家一起讨论下
我做数据插入。第一次表刚建立完成，数据为空，插入，1g数据，需要20min。
但是truncate后，第二次插入，1g数据只需要8min，同样的表。
还请各位专家能够帮忙分析下？需要提供啥就和我说
补充我的测试结果和现象：
假如首次先插入1g的数据，那么是1g 20min。重复插入则1g 8min
假如先插入1g的数据，再插入512M，那么512m的数据，是10min
假如先插入1g的数据，然后删掉该表，那么再插入512M的数据，是5min
那么表明：是否有可能是DMS向系统申请空间导致的资源消耗？请大家一起讨论下
附件：
insert_over_500.res (606.66 KB)
insert_iner_500.res (606.66 KB)
41 同行回答
因为不知道你的truncate是怎么做的，可以试试这个：
1、第一次插入数据后，收集一下表的信息，看表的fpages是多大
2、truncate后，再收集一下表的信息，看表的fpages是多大
3、比较前后的fpages大小
如果没有变化，说明以后新插入是利用第一次分配的空间，理论上是要比第一次快点 收起
1、第一次插入数据后，收集一下表的信息，看表的fpages是多大
2、truncate后，再收集一下表的信息，看表的fpages是多大
3、比较前后的fpages大小
如果没有变化，说明以后新插入是利用第一次分配的空间，理论上是要比第一次快点 收起
兄以上的方法全是基于kettle ？ 如果是 ，能不能在数据库上直接用insert ，看看时间如何。 kettle原理应该是jdbc 的batch 提交 。先隔离jdbc的问题，看看数据库层面是啥情况 收起
我也觉得是data cache, DB2 自己的buffer pool会在你执行查询后缓存结果集,在你下次查询的时候就会直接从buffer pool里读数据,这样快很多. 你可以再执行一个大数据量的查询把buffer pool清空,然后应该就会跟第一次一样要20分钟了 收起