联合体insert性能疑问

从RMTQTXT可以看出insert在被一条一条的插入，这个光从联邦上优化可能有点难，可能是由于实现上A库无法直接远程在B库上构造insert XXX select from XXX语句，只能构造单条的insert语句，这个把它理解成普通的APP插入应该可以理解这一点。我记得联邦可以联邦存储过程的，考虑在A库上做个存储过程给B库，然后直接调用存储过程让其在B库上执行吧收起

回复 7# fengwhq

从昨天的信息看，io和buffer应该不是主要问题，从这个两个执行计划对比在A机执行的网络开销是在B机上的20倍，不管是在A机还是在B机操作，在插入时每次只插入一条，要执行400多万次，差别可能是在B机取数方式不同。例如：A机上执行每次插入一次数据，A机会发送一条到B机，下一次插入再发送一条。若在B机上执行，B机执行会一次得到A机的返回结果，插入时无需等待，直接将返回的数据一条一条的插入。
若上述成立的话，在执行是观察一下网络开销，对比这两次执行的网络，执行时会变成高峰，A机执行时，相对高峰时间长，但吞吐量低，B机上执行网络高峰时间相对短，但吞吐量高。

另，两个机器的参数都一样吧， Max requester I/O block size (bytes)         (RQRIOBLK) = 32767
A机器：
  
1) RETURN: (Return Result)
Cumulative Total Cost:
5.49846e+06

Cumulative CPU Cost:
1.78834e+10
Cumulative I/O Cost:
370355
Cumulative Re-Total Cost:
5.45341e+06
Cumulative Re-CPU Cost:
1.73407e+10
Cumulative Re-I/O Cost:
217907
Cumulative First Row Cost:
5.49846e+06
Estimated Bufferpool Buffers:
370355
Remote Total Cost:
6.144e+06
Remote Communication Cost:
4.096e+06
B机器：

1) RETURN: (Return Result)
Cumulative Total Cost:
523112
Cumulative CPU Cost:
1.61669e+09
Cumulative I/O Cost:
36576.1
Cumulative Re-Total Cost:
205678
Cumulative Re-CPU Cost:
1.41277e+09
Cumulative Re-I/O Cost:
15968
Cumulative First Row Cost:
523112
Estimated Bufferpool Buffers:
36577.1
Remote Total Cost:
242703
Remote Communication Cost:
242699收起

回复 18# zhenda


   测试都是在生产环境做的。    刚重新执行了下SQL，用DB2TOP看了下执行过程中缓冲池的命中率，A库SRM_XSM_CUST_ITEM_LMT表所在缓冲池命中率稳定70%左右，B库EC_CUST_CGT_LMT_TEST 表坐在缓冲池命中率稳定在92%左右，截图如下，该截图为DB2TOP看的实时命中率。


    B库的快照我再想办法弄一下吧，我也一直想看下B库dynamic sql的快照，但是一直报私有内存不足。收起

memory(kbytes)       32768

这个值不大啊，这个用户最大使用内存很小啊。

索引问题是额外话题，db2很智能，没有推荐就不用建啦。

言归正传，另一个快照没有贴出不好直接判断。你还没有贴出这两表对应bufferpool的命中率啊，这个很重要。这个建表测试是在生产环境做的？收起

回复 16# zhenda

      生产环境的，不方便改，机器剩余内存还有不少。      该sql用db2advis看了下，没建议索引了，这个表上只有一个3楼发的主键索引。您的意思是在B库执行的时候使用的索引而在A没使用索引是吧？
       刚才做了下测试，将B库EC_CUST_CGT_LMT_TEST 表建立在A库名为EC_CUST_CGT_LMT_TEST1，这样两个表都在A库，执行该SQL，看访问计划显示依旧没使用索引，但是1分钟就执行完了，是否可以表示不是表扫描导致的性能问题呢，另外把测试的访问计划再贴一下。收起

回复 14# fengwhq


   若果是测试环境可以调整一下，topas看一下服务器现有内存和剩余内存。还有当前bufferpool的命中率。
服务器参数还是有差别的：
Tablespace overhead:
12.670000
Tablespace transfer rate:
0.180000


Tablespace overhead:
7.500000
Tablespace transfer rate:
0.060000收起

回复 3# fengwhq


   在这条SQL中没有用到这个索引啊，执行所以IO成本比较高啊，若很重要，经常使用，且这个表的读/写的比例较大，可以再建一个索引。效果应该比较明显，可以测试一下下。收起

回复 12# zhenda


   2台机器物理配置一样的，缓冲池参数SRM_XSM_CUST_ITEM_LMT表所在表空间使用的缓冲池大小为480M，EC_CUST_CGT_LMT_TEST 表所在表空间使用的缓冲池大小为240M，B库中EC_CUST_CGT_LMT_TEST 表是我参考生产表创建的测试表，插入的时候该表是空表，该表没runstats，但是生产表runstats了，是否runstats测试好像没什么影响。

   另外SQL快照，A机器如下：
