DMS表空间数据插入效率

回复 10# drdb2


   在哪里做了data cacheing啊。db2的话，我重启数据库，速度还是一样啊。 收起

回复 5# xxzmxx

这就说明是data caching
your source data have been cached after first run 收起

INSERT 处理过程概述

首先让我们快速地看看插入一行时的处理步骤。这些步骤中的每一步都有优化的潜力，对此我们在后面会一一讨论。

   1. 在客户机准备 语句。对于动态 SQL，在语句执行前就要做这一步，此处的性能是很重要的；对于静态 SQL，这一步的性能实际上关系不大，因为语句的准备是事先完成的。
   2. 在客户机，将要插入的行的各个 列值组装起来，发送到 DB2 服务器。
   3. DB2 服务器确定将这一行插入到哪一页中。
   4. DB2 在 用于该页的缓冲池中预留一个位置。如果 DB2 选定的是一个已有的页，那么就需要读磁盘；如果使用一个新页，则要在表空间（如果是 SMS，也就是系统管理存储的表空间）中为该页物理地分配空间。插入了新行的每一页最后都要从缓冲池写入到磁盘。
   5. 在目标页中对该行进行格式化，并获得该行上的一个 X（exclusive，独占的） 行锁。
   6. 将反映该 insert 的一条 记录写入到日志缓冲区中。
   7. 最后 提交包含该 insert 的事务，如果这时日志缓冲区中的记录还没有被写入日志文件的话，则将这些记录写到日志文件中。


这个是insert的操作过程，估计第四步的原因 收起

回复 3# wp28556259


   可能和表空间没关系啊？我重复做多次，都是和第二次结果意义，保持在8min左右。
   只有第一次最慢，并且是2倍左右的差距:funk: 收起

不过V9.5好像没有truncate操作啊。

不知道kettle（etl工具）是如何实现truncate的，速度很快。 收起

回复 3# wp28556259


   我的表空间不是自动Reize的啊
并且时NO FILE SYSTEM CACHING 收起

回复 4# drdb2


   第三次的结果和第二次一样啊。在8min左右 收起

I tend to think something to do with data caching.

what about 第三次？ 收起

表空间是AUTORESIZE吗？你TRUNCATE后，ALTER  TBSPACE REDUCE MAX，然后再插入，看看速度是不是和第一次建表后插入时间一样。会不会是在数据库向操作系统申请空间的时候花费了时间 收起

本次操作的背景，是ETL的一个过程，从源表抽取数据到目标表

第一次很慢，而第二次做同样操作就非常快。

数据库重启之类的我都试过，结果一样。排除数据库端和应用端缓存 收起