最近,遇到一客户,反馈业务响应慢,经过分析后最后锁定到平时执行不到1秒的SQL语句,今天突然执行时间变成
半分钟。处理过程如下:
取问题时段的AWR,查看数据库负载,发现数据库负载不高:
查看数据库顶级等待事件,发现是文件离散读,基本可以锁定是表扫描相关的问题:
查看问题SQL,Order by Elapsed Time,发现一条执执行次数不算多,执行耗时特别长的SQL:
如图SQL ordered by Elanpsed Time所示, 接下来分析数据库awr的TOP SQL消耗时间最多的SQL 是fbh8jvk9fvdkh,平均执
行时长239.54s,经与甲方人员核实是监控到的慢业务SQL语句。
将问题SQL改造,方便性能测试,改造后的语句如下(sql_tun110是为了方便找SQL_ID):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
获取上述SQL的执行计划:
如图上所示,问题SQL执行计划显示其Cost值只有61,但是consistent gets有5274937之多,可以确认是sql语句的
执行计划出现问题导致sql性能下降。经过与甲方人员沟通,得知上午对datacenter以analyse table的方式进行过统
计信息收集,经进一步查询最近只有2018年6月13日执行过统计信息收集如下图所示。
因此得出结论: 由于datacenter数据库统计信息不准确,使得数据库SQL优化器参考的统计信息不准确,导致数据库优化器产生了性能极差的执行计划,sql执行耗时较长,影响业务响应速度 。
重新更新表的统计信息:
1 2 |
|
验证效果,原先SQL的逻辑读5274937降低到6290,SQL原先执行30多秒,现在执行耗时0.6秒:
优化前的执行对比: