上周,Production DB A的user 反应他们作业的速度变得很慢。
这台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 的通常应用很稳固,经过一年多调整,已经相当稳定,所以判断为有新的应用上线。
查了下正在执行的SQL和Library Cache Pin 的Session在执行的SQL:
发现了一个令人惊讶的SQL:
从v$sqltext中Copy到TXT上竟然有140KB.
仔细察看是 N个SQL Union在一起,看来是某个程序自动生成的动态SQL。通知AP人员全部停止该应用后速度恢复正常。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10856805/viewspace-1012871/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/10856805/viewspace-1012871/