2015.06.03
檢視生產庫的等待事件的時，經常看到 cursor: pin S 等待事件
這是一個由於頻繁執行SQL共享解析時產生的競爭。當一個會話嘗試以共享模式（S - Share）來獲得一個遊標時，需要修改相應的Mutex結構的引用計數（reference count），或者增加該計數，或者減少。修改引用技術的原子操作很快（其實和Latch的獲取釋放類似），但是在頻繁解析的情況下，仍然產生了競爭和等待，由此就產生了 cursor : pin S 的等待。
下面語句找到引起 cursor: pin S等待事件的具體SQL：

點選(此處)摺疊或開啟

SELECT a.*, s.sql_text
FROM v$sql s,
(SELECT sid,
event,
wait_class,
p1 cursor_hash_value,
p2raw Mutex_value,
TO_NUMBER (SUBSTR (p2raw, 1, 8), \'xxxxxxxx\') hold_mutex_x_sid
FROM v$session_wait
WHERE event LIKE \'cursor: pin S\') a
WHERE s.HASH_VALUE = a.cursor_hash_value;

這通常是由於某些SQL以超高頻繁的頻率執行導致的，當然也可能與系統的CPU能力不足有關。
結合該庫的實際情況，確定為某些SQL超高頻繁的執行導致的，應該是程式設計師或者資料庫開發人員將SQL寫到迴圈裡導致的，超高頻執行，算了一下業務高峰期時大概每分鐘，每個SQL執行10萬次。

Mutex機制在Oracle 10g引入，用於替代Library cache pin操作，其效能更高，其原理為在每個Child Cursor上分配一個地址空間記錄Mutex，當該Cursor被共享執行時，透過將該位進行加一處理來實現。雖然是指遊標共享，但是更新Mutex結構的操作需要排他，當某一個SQL被頻繁共享執行時，可能就會出現Pin S的等待。

每個Library Cache物件都有一個reference count （引用計數），用來表明有多少其他物件目前正保留一個對它的引用（reference). 物件A 想要引用物件B, A 就把B 的 reference count 加 1。當A 結束了對B 的引用， A 就把 B 的reference count 減 1. 當沒有任何物件再引用 B 時， B 的 reference count就減為0， B 就被清除（deallocated）, 記憶體就被釋放。清除B的時候，被B所用的物件的 reference count 也可能減小，也可能使它們被清除。

最簡單的解決方案是，將頻繁執行的SQL分割槽拆解，分散競爭。

cursor: pin S 等待事件

相關文章