迄今见到最长的SQL...滥用Union

上周Production DB Auser 反应他们作业的速度变得很慢。

这台DB用的是IBM X3850 16Core 2.93Ghz 16GB Memory AMS Storage,平时Performance表现十分良好,甚至可以支持一部分Report的作业。

[@more@]

SSH连接上去之后,打开TOP,IOSTAT观察:

IO在正常范围,最大IOWAIT不超过5%

CPU Utilization 比一般要高,时有冲到50%整的现象。

SMP System而言,这可以认为有Process持续消耗大量CPU

这是初步印象。

连入Oracle,观察了下v$session_wait

select * from v$session_wait where event not in

(select event from stats$idle_event)

发现很多Latch Free.

进一步鉴别:

SELECT l.name,s.* FROM v$session_wait s,v$latchname l

WHERE s.event='latch free' and s.P2=l.LATCH#

发现几乎一半是Library Cache, 一半是Library Cache Pin

Client还能继续执行,排除Compile造成objects被长期锁住的问题。

那就应该是shared_pool本身出现性能问题。

但这台DB 的通常应用很稳固,经过一年多调整,已经相当稳定,所以判断为有新的应用上线。

查了下正在执行的SQLLibrary Cache Pin Session在执行的SQL:

发现了一个令人惊讶的SQL:

v$sqltextCopyTXT上竟然有140KB.

仔细察看是 NSQL Union在一起,看来是某个程序自动生成的动态SQL。通知AP人员全部停止该应用后速度恢复正常。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10856805/viewspace-1012871/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/10856805/viewspace-1012871/

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值