上周，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博客

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