oracle 升级到11204,升级到11204遇到的性能问题
有一套系统从11201升级到11204,升级后发现业务SQL变慢,CPU使用率高了很多:升级前(11201版本): 升级后(11204版本): 通过AWR 和oratop 工具发现出问题的是一些类似的sql,性能下降上千倍,sqlhc信息如下: sql核心部分代码(上面还有很长): 升级前好的执行计划(部分): 升级后差的执行计划(部分): 差的执行计划表现在rr表独自做了group by然后与其
有一套系统从11201升级到11204,升级后发现业务SQL变慢,CPU使用率高了很多:
升级前(11201版本):

升级后(11204版本):

通过AWR 和oratop 工具发现出问题的是一些类似的sql,性能下降上千倍,sqlhc信息如下:

sql核心部分代码(上面还有很长):

升级前好的执行计划(部分):

升级后差的执行计划(部分):

差的执行计划表现在rr表独自做了group by然后与其他两表做hash join;而好的执行计划全部是nested loop,最后再做group by.
尝试使用sql profile固定执行计划,不成功;重新收集各表的统计信息,还是不行;
仔细检查执行计划outline data,发现差的执行计划有这个内容:PLACE_GROUP_BY(@"SEL$10" ( "RR"@"SEL$10" ) 12)
检索group by相关参数,发现有_optimizer_group_by_placement隐含参数,将该参数在session级别改成false,执行问题sql,执行计划正常.
到MOS查_optimizer_group_by_placement,在11204 的fixed bug 列表中有这个内容(Doc id : 1562142.1),对应的bug号是13886606. 应该是在11204的某个patch set里面修正了这个bug,这个系统只是升级到了11204,没有把最新的patch打上.
临时解决方法:
alter system set "_optimizer_group_by_placement"=false scope=both;
可以等下次打完最新patch后, 再测试一下,看看这个问题是否真的解决了.
建议:
版本升级,最好把最新patch打上;升级前做足测试,提早发现提早解决.
魔乐社区(Modelers.cn) 是一个中立、公益的人工智能社区,提供人工智能工具、模型、数据的托管、展示与应用协同服务,为人工智能开发及爱好者搭建开放的学习交流平台。社区通过理事会方式运作,由全产业链共同建设、共同运营、共同享有,推动国产AI生态繁荣发展。
更多推荐



所有评论(0)