Number of executions               = 1
Number of compilations             = 1
Worst preparation time (ms)        = 3
Best preparation time (ms)         = 3
Internal rows deleted              = 0
Internal rows inserted             = 0
Rows read                          = 6308346
Internal rows updated              = 0
Rows written                       = 0
Statement sorts                    = 0
Statement sort overflows           = 0
Total sort time                    = 0
Buffer pool data logical reads     = 156042
Buffer pool data physical reads    = 10
Buffer pool temporary data logical reads   = 0
Buffer pool temporary data physical reads  = 0
Buffer pool index logical reads    = 0
Buffer pool index physical reads   = 0
Buffer pool temporary index logical reads  = 0
Buffer pool temporary index physical reads = 0
Buffer pool xda logical reads      = 0
Buffer pool xda physical reads     = 0
Buffer pool temporary xda logical reads    = 0
Buffer pool temporary xda physical reads   = 0
Total execution time (sec.microsec)= 1041.804537
Total user cpu time (sec.microsec) = 82.227238
Total system cpu time (sec.microsec)= 59.639625
Total statistic fabrication time (milliseconds) = 0
Total synchronous runstats time  (milliseconds) = 0
Statement text                     = insert INTO EC_CUST_CGT_LMT_TEST (ORG_CODE,CUST_CODE,CGT_CODE,QTY_LMT,NOTE,UP_TIME)    SELECT COM_ID,CUST_ID,ITEM_ID,LMT_QTY,NOTE,'2014-02-11 16:35:02'      FROM SRM_XSM_CUST_ITEM_LMT      WHERE COM_ID='11230101'



B机器抓快照报私有内存不足，还没找到怎么解决，报错及db2diag.log如下，麻烦看下是什么原因呢？
$ db2 get snapshot for dynamic sql on xsmec
SQL0083C  A memory allocation error has occurred.



2014-02-20-15.44.03.185970+480 E331230024A1156    LEVEL: Error (OS)
PID     : 1016682              TID  : 1           PROC : db2bp
INSTANCE: db2inst3             NODE : 000
EDUID   : 1
FUNCTION: DB2 UDB, SQO Memory Management, sqloLogMemoryCondition, probe:100
CALLED  : OS, -, malloc
OSERR   : ENOMEM (12) "There is not enough memory available now."
MESSAGE : Private memory and/or virtual address space exhausted, or data ulimit
          exceeded
DATA #1 : Soft data resource limit, PD_TYPE_RLIM_DATA_CUR, 8 bytes
134217728
DATA #2 : Requested size, PD_TYPE_MEM_REQUESTED_SIZE, 8 bytes
269815808
DATA #3 : Current set size, PD_TYPE_SET_SIZE, 8 bytes
90963968
CALLSTCK:
  [0] 0x090000000051DD50 sqloLogMemoryCondition + 0x274
  [1] 0x090000000051DA24 sqloLogMemoryCondition@glue30B + 0x78
  [2] 0x090000000062479C sqlogmblkEx + 0x11C
  [3] 0x0900000000BEA954 sqloMemBlockReallocate + 0x100
  [4] 0x00000001000F0834 clpbp_exe_sqlmonss__Fv + 0x394
  [5] 0x00000001000015F0 clp_bp_con__Fv + 0x630
  [6] 0x0000000100000A78 main + 0x1F8
  [7] 0x0000000100000320 __start + 0x98
  [8] 0x0000000000000000 ?unknown + 0x0
  [9] 0x0000000000000000 ?unknown + 0x0

2014-02-20-15.44.03.187008+480 E331231181A561     LEVEL: Warning
PID     : 1016682              TID  : 1           PROC : db2bp
INSTANCE: db2inst3             NODE : 000
EDUID   : 1
FUNCTION: DB2 UDB, SQO Memory Management, sqloMemLogPoolConditions, probe:30
DATA #1 :
Out of memory failure for Private Heap.
Requested block size           : 269774247 bytes.
Physical heap size             : 90505216 bytes.
Configured heap size           : 1099511627776 bytes.
Unreserved memory used by heap : 0 bytes.
Unreserved memory left in set  : 0 bytes.




$ ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         131072
stack(kbytes)        32768
memory(kbytes)       32768
coredump(blocks)     2097151
nofiles(descriptors) 2000


是否需要增大data的limits?收起

若有新的变化记得回帖哦，关注中。收起

从执行计划看你的A机器配置要比B机器的配置高吧，，还有在B机器上没有做过runstats吧。

请贴出这条SQL语句分别在A机器和B机器的SQL快照，还有这两个机器上的表所对应的buffepool的信息。

从给出的信息看，A机器的bufferpoll配置较高，命中率应该比较高，这条SQL占用的bufferpool为6.64%。B机器这条SQL占用bufferpool为14.54%左右。
根据后续反馈的信息，进行比较。收起