沈阳凯文数据恢复中心 服务器数据恢复 各类数据库修复 小型机数据恢复 13386848847 024-31065488 地址:沈阳市和平区三好街同方广场A座10楼1012写字间

存储过程执行突然执行缓慢,问题解决思路

 <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这样优化器将考虑使用索引扫描而不是表扫描。无论统计信息如何,优化器将使用索引扫描而不是使用表扫描