存储过程执行突然执行缓慢，问题解决思路
<hr class="more" />
存储过程执行突然执行缓慢，问题解决思路?
对于以往执行正常，当前执行缓慢的情况，思路如下：
将存储过程中的语句进行拆分，逐条执行动态SQL，观察执行时间
如果很快，1、需要先了解最近是否有大量新数据导入；2、是否新建索引
获取当前存储过程执行计划A
检查最近是否正常runstats
如果异常先将该存储过程所涉及的所有表runstats
执行存储过程
如果还是缓慢，rebind package重新绑定该存储过程所涉及的包
获取rebind后的存储过程的执行计划B
最后，对比 执行计划A 与 执行计划B
--获得存储过程的包名
1、先指定存储过程名 rpt.aa10001
2、获取 pkgname
select b.*,c.PROCSCHEMA,c.PROCNAME from
syscat.STATEMENTS b, syscat.PROCEDURES c,syscat.ROUTINEDEP d
where b.pkgname=d.bname
and c.SPECIFICNAME=d.SPECIFICNAME
and c.PROCSCHEMA=d.ROUTINESCHEMA
and 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
这样优化器将考虑使用索引扫描而不是表扫描。无论统计信息如何，优化器将使用索引扫描而不是使用表扫描