关于大数据插入的性能调优
最近碰到一个关于DB2调优的问题，具体程序段如下：
LOAD FROM /dev/null of del replace into A ;
INSERT INTO A(col1,col2,col3,col4)
SELECT B.col1,B.col2,C.col1,C.col2
FROM B,C
WHERE B.KEY_NO=C.KEY_NO
with ur;
其中B表中数据量为3700W，C表中数据量为1900W，B表和C表均建立了KEY_NO相应索引，两表中KEY_NO数据类型一致，A表中也建了部分索引，
B、C表所在表空间的页大小为32K，缓冲池空间足够，日志空间足够。
该语句在非业务时间正常运行时间为40分钟，但是在业务时间运行的话，写入速度很慢，并在数据已插入量达到3000W之后，速度降到100条/s，
db2top 可以看到I/O占用非常小，前台应用连接数据库也不多，但CPU一直很低；查看数据库日志无任何异常。
db2expln 查看程序执行计划，显示两表是通过HSJOIN方式进行全表扫描，并没有使用索引，默认使用散列方式JOIN，不知道是不是因为通过使用该方式读入内存的数据量太大而导致速度变慢。
请问各位大神，有否优化的建议。谢谢！
LOAD FROM /dev/null of del replace into A ;
INSERT INTO A(col1,col2,col3,col4)
SELECT B.col1,B.col2,C.col1,C.col2
FROM B,C
WHERE B.KEY_NO=C.KEY_NO
with ur;
其中B表中数据量为3700W，C表中数据量为1900W，B表和C表均建立了KEY_NO相应索引，两表中KEY_NO数据类型一致，A表中也建了部分索引，
B、C表所在表空间的页大小为32K，缓冲池空间足够，日志空间足够。
该语句在非业务时间正常运行时间为40分钟，但是在业务时间运行的话，写入速度很慢，并在数据已插入量达到3000W之后，速度降到100条/s，
db2top 可以看到I/O占用非常小，前台应用连接数据库也不多，但CPU一直很低；查看数据库日志无任何异常。
db2expln 查看程序执行计划，显示两表是通过HSJOIN方式进行全表扫描，并没有使用索引，默认使用散列方式JOIN，不知道是不是因为通过使用该方式读入内存的数据量太大而导致速度变慢。
请问各位大神，有否优化的建议。谢谢！
21同行回答
个人认为：开始的时候缓冲池中的脏数据较少，插入内容是直接写入的缓冲池，而到了后面，由于缓冲池中的脏页已经很多，因此应该已经触发异步写磁盘动作，所以，后面在执行过程中会同时存在异步写磁盘的动作，由于写内存要比写磁盘快的多，后面可能存在往缓冲池中写数据等待写磁盘的情况，所以写入速度会减慢。而且，对目标表而言，如果包含索引的话，随着插入数据量的增加，索引级次的增加也会减慢数据插入的速度。收起
浏览1231
1、如果是DB2 DPF数据库，看看两张表的分区健是否相同是否合理，会不会有数据偏斜。目标表的分区健是否和B表C表相同，是否会导致数据偏斜。
2、先不建索引，插入完成以后，手动建索引。
3、可以考虑not logged initially，对目标表不做日志。收起
2、先不建索引，插入完成以后，手动建索引。
3、可以考虑not logged initially，对目标表不做日志。收起
浏览1236
浏览1293
你的平台是什么？
你试过这个了吗？
“如果并发不是问题的话，你可以尝试一下先显式的锁住表，然后再插入。
lock table A in excusive mode.
insert into A....................
要确保这两句在一个是事务里。”
如果还不行，
用db2batch 运行你的sql，用db2exfmt收集执行计划，然后把两者的输出发上来看看。收起
你试过这个了吗？
“如果并发不是问题的话，你可以尝试一下先显式的锁住表，然后再插入。
lock table A in excusive mode.
insert into A....................
要确保这两句在一个是事务里。”
如果还不行，
用db2batch 运行你的sql，用db2exfmt收集执行计划，然后把两者的输出发上来看看。收起
浏览1230
今天查看了一些数据库参数，发现临时表空间均是建在默认的缓冲池上，默认 BUFFER POOL 的PAGESIZE为32K，大小为1000页，
临时表空间有两个：一个系统临时表空间TEMPSPACE1(MANAGED BY SYSTEM)和一个用户临时表空间TBS_TEMP(MANAGED BY DATABASE)
且TBS_TEMP的参数设置
Tablespace Page size (bytes) = 32768
Tablespace Extent size (pages) = 32
Tablespace Prefetch size (pages) = 32
Number of containers = 1
之前了解到如果要改善 DB2 执行并行 I/O 和提高使用TEMPSPACE的排序、散列连接（hash join）和其它数据库操作的性能，
临时表空间至少应该在三个不同的磁盘驱动器上拥有三个容器。
怀疑问题原因可能是：
1、默认的缓冲池应该增大空间，或者将临时表空间更改至自定义缓冲池上(PAGESIZE为32K，大小为500000页)
2、临时表空间的containers应该增加到3个，Prefetch size应该设置为Extent size的3倍，这个倍数等于容器的个数，
3、已打开STMM,LOCKLIST参数值为指定值20000，非automatic；LOCKTIMEOUT为60，锁等待时间设置短一些.
请大家查阅分析，分享一下经验，谢谢！收起
临时表空间有两个：一个系统临时表空间TEMPSPACE1(MANAGED BY SYSTEM)和一个用户临时表空间TBS_TEMP(MANAGED BY DATABASE)
且TBS_TEMP的参数设置
Tablespace Page size (bytes) = 32768
Tablespace Extent size (pages) = 32
Tablespace Prefetch size (pages) = 32
Number of containers = 1
之前了解到如果要改善 DB2 执行并行 I/O 和提高使用TEMPSPACE的排序、散列连接（hash join）和其它数据库操作的性能，
临时表空间至少应该在三个不同的磁盘驱动器上拥有三个容器。
怀疑问题原因可能是：
1、默认的缓冲池应该增大空间，或者将临时表空间更改至自定义缓冲池上(PAGESIZE为32K，大小为500000页)
2、临时表空间的containers应该增加到3个，Prefetch size应该设置为Extent size的3倍，这个倍数等于容器的个数，
3、已打开STMM,LOCKLIST参数值为指定值20000，非automatic；LOCKTIMEOUT为60，锁等待时间设置短一些.
请大家查阅分析，分享一下经验，谢谢！收起
浏览1285