其他分享
首页 > 其他分享> > 记一次SPA回放缓慢分析

记一次SPA回放缓慢分析

作者:互联网


现象


最近在做一套核心库的的spa回放,共分为3个任务来跑,其中任务1,2跑起来较慢,预估时间要20多少小时。实际跑下来将近24个小时。按照以往经验,这点sql最多几个小时就该跑完的,所以,老司机的撸感告诉自己,应该是出问题了。再次核查统计信息,索引等信息,发现都正常。这说明数据准备这块确实没问题,看来问题应该出现在sql上。只能等spa报告跑出来分析报告了。




分析


主要分析了任务1,2跑出的buffer_gets报告,下面这条语句引起了我的注意。


图片


==>时间上比生产的平均值要高,达到了20s。逻辑读上生产的平均值是一百多万,测试环境中更是达到了两百多万,但返回的行数却很少。很显然这条语句在生产上性能本就存在问题,但可能因调用量少,问题没有凸显出来。



图片

==》这类语句在spa任务1,2中的sql集中存在较多,分别为五千多,六千多。按每个语句20s执行,这类语句执行消耗的时间可估算总和到几十个小时。


图片


==》把这条语句单独拿出来进行优化,重新收集统计信息,新建索引等方法,执行计划达不到想要的结果,逻辑读依然达到了两百多万。

图片


==》最后只能改写这条语句了,注意到这里使用了hint关键字/*+ORDERED */,该ORDERED提示使Oracle按照表在FROM子句中出现的顺序联接表。怀疑是该hint导致执行计划无法最优。手工把该hint去掉后,测试环境逻辑读降为两千多。




解决方案


  1. 如果要绑定sqlprofile,这一类语句太多了,即使绑定也一定都适用此类语句。


  2. 可以考虑将此类语句从SQL集中去掉,但去掉的话就无法验证是否是这一批语句引起的问题。


  3. 19c环境我们可以使用OPTIMIZER_IGNORE_HINTS参数来忽略sql语句中使用的hint。默认为false,我们在system级别调成true,再跑下spa任务。


图片




优化效果


图片

图片


==》重新跑spa任务后,系统估算任务1,2在2个小时内能跑完,实际跑下来也确认如此,速度提升了近10倍。

图片

==》最新跑出的报告,该语句对比性能提升显著,执行时间在0.02s左右,逻辑读三千左右。




总结


SPA任务跑的慢,说明语句可能存在问题。那么本次的原因是因业务语句使用hint导致,根本上解决此问题还需要和业务侧沟通整改。另外补充下,OPTIMIZER_IGNORE_HINTS参数对现有绑定sqlprofile的语句不影响,这里不再详细阐述。



标签:语句,回放,hint,sql,问题,任务,缓慢,spa,SPA
来源: https://blog.51cto.com/u_15127668/2802606