机器：sun4u Sun Fire E4900
内存: 16GB
CPU： 4*1350
ORACLE：10.2.0.2.0 on RAC
群集软件：sun cluster
操作系统：Solaris 5.9

症状描述：
接到移动报告说数据库昨天在群发短信时hang住。下午出现同样情况，并且这个过程中执行任何的sql语句都会hang住。
非常奇怪的是，在另一个节点中可以轻松的执行任何操作。但是在此节点中sqlplus都无法登录。
赶到现场，收集hang住时间点的awrrpt.以下为top 5 event:

Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
latch: library cache 1,031 48,359 46905 89.6 Concurrenc
CPU time 5,235 9.7
gc cr multi block request 4,889,209 824 0 1.5 Cluster
enq: TM - contention 1,181 568 481 1.1 Applicatio
gc current block 2-way 58,770 41 1 0.1 Cluster

可见到latch等待非常之高，对于library cache详见本博客其他文章。
发现top session发现有一个sql语句在半个月前就开始执行，直到现在还未完成。找到该sql。其实只是一条无关紧要的select语句。
是查锁的。将其会话kill之。然后手工运行这个sql.发现很快就hang. 难道是这个sql引起的问题？不可能啊。仅仅是查v$lock和v$session这两个视图而已。其实就不管是什么视图，查询半个月总归是个大问题，并且总是在发短信的高峰期时hang住。
还好，抓到了一次现场。使用带truss命令的sqlplus登录。很快hang住。打开truss内容。并没有发现什么异常。也就是说问题并没有出在os级别或者软件级别了。继续看awrrpt报告。有一个地方引起怀疑，我发现有一个sql语句的version count达到37000之多：
Version
Count Executions SQL Id
-------- ------------ -------------
37,164 N/A g2k0nc8fbn337

这也就意味着oracle需要进行这么多的寻址。搜索到metalink，居然是个bug:5442957,原来是cursor_sharing=similar引起的bug.通过event 38056可解决。

晚上停掉数据库，添加Event = '38056 trace name context forever, level 1',问题OK。
这三天以来一直未出现个hang的情况。

注意:在节点01出现问题时，节点02是没有任何问题的。