记一次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去掉后，测试环境逻辑读降为两千多。
解决方案
如果要绑定sqlprofile,这一类语句太多了，即使绑定也一定都适用此类语句。
可以考虑将此类语句从SQL集中去掉，但去掉的话就无法验证是否是这一批语句引起的问题。
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