<hr class="more" />存储过程执行突然执行缓慢，问题解决思路?对于以往执行正常，当前执行缓慢的情况，思路如下：将存储过程中的语句进行拆分，逐条执行动态SQL，观察执行时间如果很快，1、需要先了解最近是否有大量新数据导入；2、是否新建索引获取当前存储过程执行计划A检查最近是否正常runstats如果异常先将该存储过程所涉及的所有表runstats执行存储过程如果还是缓慢，rebind package重新绑定该存储过程所涉及的包获取rebind后的存储过程的执行计划B最后，对比 执行计划A 与 执行计划B--获得存储过程的包名1、先指定存储过程名 rpt.aa100012、获取 pkgnameselect b.*,c.PROCSCHEMA,c.PROCNAME fromsyscat.STATEMENTS b, syscat.PROCEDURES c,syscat.ROUTINEDEP dwhere b.pkgname=d.bnameand c.SPECIFICNAME=d.SPECIFICNAMEand c.PROCSCHEMA=d.ROUTINESCHEMAand c.PROCSCHEMA='FLT' and c.PROCNAME='FLIGHTDATA' --指定存储过程名PS：runstats仅是更新执行计划的一方面（对于动态SQL生效，但对于存储过程无效）；另一方面还需rebind包（对于更新存储过程执行计划方才有效）--重新绑定包，rebind包db2 rebind package rpt.P621357动态SQL立即生效，更新package cache中的执行计划flush package cache dynamic对全库package重新绑定db2rbind dbname -l dbrbind.log all当你在分区(DPF)数据库里面使用了REDISTRIBUTE DATABASE PARTITION GROUP这个命令，那么就需要用runstats来收集新的统计信息db2 runstats on table odr.order with distribution and detailed indexes all如果我们要处理的表数据量是快速变化的，比如在电信移动行业，需要在月末进行处理的汇总表。在不长的时间范围内数据量变化特别大，从而使得RUNSTATS 得到的统计信息不准确，原因是这些统计信息只是某个时间点的信息。您可以用这条语句来把表修改为volatile alter table table_name volatile cardinality这样优化器将考虑使用索引扫描而不是表扫描。无论统计信息如何，优化器将使用索引扫描而不是使用表扫描