?

1.????故障概述

?????7:15，二節(jié)點(diǎn)出現(xiàn)大量的“cursor:?pin?S?wait?on?X”等待事件，數(shù)據(jù)庫(kù)性能下降，持續(xù)到7:19分恢復(fù)正常，持續(xù)時(shí)間4分鐘左右。 下面是詳細(xì)的故障分析診斷過(guò)程。

2.????故障分析

2.1.??故障現(xiàn)象

7:15,系統(tǒng)出現(xiàn)大量“cursor:?pin?S?wait?on?X”等待事件，DBA未做任何操作，數(shù)據(jù)庫(kù)恢復(fù)正常。 ?

2.2.??故障分析

2.2.1.?故障現(xiàn)象

從AWR報(bào)告7點(diǎn)-8點(diǎn):15數(shù)據(jù)庫(kù)awr報(bào)告。

7:15點(diǎn)-7:19點(diǎn)

7:15點(diǎn)-7:19點(diǎn)分的awr報(bào)告可以看大量的cursor:?pin?S?wait?on?X?等待 ?

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

?

? ? ? ? ? Shared pool中的Hash Bucket?管理的是Object handle， 也就是元數(shù)據(jù)。其上存放了對(duì)象的name、?namespace及相關(guān)信息(對(duì)象是否只讀，是本機(jī)的還是遠(yuǎn)端的等)，也存放了當(dāng)前正在lock和pin以及正在等待lock和pin該對(duì)象的用戶的列表等。

? ? ? ? ? ?如果object handle存在，但是相關(guān)的object heap已經(jīng)被刷出內(nèi)存，此時(shí)object heap就要被重新reload(v$librarycache.reloads);如果相關(guān)object的定義已經(jīng)被更改(v$librarycache.invalidations)，此時(shí)就要重新解析相關(guān)對(duì)象。

? ? ? ? ? cursor: pin S wait on X表示會(huì)話試圖以S?模式?Pin?某個(gè)?Cursor?，但是某個(gè)會(huì)話已經(jīng)以?X?模式?Pinned，正在執(zhí)行?Loading，也就是?Parsing。 通常cursor: pin S wait on X?不是故障的原因，它只是受害者。

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

·??內(nèi)存抖動(dòng)

?但內(nèi)存抖動(dòng)會(huì)加劇shared pool的latch爭(zhēng)用，會(huì)導(dǎo)致出現(xiàn)cursor: pin S wait on X，library cache相關(guān)等待，嚴(yán)重可能導(dǎo)致數(shù)據(jù)庫(kù)hang死或者宕機(jī)?

·??頻繁硬解析

硬解析較多也會(huì)導(dǎo)致?cursor: pin相關(guān)等待增多

?

·??高版本
當(dāng)一個(gè)sql的版本過(guò)多，也就是子游標(biāo)過(guò)多，當(dāng)sql軟解析去掃描父游標(biāo)下面的子游標(biāo)，鏈路太長(zhǎng)也會(huì)導(dǎo)致大量的cursor: pin S wait on X等待。可以通過(guò)oracle提供的version_rpt3_21.sql去分析高版本的原因。

Cursor Obsolescence游標(biāo)廢棄是一種SQL Cursor游標(biāo)管理方面的增強(qiáng)特性，該特性啟用后若parent cursor父游標(biāo)名下的子游標(biāo)child cursor總數(shù)超過(guò)一定的數(shù)目，則該父游標(biāo)parent cursor將被廢棄，同時(shí)一個(gè)新的父游標(biāo)將被開(kāi)始。 這樣做有2點(diǎn)好處：

l??避免進(jìn)程去掃描長(zhǎng)長(zhǎng)的子游標(biāo)列表child cursor list以找到一個(gè)合適的子游標(biāo)child cursor

l??廢棄的游標(biāo)將在一定時(shí)間內(nèi)被age out，其占用的內(nèi)存可以被重新利用

實(shí)際在版本10g中就引入了該Cursor Obsolescence游標(biāo)廢棄特性，當(dāng)時(shí)child cursor?的總數(shù)閥值是1024， 但是這個(gè)閥值在11g中被移除了,這導(dǎo)致出現(xiàn)一個(gè)父游標(biāo)下大量child cursor即high version count的發(fā)生；由此引發(fā)了一系列的版本11.2.0.3之前的cursor sharing?性能問(wèn)題，主要癥狀是版本11.2.0.1和11.2.0.2上出現(xiàn)大量的Cursor: Mutex S?和library cache lock等待事件。

通過(guò)如下參數(shù)通知子游標(biāo)的版本數(shù)量。

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

?

·??錯(cuò)誤解析

比如sql語(yǔ)法錯(cuò)誤

·??DDL

DDL語(yǔ)句會(huì)導(dǎo)致相關(guān)對(duì)象的所有游標(biāo)都失效，當(dāng)再次解析時(shí)會(huì)造成卡頓。

·??收集統(tǒng)計(jì)信息?

收集統(tǒng)計(jì)信息（使用ANALYZE或DBMS_STATS）中參數(shù)no_invalidate?設(shè)置為false，表示游標(biāo)立即失效，將導(dǎo)致庫(kù)緩存對(duì)象失效，并且這可能會(huì)級(jí)聯(lián)到許多不同的依賴(lài)對(duì)象（如游標(biāo)）。失效對(duì)庫(kù)緩存，共享池，行緩存和CPU有很大影響，因?yàn)樗鼈兛赡苄枰瑫r(shí)進(jìn)行許多硬解析。

?

·??大量并發(fā)

大并發(fā)會(huì)導(dǎo)致cursor: pin S wait on X爭(zhēng)用。

·??Known bugs等

?

2.2.4.?AWR分析

? ?

硬解析的次數(shù)非常低，排除硬解析過(guò)高的因素。 子游標(biāo)版本最多173多，說(shuō)明不多，不是子游標(biāo)數(shù)量導(dǎo)致。 解析錯(cuò)誤的也非常少，說(shuō)明不是由于解析錯(cuò)誤導(dǎo)致。 ? ?????可以看出故障時(shí)間點(diǎn)，sga各個(gè)組件在動(dòng)態(tài)調(diào)整。 ?

2.2.5.?深入分析

從trc里分析出所有的cursor:?pin?S?wait?on?X等待的阻塞源頭都是SID：737會(huì)話，發(fā)現(xiàn)737是oracle@pmjxpdbb?(MMAN)會(huì)話，MMAN進(jìn)程是Oracle?10g引入用于進(jìn)行內(nèi)存管理的進(jìn)程，在進(jìn)行動(dòng)態(tài)內(nèi)存調(diào)整時(shí)，這個(gè)進(jìn)程要發(fā)揮其作用。 等到鏈都指向了源頭SGA:?allocation?forcing?component?growth。 SGA組件中KGH:?NO?ACCESS持續(xù)變大?，KGLH0、SQLA持續(xù)變小，KGH:?NO?ACCESS表示緩沖區(qū)緩存和共享池之間的部分傳輸，正是由于內(nèi)存組件的調(diào)整，latch:?shared?pool被爭(zhēng)用，造成了大量的cursor:?pin?S?wait?on?X等待。 ?

3.????解決方案

1、增大shared_pool_size?的最小值90G（SGA 600G*15%），或者采用手工內(nèi)存管理的方式

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

2、縮小buffer cache大小，可以減小gcs resources、gcs shadows組件的大小。

2、優(yōu)化TOP SQL，尤其是全表掃描大量物理讀的sql。

?

總結(jié)

以上是生活随笔為你收集整理的cursor:pin S wait on X故障诊分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。