公众号：杨建荣的学习笔记 · 作者：r6笔记第31天 · 发布：2015-08-18 00:00:27 · 原文链接

今天通过微信群和qq帮助一个网友分析了一个rac节点性能的问题，征得这位朋友的同学，和大家分享一下。
最开始这位朋友是在微信群中留言，说有一个rac的问题，现在已经严重影响在线业务了，希望我能够帮忙看看，有什么好的建议没，这对我来说着实是一个提高自己，分析问题的好机会，因为在地铁上，自己就简单确认了下环境，然后让他提供一些基本的错误日志或者报告。方便定位问题。
首先确认环境，得知这是一个rac 11g的环境，有两个节点，其它未知，根据这位朋友的反馈，有一个节点最近老出问题，前几天每天都报ora-00604,00609的错误，他查了下，说发现不是网络的问题就是sql语句的问题，然后今天节点又挂了，下午的时候报了ora-00020连接数超出的错误。作为临时解决方案，他把业务迁移到另外一个节点上之后就没有了问题，连接数也正常了。
从他的反馈来说，感觉这个节点存在一定的问题，但是不确定到底是什么原因，想让我来看一下。
很快从他那里得到了一个错误日志的截屏。

但是错误信息毕竟有限，而且这种错误还需要依赖上下文环境，这个时候手头也没有metalink来查看，就让这位朋友生成问题发生时间段的ash报告，把问题节点的ash报告和正常节点的ash报告都抓取一下。
过了一会，他就生成了ash报告，我让他把等待事件/top sql的部分贴出来。得到的截图如下：

在有限的信息中，这个问题着实让我捡了个大便宜，因为一看这部分，似乎问题的根源就有了眉目。
首先top sql的等待事件中，都指向了CPU，而且可以很明显的看到这些sql都走了全表扫描。然后我们往左边看，plan_hashvalue都是一致的，但是sql_id确不相同。然后向右看，目前看到的sql_text都是一致的。由此我脑海中得到了一个大体的影响，CPU的大量等待都在一些很相似的sql语句上，而且这些sql语句都走了全表扫描。很有可能是硬解析的问题，sql语句基本相同，可能没有使用绑定变量之类的。作为一个猜想，在回家之后，朋友已经发来了两个节点的ash报告。
带着疑问简单看了看，来做一个基本的验证。
首先是系统环境，