互联网服务 数据库
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 同行回答
兄以上的方法全是基于kettle ？ 如果是 ，能不能在数据库上直接用insert ，看看时间如何。 kettle原理应该是jdbc 的batch 提交 。先隔离jdbc的问题，看看数据库层面是啥情况 收起
INSERT 处理过程概述
首先让我们快速地看看插入一行时的处理步骤。这些步骤中的每一步都有优化的潜力，对此我们在后面会一一讨论。
1. 在客户机准备 语句。对于动态 SQL，在语句执行前就要做这一步，此处的性能是很重要的；对于静态 SQL，这一步的性能实际上关系不大，因为语句的准备是事先完成的。
2. 在客户机，将要插入的行的各个 列值组装起来，发送到 DB2 服务器。
3. DB2 服务器确定将这一行插入到哪一页中。
4. DB2 在 用于该页的缓冲池中预留一个位置。如果 DB2 选定的是一个已有的页，那么就需要读磁盘；如果使用一个新页，则要在表空间（如果是 SMS，也就是系统管理存储的表空间）中为该页物理地分配空间。插入了新行的每一页最后都要从缓冲池写入到磁盘。
5. 在目标页中对该行进行格式化，并获得该行上的一个 X（exclusive，独占的） 行锁。
6. 将反映该 insert 的一条 记录写入到日志缓冲区中。
7. 最后 提交包含该 insert 的事务，如果这时日志缓冲区中的记录还没有被写入日志文件的话，则将这些记录写到日志文件中。
这个是insert的操作过程，估计第四步的原因 收起
首先让我们快速地看看插入一行时的处理步骤。这些步骤中的每一步都有优化的潜力，对此我们在后面会一一讨论。
1. 在客户机准备 语句。对于动态 SQL，在语句执行前就要做这一步，此处的性能是很重要的；对于静态 SQL，这一步的性能实际上关系不大，因为语句的准备是事先完成的。
2. 在客户机，将要插入的行的各个 列值组装起来，发送到 DB2 服务器。
3. DB2 服务器确定将这一行插入到哪一页中。
4. DB2 在 用于该页的缓冲池中预留一个位置。如果 DB2 选定的是一个已有的页，那么就需要读磁盘；如果使用一个新页，则要在表空间（如果是 SMS，也就是系统管理存储的表空间）中为该页物理地分配空间。插入了新行的每一页最后都要从缓冲池写入到磁盘。
5. 在目标页中对该行进行格式化，并获得该行上的一个 X（exclusive，独占的） 行锁。
6. 将反映该 insert 的一条 记录写入到日志缓冲区中。
7. 最后 提交包含该 insert 的事务，如果这时日志缓冲区中的记录还没有被写入日志文件的话，则将这些记录写到日志文件中。
这个是insert的操作过程，估计第四步的原因 收起