oracle 升级到11204,升级到11204遇到的性能问题

有一套系统从11201升级到11204,升级后发现业务SQL变慢,CPU使用率高了很多:

升级前(11201版本):

407476967ae08d6786cd601be8c5c1fc.png

升级后(11204版本):

4da905db8f064eb6bc59c8add75f9806.png

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

2404a65ebea6a0fdd3272ce9dbbedad9.png

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

f44f075deeddd1e8186af86e28eef023.png

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

3595eed1747479064b43010e54a2b927.png

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

0fb9516bf3c15c1eb1caf12d026cabc7.png

差的执行计划表现在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打上;升级前做足测试,提早发现提早解决.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值