【中亦安图】Systemstate Dump分析经典案例（7）

2016-04-18 1459

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 第一章技术人生系列 · 我和数据中心的故事（第七期）Systemstate Dump分析经典案例（上）中亦安图 | 2016-03-03 21:42 前言本期我们邀请中亦科技的另外一位Oracle专家老K来给大家分享systemstate dump分析的经典案例。

第一章技术人生系列 · 我和数据中心的故事（第七期）Systemstate Dump分析经典案例（上）

中亦安图 | 2016-03-03 21:42

前言

本期我们邀请中亦科技的另外一位Oracle专家老K来给大家分享systemstate dump分析的经典案例。后续我们还会有更多技术专家带来更多诚意分享。

老K作为一个长期在数据中心奋战的数据库工程师，看到小y前期的分享，有种跃跃欲试的感觉，也想把我日常遇到的一些有意思的案例拿出来分享讨论，希望我们都能从中获得些许收获，少走弯路。同时本文涉及到很多基础知识，又涉及看似枯燥的trace分析，但老K还是建议大家耐心看完本文。

精彩预告如何分析cursor:pin S wait on X？

如何分析library cache lock？

如何分析解读systemstate dump？

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

温馨提示温馨提示：该篇为老K诚意之作，篇幅略长，如微信阅读有所不适，可以移步QQ群：227189100下载文本阅读，并同时关注我们的微信号“中亦安图”与我们交流。

Systemstate Dump我们暂且叫SSD吧

Part 1

问题来了

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

现象描述：

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

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

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

Part 2

故障处理及信息收集

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

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

Part 3

知识点扫盲

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关键字查找到该等待事件的源头。

那么数据库异常时间内到底发生了什么，我们通过trace入手，还原现场。

Part 4

故障分析

环境介绍：

操作系统 AIX 5.3

数据库 ORACLE 10.2.0.5 两节点RAC

4.1 第一次头脑风暴

现有“情报”

>> RAC系统一个节点夯

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

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

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

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

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

4.2 入手分析

4.2.1

SSD入手分析

常规处理方法：对于cursor:pin S wait on X等待事件，只需关注其等待对象，是同一个对象还是多个不同对象，如果都是等待在一个对象上，情况相对简单，要找到这个等待的对象，那就需要到SSD的trace中查找关键字’waiting for ‘cursor:pin S wait on X’，结果见下图：