统计信息问题造成的执行计划糟糕的一个例子(找原因)

昨天的报表数据库中有一条SQL,执行计划很差 ,Full table scan ,索引以及全部统计信息完整。
SELECT × FROM wPay201004 WHERE org_code='01013340C' AND op_code not in ('1330');
用户很着急,试着采取了几个方法 :
1.删除统计信息,重新收集
2.对索引进行重建。
结果还是不通过索引来进行查询。强行在SQL语句中加上hint提示(/*+ index(wpay201004 wpay201004_idx2) */),执行计划可以了,可这就要改程序,已经来不及,只能想别的方法。
这是一张月份表,同样对比前一个月的查询,3月的执行计划通过走了索引而四月却是全表扫描,效率差了一大截。仔细查看,表、索引结构相同,唯一的差别就是统计信息数值不一样。我跟用户说换个思路,把3月表的统计信息复制到4月,通过这种方法改变执行计划,得到用户的肯定我开始进行操作。
建stata表
execute DBMS_STATS.CREATE_STAT_TABLE(ownname=>'owner',stattab=>'stat_tab',tblspace=>'ts_name');
导出表wpay201003分析数据:
execute DBMS_STATS.export_table_stats(ownname=>'owner',tabname=>'wpay201003',stattab=>'stat_tab');
删除表wpay201004的分析数据:
execute dbms_stats.delete_table_stats(ownname=>'owner',tabname=>'wpay201004');
修改统计信息
对stat_tab统计信息做休息,让数据复合wpay201004使用。
导入分析数据
execute DBMS_STATS.IMPORT_TABLE_STATS(ownname=>'owner',tabname=>'wpay201004',stattab=>'stat_tab');
完成,测试结果完全按照预想,执行计划走了索引。执行时间从50多秒缩短到4秒左右。

什么原因呢?
我怀疑是作者在收集统计信息的时候,使用了块采样,造成了错误的统计信息,应该进行全扫描的方式进行统计信息的收集(细细的研究dbms_stats包里面的一些具体的细节)。
标签: 暂无标签
oraunix

写了 199 篇文章,拥有财富 1026,被 339 人关注

转播转播 分享分享 分享淘帖
回复

使用道具

P3 | 发表于 2013-3-18 15:08:27
这样的思路初学者确实很难想到
回复

使用道具

P5 | 发表于 2013-3-19 15:59:26
学习学习
回复

使用道具

P4 | 发表于 2013-4-14 11:09:15
"对stat_tab统计信息做休息,让数据复合wpay201004使用。" 请问大师,这句话是什么意思?

另外这个导出导入的方式,和 DBMS_STATS.copy_table_stats 有什么不同?
回复

使用道具

您需要登录后才可以回帖 登录 | 加入社区

本版积分规则

意见
反馈