接上一期:<强>
<强> 4.3.4
<强>
接上一期:
分析到这步,前边看似毫无头绪的问题似乎理清了,大量光标:销年代等alt=" Systemstate转储分析经典案例(下)">
<强>这个会话信息中我们能看到:
祝辞祝辞会话在等待库缓存锁等待事件,等待时间4429秒
祝辞祝辞会话以年代模式请求句柄为<强> 700000209 bb9d80 的库缓存对象(请求=S)
祝辞祝辞句柄为700000209 bb9d80的库缓存对象是系统。C_OBJ#_INTCOL#，是一个cluster（簇聚）对象。
我们就看到，会话859正在以S模式请求700000209bb9d80上的library cache lock而产生了等待，那么我们就可以确认系统中一定有另一个会话以X模式持有了700000209bb9d80上的library cache lock；同样，我们在trace文件中搜索关键字”700000209bb9d80”再过滤后能看到下面的条目：
我们定位到该条信息后，再确认该条信息所属的会话，确认其会话信息如下：
看到这里，大家有没有柳暗花明的感觉呢，我们看到持有
会话正在请求C_OBJ#_INTCOL#上的library cache lock而产生等待，而从这三条sql的文本来看，似乎都跟C_OBJ#_INTCOL#这个对象扯不上关系，这又怎么解释呢？有细心的读者可能已经注意到了，前面老K特意指出了C_OBJ#_INTCOL#是一个cluster（簇聚）对象，cluster对象不是表，而是用来存储多个表的共同列的，那这里我们就可以注意最底层调用的sql中的histgrm$对象是否与C_OBJ#_INTCOL#有关，我们来看看histgm$的定义：
又解开了一个谜题，histgrm$确实使用了C_OBJ#_INTCOL#这个cluster对象，所以在解析使用了histgrm$表的sql语句时，需要获取C_OBJ#_INTCOL#上的library cache lock。
5.3 柳暗花明之会话624
接下来，再来看看会话624，像分析会话859一样，把单个进程的trace摘出来，我们来截取部分信息如下：
从这里看，这是一个被调起的job进程，PROCESS号为42；
这不是一个数据库的后台进程，所以，相比于之前看到的859进程，我们能看到更多的信息，我们大致知道，这个进程是数据库调起的收集统计信息的job任务，在等待”cursor:pin S wait alt="Systemstate Dump分析经典案例（下）">
同样，我们也能从sql语句的语义上猜到两者的递归调用关系；
会话624持有了C_OBJ#_INTCOL#和I_OBJ#_INTCOL#的library cache lock，其中I_OBJ#_INTCOL#是CLUSTER的索引。现在所有疑团都解开了。可以放松一下，从头捋顺思路了。
终于看到了全景，看看数据库故障时刻在做什么。
在本场景中，t1时刻，数据库自动收集统计信息任务调度J000进程收集整个数据库统计信息，在收集cluster对象时，数据库只能使用analyze的方式分析；
t4时刻，这时CJQ0进程定时查询系统JOB时，需要硬解析，递归调用bbcee4f7时对其进行解析；
解析的过程中需要以S模式请求持有histgrm$及其相关对象（也就包括C_OBJ#_INTCOL#及其索引I_OBJ#_INTCOL#）的library cache lock；
t4时刻，J000进程正在analyze索引I_OBJ#_INTCOL#，也就以X模式持有了I_OBJ#_INTCOL#上的library cache lock；
在J000使用analyze的过程中，同样需要执行相关递归sql，需要进行硬解析，也就调用了上面说到的关键sql bbcee4f7；
