love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

The cause of system hung is cursor: pin X ?

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: The cause of system hung is cursor: pin X ?

这是一个朋友单位的库,据说该库hung了一段时间,从alert log来看,中间有2小时是没有任何信息,难道hung了2个小时吗 ? alert log 如下:

上述的信息是很简单的,提到了system state dump,下面我们来看下朋友提供的dump. 首先利用脚本先格式化一下:

很显然,从脚本格式化之后的信息来看,这部分信息是我们要分析的关键:

 

19和32都是holder,而32 正在等待19. 注意,这里的19,32其实都是值的orapid。
我们可以看到,orapid 32正在正待Latch 70000006b9d8008,而orapid 32在等待19,那么orapid 19可能就是我们需要分析的关键了。 从这里来看,orapid 19似乎同时持有了一个mutex和latch,下面我们来分别看下orapid 19和32 的详细信息:

我们可以看到orapid 32是一个用户进程,正在等待library cache latch,latch地址是:70000006b9d8008
从possible holder pid = 19 ospid=10027060 可以看出,这个latch正在被orapid 19所持有,下面我们搜索关键字:process 19

 

我们可以看到orapid 19这个进程正在持有llibrary cache latch 70000006b9d8008没有释放,到前面的orapid 32一直等待。
然而我们可以看到,orapid 19虽然持有了70000006b9d8008这个latch,然而同时它也在等待一个library cache latch 70000006b9d7f68
我们可以看到这个orapid 19的进程其实是J001,其状态已经为dead了。同时我们分析下面的mutex信息,发现该进程同时还持有了mutex: Mutex 70000003eec4be0(534, 0) idn ad39e34 oper EXCL
从这句话我们可以看出,orapid 19还持有了mutex ad39e34,而且mode为exel,即排他模式. 根据这个mutex 地址,我们进行搜索,发现 Oracle Pmon进程正在申请这个Mutex,如下:

可以看到pmon进程一直在等待这个mutex,也需要申请获得排他模式的mutex(类似传统的排他模式的library cache pin).
而由于这个mutex被前面的orapid 19(j001)锁持有,没有释放,导致pmon进程挂起。
最后我们简单的总结下:
1、大量的进程在等待library cache latch,而该latch被orapid 19(J001)进程所持有.

2、J001进程持有library cache latch不释放,同时还申请持有mutex,该进程状态是dead

3、Pmon进程申请排它模式的Mutex,而该mutex被J001进程持有,且状态也是排它模式.

4、按理说J001进程死掉之后,其持有的latch信息应该都会被pmon进程所清理释放掉,因为   这本身就是pmon进程的分内之事,然而由于mutex的原因,导致pmon进程挂起。

5、最后由于pmon进程也无法获得mutex,导致无法清理j0001进程,最后导致j0001阻塞了大量会话,   出现大面积library cache latch等待,最后整个系统hung.
6、个人认为问题的根据还是mutex的问题,library cache latch只是表象.

Leave a Reply

You must be logged in to post a comment.