cursor:pin S wait on X故障诊分析

 

1.    故障概述

     7:15,二节点出现大量的“cursor: pin S wait on X”等待事件,数据库性能下降,持续到7:19分恢复正常,持续时间4分钟左右。
下面是详细的故障分析诊断过程。

2.    故障分析

2.1.  故障现象

7:15,系统出现大量“cursor: pin S wait on X”等待事件,DBA未做任何操作,数据库恢复正常。
 

2.2.  故障分析

2.2.1. 故障现象

从AWR报告7点-8点:15数据库awr报告。

7:15点-7:19点

cursor:pin S wait on X故障诊分析_第1张图片

7:15点-7:19点分的awr报告可以看大量的cursor: pin S wait on X 等待
 

2.2.2. 什么是cursor: pin S wait on X

cursor:pin S wait on X故障诊分析_第2张图片

cursor:pin S wait on X故障诊分析_第3张图片

 

          Shared pool中的Hash Bucket 管理的是Object handle, 也就是元数据。其上存放了对象的name、 namespace及相关信息(对象是否只读,是本机的还是远端的等),也存放了当前正在lock和pin以及正在等待lock和pin该对象的用户的列表等。

           如果object handle存在,但是相关的object heap已经被刷出内存,此时object heap就要被重新reload(v$librarycache.reloads);如果相关object的定义已经被更改(v$librarycache.invalidations),此时就要重新解析相关对象。

          cursor: pin S wait on X表示会话试图以S 模式 Pin 某个 Cursor ,但是某个会话已经以 X 模式 Pinned,正在执行 Loading,也就是 Parsing。 通常cursor: pin S wait on X 不是故障的原因,它只是受害者。

2.2.3. cursor: pin S wait on X故障原因

·  内存抖动

 但内存抖动会加剧shared pool的latch争用,会导致出现cursor: pin S wait on X,library cache相关等待,严重可能导致数据库hang死或者宕机 

·  频繁硬解析

硬解析较多也会导致 cursor: pin相关等待增多

 

·  高版本
当一个sql的版本过多,也就是子游标过多,当sql软解析去扫描父游标下面的子游标,链路太长也会导致大量的cursor: pin S wait on X等待。可以通过oracle提供的version_rpt3_21.sql去分析高版本的原因。

Cursor Obsolescence游标废弃是一种SQL Cursor游标管理方面的增强特性,该特性启用后若parent cursor父游标名下的子游标child cursor总数超过一定的数目,则该父游标parent cursor将被废弃,同时一个新的父游标将被开始。 这样做有2点好处:

l  避免进程去扫描长长的子游标列表child cursor list以找到一个合适的子游标child cursor

l  废弃的游标将在一定时间内被age out,其占用的内存可以被重新利用

实际在版本10g中就引入了该Cursor Obsolescence游标废弃特性,当时child cursor 的总数阀值是1024, 但是这个阀值在11g中被移除了,这导致出现一个父游标下大量child cursor即high version count的发生;由此引发了一系列的版本11.2.0.3之前的cursor sharing 性能问题,主要症状是版本11.2.0.1和11.2.0.2上出现大量的Cursor: Mutex S 和library cache lock等待事件。

通过如下参数通知子游标的版本数量。

alter system set "_cursor_obsolete_threshold" =100 scope=spfile;

 

·  错误解析

比如sql语法错误

·  DDL

DDL语句会导致相关对象的所有游标都失效,当再次解析时会造成卡顿。

·  收集统计信息 

收集统计信息(使用ANALYZE或DBMS_STATS)中参数no_invalidate 设置为false,表示游标立即失效,将导致库缓存对象失效,并且这可能会级联到许多不同的依赖对象(如游标)。失效对库缓存,共享池,行缓存和CPU有很大影响,因为它们可能需要同时进行许多硬解析。

 

·  大量并发

大并发会导致cursor: pin S wait on X争用。

·  Known bugs

 

2.2.4. AWR分析

cursor:pin S wait on X故障诊分析_第4张图片

cursor:pin S wait on X故障诊分析_第5张图片

 
硬解析的次数非常低,排除硬解析过高的因素。
cursor:pin S wait on X故障诊分析_第6张图片
子游标版本最多173多,说明不多,不是子游标数量导致。

解析错误的也非常少,说明不是由于解析错误导致。
 

cursor:pin S wait on X故障诊分析_第7张图片

     可以看出故障时间点,sga各个组件在动态调整。
 

2.2.5. 深入分析

cursor:pin S wait on X故障诊分析_第8张图片

cursor:pin S wait on X故障诊分析_第9张图片

从trc里分析出所有的cursor: pin S wait on X等待的阻塞源头都是SID:737会话,发现737是oracle@pmjxpdbb (MMAN)会话,MMAN进程是Oracle 10g引入用于进行内存管理的进程,在进行动态内存调整时,这个进程要发挥其作用。

cursor:pin S wait on X故障诊分析_第10张图片

等到链都指向了源头SGA: allocation forcing component growth。

cursor:pin S wait on X故障诊分析_第11张图片

cursor:pin S wait on X故障诊分析_第12张图片

SGA组件中KGH: NO ACCESS持续变大 ,KGLH0、SQLA持续变小,KGH: NO ACCESS表示缓冲区缓存和共享池之间的部分传输,正是由于内存组件的调整,latch: shared pool被争用,造成了大量的cursor: pin S wait on X等待。
 

3.    解决方案

1、增大shared_pool_size 的最小值90G(SGA 600G*15%),或者采用手工内存管理的方式

根据Best Practices and Recommendations for RAC databases with SGA size over 100GB (Doc ID 1619155.1)

cursor:pin S wait on X故障诊分析_第13张图片

2、缩小buffer cache大小,可以减小gcs resources、gcs shadows组件的大小。

2、优化TOP SQL,尤其是全表扫描大量物理读的sql。


 

你可能感兴趣的:(技术博文,Oracle,Oracle,探索系列,数据库,sql,mysql)