案例：troubleshooting row cache lock(一)

今天某交管客户出现登录异常，应用反馈无法登录数据库。数据库版本为11.2.0.4，patch版本没注意，先暂时不关注。使用客户提供的异常用户测试登录发现确实会hang住。

当时等待事件为：

当看到row cache lock和library cache lock一般来说需要分析是row cache的哪个组件发生争用，library cache lock的namespace等等。

进一步分析：

从11.2之后如果是密码错误导致的密码延迟一般产生的是library cache lock，这里发现有很多session username是空的，这就说明是那些登录异常的session，都是等待row cache lock，通过p1可以判断是dc_users组件。最终阻塞会话为2838，但是尝试去kill 2838时发现并没有解决问题，只是换了一个最终阻塞会话。原因在于row cache lock是一个enqueue，虽然没有TX那么多mode，它只有S(共享)和X(排他)，其中S与S兼容，S阻塞X，X阻塞S，X阻塞X。如果这时有一个X模式的请求进入到enqueue中并且没有释放的话，那么会阻塞后续所有S和X的请求。

由于急于恢复业务，kill掉所有local=no的session。但仍然可以通过diag生成的systatedump去分析。

从row cache enqueue state object中可以看到有dc_users的X模式的请求，：

通过0x2fe20af948去搜索session state object，可以找到对应的sql

根据0x2db37f7f88去搜索LibraryHandle找到sql文本

发现该session执行的sql是grant execute any procedure to centernew ，但是从session state object里面看到program: JDBC Thin Client，一般情况JDBC连接上来的session不会去单独执行grant操作。

搜索0x2fc14626f0可以找到process so，并且可以看到当时的short_stack

calls cur/top: 0x2dcae69d40/0x2dcae3d400，继续搜索top 0x2dcae3d400看看是什么调用了该sql

发现是CENTERNEW.DBT_ALL_FN_TRC_EXETCPU_REQ存储过程调用的，由于systatedump是基于某个时刻，所以最好分析ash查询还有哪些存储过程对dc_users进行x模式请求。

至此此案例分析完毕，从ash可以看到有5个存储过程中包含了grant user的语句，并且反复执行了多次导致了此次故障。