sql 使CPU使用100%，棘手！

askgyliu

多 和 少 时 相 对 而 言 的 。

可 以 把 我 在 回 贴 53 所 要 的 结 果 放 上 来 吗 ？

myfriend2010

可以啊!但是由于数据量很大,估计的下班没有人用数据库的时候才可以做!

askgyliu 是好心人啊!

这样吧这边有我和狼的最新的分析结果!

你可以看看!如果能看出什么问题来,我就按照你53楼的方法!

myfriend2010

exfmt.txt为9月份的表做的sql,执行正常,也就是不会报CPU使用100%
exfmt1.txt为10月份的表做的sql,执行不正常,也就是会报CPU使用100%
exfmt2.txt为10月份的表做的sql,但是把临时表session.V_PRE_EXP_GROUP_CUST1换成fact表,执行正常,也就是不会报CPU使用100%

myfriend2010

askgyliu帮忙看看这个sql,如果有必要我把系统数据库的support分析结果也发上来!

myfriend2010

to: wangzhonnew,这边版本是8.1,在存储过程中每发对临时表进行分析!所以我感觉就算是临时表统计信息有问题,我这边也没法解决啊!

askgyliu

这最近的三个SQL跟最开始的两个SQL是不相同的？

这里面还有INSERT的问题？

我只能给些建议：

0) 只有人类才会觉得两个SQL很相似，会去比较。对DB2来说，一个小小的改变，对DB2来说就是完全不相同的SQL，而ACCESS PLAN可能会完全不相同。

1) 看看机子上有多少个CPU？有4个NODES，还有INTRA-PARTITION PARALLELISM，那起码得要有8个CPU。如果DB2给了个很RESOURCE-INTENSIVE但OPTIMIZED的路径，但机子RESOURCE跟不上，那怎么办？巧妇难为无米之炊。等待的时间是会成指数增加的，而不是线性的。

2) INSERT TEMP TABLE还有另外的考虑。比如说TEMP一般是SMS TABLESPACE，对大量的数据INSERT并不好。所以你的PERFORMANCE可能就是因为INSERT太慢了而导致的。如果你把TEMP TABLE全换成普通的TABLE，PERFORMANCE突然好了，那很大可能就是SMS跟DMS的区别了。我遇到过这种情况，就是TARGETED TABLE从SMS换成DMS，整个INSERT用SMS本来两个多钟头没结果，用DMS不到五分钟就好了。

3) 尽可能别写太复杂的SQL。几个简单的SQL往往会比一个复杂的SQL执行得快，也比较容易OPTIMIZE。越复杂的SQL就会有越多可能的ACCESS PATH，就越可能有莫名其妙的PERFORMANCE UNCERTAINTY。

askgyliu

再有一点非常非典型的个人想法。若是SQL有PERFORMANCE问题，而CPU/DISK IO又很低的话，可能就是很棘手了。

myfriend2010

to:askgyliu
Q:这最近的三个SQL跟最开始的两个SQL是不相同的？

A:是啊,我把10月份的表重新生成并分析后,就这个样子了!这是最新的执行计划,以前的执行计划无法得到了!

Q:这里面还有INSERT的问题？

A:恩,63楼已经说的很详细了!

Q:看看机子上有多少个CPU？有4个NODES，还有INTRA-PARTITION PARALLELISM，那起码得要有8个CPU。如果DB2给了个很RESOURCE-INTENSIVE但OPTIMIZED的路径，但机子RESOURCE跟不上，那怎么办？巧妇难为无米之炊。等待的时间是会成指数增加的，而不是线性的。

A: CPU 4*2 ,内存16G

Q: INSERT TEMP TABLE还有另外的考虑。比如说TEMP一般是SMS TABLESPACE，对大量的数据INSERT并不好。所以你的PERFORMANCE可能就是因为INSERT太慢了而导致的。如果你把TEMP TABLE全换成普通的TABLE，PERFORMANCE突然好了，那很大可能就是SMS跟DMS的区别了。我遇到过这种情况，就是TARGETED TABLE从SMS换成DMS，整个INSERT用SMS本来两个多钟头没结果，用DMS不到五分钟就好了。

A: 这边无论临时表还是fact表都是SMS的!呵呵

wangzhonnew

原帖由 myfriend2010 于 2007-12-12 10:46 发表
to: wangzhonnew,这边版本是8.1,在存储过程中每发对临时表进行分析!所以我感觉就算是临时表统计信息有问题,我这边也没法解决啊!

1) add index to cust_id
2) runstats to the temp table

wangzhonnew

and i didn't see you pasted select count(*) result from temp table, please do it and we'll see if the statistics is really off from the real number of rows...