清算/报表/日终跑批程序之性能优化案例（一）

前言

不知不觉，技术人生系列·我和数据中心的故事来到了第五期。小y又和大家见面了！

前几期主要发了一些TroubleShooting的案例分享，其实小y最擅长的是性能优化，所以从这期开始，小y会陆续的分享更多的数据库性能优化案例。

进入正题，如果您的日终跑批/清算/报表等程序时快时慢，或者从某一天以后就一直变慢，作为运维DBA或开发的您，会怎么下手？还有，除了解决问题外，你要如何解答领导最关心的一个问题，“为什么现在有问题，但是以前没有问题呢”！

小y今天要和大家分享的就是这样一个性能问题的分析和解决过程。

你们的点赞和转发就是小y继续坚持分享的动力。

另外，前阵子有部分朋友问，小y所在的团队是否可以提供对外的第三方Oracle服务，答案是YES！

有兴趣的朋友可以加一下小y的个人微信，微信号是 shadow-huang-bj,希望可以交到更多的朋友，并帮助到更多有需要的人。

Part 1

问题来了

小y,有空么？一会一起看一个报表的性能问题。

 有个SQL语句一周前开始，性能急剧恶化，执行时间从10分钟以内变成了10个小时以上。

刚在客户现场做完Oracle的培训，问题来的正是时候，刚好可以让客户感受下理论如何融入实战的魅力！小y的第一想法是SQL语句的执行计划发生了改变，通常从统计信息或者CBO对cardinality的估算情况中就可以快速找到线索，应该很快就可以查明原因并解决！

最后的事实证明，小y一开始想简单了。针对这个问题，客户通过并且重新收集统计信息或重启数据库均无法解决问题。幸运的是，小y及时调整回到了学院派模式，最终在一个小时内找到了问题的原因，问题的解决也就是顺其自然了。

环境介绍：

操作系统 Redhat 64 bit

数据库   Oracle 11.2.0.3 ,  2节点RAC

Part 2

分析过程

2.1 完整的SQL语句

小y对这条SQL进行了敏感信息处理和写法的简化处理，可以看到：

Ø  该SQL对两张表张进行join，然后group by