fengwhq

21年压测过性能不太理想，近两年不知道是否有优化

针对openguas的评价1.性能比较业内国产集中式数据库相对较好2. 商业版厂商较多，合作伙伴较多，社区资源丰富3. 一主多备模式切换存在一定BUG4. 相比较国外产品，对于自动调优工具如sql tune、db2advis等不支持，大量的复

看看日志吧 估计回滚呢 就算强行 db2_kill了 ，db2start也会超级慢 ，基本就一个办法 等

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

回复 zhenda 生产环境的，不方便改，机器剩余内存还有不少。 该sql用db2advis看了下，没建议索引了，这个表上只有一个3楼发的主键索引。您的意思是在B库执行的时候使用的索引而在A没使用索引是吧？ 刚才做了下测试

回复 zhenda 2台机器物理配置一样的，缓冲池参数SRM_XSM_CUST_ITEM_LMT表所在表空间使用的缓冲池大小为480M，EC_CUST_CGT_LMT_TEST 表所在表空间使用的缓冲池大小为240M，B库中EC_CUST_CGT_LMT_TEST 表是我参考生产表创

回复 mdkii 恩，好像主要还是一条一条insert导致的，主要这个程序不是脚本写的，如果是脚本就好弄了。这个东西是B/S架构程序里的一个按钮，数据源连接的A库，有没有办法可以优化下联合体呢，现有架构下能进行优化吗？这个问题实

topas观察了一下，执行的时候网卡的IO流量都在3000左右，执行完马上就降下来，基本时间都消耗在两台机器通信上了，两台机器做的HA，互相ping 0ms，求解

回复 mdkii 确实是一条一条执行的。 我用这个看了一下select num_executions,stmt_text from sysibmadm.snapdyn_sql order by 1 desc; 该insert语句执行了459W次 如果将EC_CUST_CGT_LMT_TEST表放到A库的话，B库

回复 mdkii 实际的插入数据为440W+ 另外做了下测试，把EC_CUST_CGT_LMT_TEST表建在A库测试，不到1分钟就执行完了；把A库SRM_XSM_CUST_ITEM_LMT数据export出来再import到B库里需要大概2-3分钟。会不会是联合体导致的问