不知不觉,技术人生系列·我和数据中心的故事来到了第五期,小y又和大家见面了!
前几期主要发了一些故障排除的案例分享,其实小y最擅长的是性能优化,所以从这期开始,小y会陆续的分享更多的数据库性能优化案例。
进入正题,如果您的日终跑批清算报表等程序时快时慢,或者从某一天以后就一直变慢,作为运维或开发的您,会怎么下手?
小今天要和大家分享的就是这样一个性能问题的分析和解决过程。
你们的点赞和转发就是小继续坚持分享的动力。
另外,前阵子有部分朋友问,小y所在的团队是否可以提供对外的第三方甲骨文服务,答案是是的!
有兴趣的朋友可以加一下小y的个人微信,微信号是shadow-huang-bj,希望可以交到更多的朋友,并帮助到更多有需要的人。
<强>
小y,有空么?一会一起看一个报表的性能问题。
,有个SQL语句一周前开始,性能急剧恶化,执行时间从10分钟以内变成了10个小时以上。
刚在客户现场做完甲骨文的培训,问题来的正是时候,刚好可以让客户感受下理论如何融入实战的魅力!小y的第一想法是SQL语句的执行计划发生了改变,通常从统计信息或者国会预算办公室对基数的估算情况中就可以快速找到线索,应该很快就可以查明原因并解决!
最后的事实证明,小y一开始想简单了。针对这个问题,客户通过并且重新收集统计信息或重启数据库均无法解决问题。幸运的是,小y及时调整回到了学院派模式,最终在一个小时内找到了问题的原因,问题的解决也就是顺其自然了。
环境介绍:
操作系统Redhat 64位
数据库,,Oracle 11.2.0.3, 2节点RAC
<强>
2.1完整的SQL语句
<强>小y对这条SQL进行了敏感信息处理和写法的简化处理,可以看到:
,,该SQL对两张表张进行加入,然后group by
,,参与关联的两张表一张是80米的小表,另外一张是3.5 g的较大一些的表。记录数分别万是160年和800年万
, SQL语句用了提示,提示优化器表连接走散列连接,单表访问路径小表走全表扫描。
这样的一条SQL,按照小y的经验,驱动表只要选择小表,那么整个散列连接的执行时间基本等同于两张表的单表访问时间,两张表加起来不到4 g,通常都可以在5分钟内完成。这和客户描述的以前的执行时间是相吻合的。
这里顺便说一下:
很多开发写往往写的不完整,例如这个只写了表连接方式,单表访问路径只写了一张表,表的连接顺序没有写,其实并没有完全固定死执行计划。
接下来,小y将查看执行计划是否发生变化,还有执行计划是否正确。
2.2执行计划
可以看到:
,执行计划(oracle内部的算法)确实如提示一样
,表连接方式走的是散列连接
,单表访问路径都是全表扫描(表访问完整)
,表连接顺序是小表做驱动表(散列内存表)
2.3 SQL执行的相关统计
<强>可以看到:
1,,每次执行时间39615秒,超过10个小时
2,,每次执行逻辑读只有45276个块(块)
3,,每次执行物理读451421个块(块)
4,,时间基本都消耗在CPU上,达到38719秒,超过10个小时,而在IO/集群/应用(锁)/并发环节消耗时间很小
