定位rac环境中某条sql执行时间过长

    今天早上开发人员反应昨晚跑的一个存储过程到今天早上还没执行完，于是sqlplus登陆实例1和实例2，查询到该存过程是连接自实例1的，而该存储过程对应的sql语句已经执行了10多个小时，现在会话处于cr request retry等待事件中，通过v$session的p1和p2列确定了该事件正在等待14号文件的68859号块，然后通过dba_extents又进一步定位了该块位于X表上，且实例1上还有若干会话也都处于cr request retry等待时间中，通过v$session的sql_id与v$sql的sql_id关联查询到这些sql都共同访问了X表。
     在实例1上查询到的都是对65589号块的请求，并没有发现持有该块资源的会话，这时觉得持有该资源的会话应该在实例2上，于是连接自实例2，通过对v$session的查询发现也有若干会话处于read by other session等待事件中，还有1个会话处于de file sequencial read等待事件中，而这个会话长时间一直在对65589号块进行读取操作，这时怀疑问题的根源应该是这个会话的问题。和开发人员沟通后确认这个会话对应的sql是个分页查询，可以kill掉这个会话，于是通过关联v$process确认spid后，在os上杀掉了该进程，然后马上查询实例2和实例1上的会话情况，这时相关等待事件全部消失，开发人员再次手动执行存储过程，此时该存储过程可以在规定时间内顺利跑完。
      这里还有一点疑惑就是什么原因导致实例2上那个会话一直处于对65589块的db file sequencial read等待事件中。。。。。。。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/20801486/viewspace-723345/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/20801486/viewspace-723345/