Systemstate Dump分析经典案例（下）

前言

接上一期： （上一期的阅读方法：关注“中亦安图”公众号后回复‘007’）

4.3.4

SSD中library cache lock的分析

接上一期：

分析到这步，前边看似毫无头绪的问题似乎理清了，大量cursor:pin S wait on X已经理清楚，所有的矛头走指向了sid 859

离真相只差一步了，我们只需要分析library cache lock的源头就能解释整个谜团了，前面老K已经提到了分析library cache lock等待事件的方法了，现在我们就来结合trace文件看看如何定位library cache lock的阻塞关系。

那好，我们就来看sid 859：

这个会话信息中我们能看到：

>> 会话在等待library cache lock等待事件，等待时间4429秒

>> 会话以S模式请求句柄为700000209bb9d80的library cache对象（request=S）

>> 句柄为700000209bb9d80的library cache对象是SYS.C_OBJ#_INTCOL#，是一个cluster（簇聚）对象。

我们就看到，会话859正在以S模式请求 700000209bb9d80上的library cache lock而产生了等待，那么我们就可以确认系统中一定有另一个会话以X模式持有了700000209bb9d80上的library cache lock；同样，我们在trace文件中搜索关键字”700000209bb9d80”再过滤后能看到下面的条目：

我们定位到该条信息后，再确认该条信息所属的会话，确认其会话信息如下：

看到这里，