前言

精彩预告

• 如何分析 cursor:pin S wait on X？

• 如何分析 library cache lock？

• 如何分析解读 systemstate dump？

• 如何快速应急处理以及收集信息？

一个周末的早上，客户来电，两节点RAC数据库其中一个节点夯死。

现象描述：

>> 节点hang死，SYS和普通用户均无法登陆

>> 受影响范围只在其中一个节点，其他节点能正常对外提供服务

>> hang死节点有大量异常等待事件cursor:pin S wait on X以及少量library cache lock。

老K第一反应是让客户快速收集数据库hanganalyze 和SSD，马上通过杀进程的方式重启问题节点数据库，优先恢复数据库服务。

最终，客户在收集完信息发给老K后，重启了问题节点数据库，一切又恢复了正常。

cursor:pin S wait on X

什么时候会产生这个等待事件？

当一个会话以X模式持有某个cursor（如sql/procedure/function/package body等）的mutex时，如果另一个会话需要以S模式请求该cursor的mutex；一般来说，对cursor进行硬解析时，会以X模式持有cursor的mutex，而对cursor进行软解析时，则会以S模式持有cursor的mutex；

举一个简单的例子，一个会话（SESSION_A）正在解析（硬解析）某一个sql语句（SQL_A），当另一个会话（SESSION_B）同时执行这条sql语句（SQL_A）时（执行前需要对该语句进行软解析），SESSION_B就会等待cursor:pin S wait on X 事件。

如何定位其等待的对象？

该等待事件的P1参数idn，实际上就是sql语句的hash_value，也就是说通过该等待事件的P1参数即可定位等待的实际对象。

如何查找该事件的源头？

在定位了该等待事件所等待的对象后，该对象MUTEX的持有者即为该等待事件的源头。

在trace文件中，可以通过oper EXCL关键字查找到持有者。

library cache lock

什么时候会产生这个等待事件？

当一个会话对library cache中的对象（主要是TABLE /INDEX/CLUSTER/PROCEDURE等）进行修改（通常是指DDL操作）时，会以X模式持有该对象的library cache lock；当一个会话在解析sql需要用到某个对象时，会以S模式请求该对象的library cache lock；

举一个简单的例子，一个会话（SESSION_A）正在对表TAB_A进行DDL操作，另一会话（SESSION_B）开始执行与TAB_A相关的sql语句，那么此时SESSION_B此时会等待library cache lock事件。

如何定位其等待的对象？

该等待事件的P1为handle address即为等待对象在library cache 中的句柄地址，可唯一标示该内存对象。

如何产生该事件的源头？

在定位了该等待事件所等待的对象后，持有该对象的X模式library cache lock的会话即为等待事件的源头。

在trace文件中，可以通过对象的地址关键字和mode=X关键字查找到该等待事件的源头。

环境介绍：

操作系统 AIX 5.3

数据库 ORACLE 10.2.0.5 两节点RAC

现有“情报”

>> RAC系统一个节点夯

>> 数据库中存在大量cursor:pin S wait on X 等待事件和少量library cache lock等待事件

>> 有收集的hanganalyze 信息和SSD  trace文件

这两个等待事件的原理是什么？

出现上述等待事件后系统的表现是什么？

当一个系统出现大量cursor:pin S wait on X 等待事件时，通常原因是由于一个会话的sql硬解析异常，阻塞了这条SQL的软解析，这种情况下，可能的源头就只有一个，只要把源头找到，问题就迎刃而解了。

出乎老K的意料，这些等待” cursor:pin S wait on X”的会话并不都在同一个idn上，而是分布在几个不同的idn上。

看起来问题比老K开始想象的要复杂，但是没有关系， 以老K处理各种问题的经验来看，复杂问题只不过是多个简单问题的集合而已，需要的只是多一点耐心。

这里需要解释一下

idn 82d61778：表明cursor对象

oper GET_SHRD：表明该会话正在以shared模式请求该mutex

(858, 0)：表明该mutex的持有者sid为858

我们看到了会话859持有了bbcee4f7的mutex，然后它又在等待”library cache lock”事件。

问题查到这，我们停下来想一想。

>> 会话598在等待cursor:pin S wait on X，阻塞者sid为 858

>> 会话858在等待cursor:pin S wait on X事件，阻塞者sid为859

>> 会话859在等待library cache lock事件，阻塞者待查

>> library cache lock的阻塞者是谁，很有可能是一个“元凶之一”

>>是不是大量的cursor:pin S wait on X都被library cache lock阻塞，如果是的话问题就变得简单了

离真相只差一步了，我们只需要分析library cache lock的源头就能解释整个谜团了，前面老K已经提到了分析library cache lock等待事件的方法了，

下一步只要结合trace文件定位library cache lock的阻塞关系，就能很快定位原因了。

由于篇幅有限，本期分享到这里先告一段落，下期分享继续，看老K如何一步一步由浅入深，分析问题，看看高大上的SSD分析是什么样的。敬请关注下期（未完待续...）