今天早上刚到办公室，应用支撑侧同事打电话告诉我某某系统很慢并且有超时现像发生，让我分析一下数据库是不是有异常，登陆数据库后发现数据库日志中提示会话数ORA－00018 Maximum number of sessions exceeded超出最大会话数，该库正常情况下会话数在300-600之间，数据为设置session数量是1105，肯定发生了严重的等待事件，取出当时AWR报告进行分析，记录一下分析过程。

http://s6/mw690/001N2SGigy6FiEzmf6l45&690read by other session" TITLE="AWR实战分析之---- read by other session" />

    发现数据库由session原来的331直接上升至1020，验证了日志报错信息，不超才怪，但是以目前服务器配置来看，数据库负载并不算太高，再看看TOP 5等待事件

http://s13/mw690/001N2SGity6FmN5DkzWfc&690read by other session" TITLE="AWR实战分析之---- read by other session" />
    正常情况下，db file sequential read是由于索引扫描引起，在TOP 5中排在第四或第五位是正常的，无须过多关注，但是今天它跑到了第一位，并且伴随着read by other session那就说明问题了，首先我们知道read by other session等待的原理是多个会话并发将同一数据块从磁盘读入SGA，但ORACLE同一时间只允许一个会话从磁盘将同一数据块读入SGA，在并发情况下其它session必须等待，因此就有了read by other session等待事件，结合两个等待事件原理，我们基本上可以断定，系统发生了高并发查询，并且从log file sync等待事件来看，系统发生了频率的提交操作，导致数据库日志频率同步，实际情况是不是这样呢？这一点我们可以从Load Profile和TOP SQL部分可以得到验证，如下图所示

http://s14/mw690/001N2SGigy6FiEJsRk19d&690read by other session" TITLE="AWR实战分析之---- read by other session" />

    因为该系统是ERP系统，虽是全国用户在用，但是实际业务并发性并不高，但是我们从图上可以看到，每秒用户调用7986.19次，每秒执行6375.54次，典型的高并发，如此高的并发在做什么？这一点我们只能从TOP SQL中去寻找答案，我们看看TOP SQL能告诉我们什么？

SQL ordered by Elapsed Time

http://s5/mw690/001N2SGity6FmNlS2QQ54&690read by other session" TITLE="AWR实战分析之---- read by other session" />
    很明显，三条SQL在一小时内执行都超过百万次，确实发生了高并发查询，同时我们可以看到确实有频率的插入操作提交操作，一小时内执行了89178次，验证了我们前面分析，但是从SQL Module看出，并发查询都是从都是机器ECMora01发起的，并且ECMora01是一个数据库服务器，两者之间是通过dblink连接，实际业务情况是从ECMora01查询数据，然后ECMora01通过dblink查询本案例数据库中的数据，这时我们只能再从ECMora01数据库着手分析，并且ECMora01此时会话数也超过了系统最大值，并且等待事件是另一种类型，我们在下一案例中进行分析，read by other session等待事件分析到此为止。