?

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點

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

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

?

? ? ? ? ? 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分析

? ?

硬解析的次數非常低，排除硬解析過高的因素。 子游標版本最多173多，說明不多，不是子游標數量導致。 解析錯誤的也非常少，說明不是由于解析錯誤導致。 ? ?????可以看出故障時間點，sga各個組件在動態調整。 ?

2.2.5.?深入分析

從trc里分析出所有的cursor:?pin?S?wait?on?X等待的阻塞源頭都是SID：737會話，發現737是oracle@pmjxpdbb?(MMAN)會話，MMAN進程是Oracle?10g引入用于進行內存管理的進程，在進行動態內存調整時，這個進程要發揮其作用。 等到鏈都指向了源頭SGA:?allocation?forcing?component?growth。 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)

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

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

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。