東南亞某國，系統A已上線好幾年，資料量較小，一直執行正常，4月22號同事反應

系統處在hang的狀態，一啟動，就有好多session . 系統基本不用。

OS:suse10

DBMS:11.1.0.7

ps -ef|grep ora|wc -l 發現程式數一直在增長

執行sql

-- 查詢當前會話資訊
select t3.sql_id, t3.sql_text, t1.SID, t1.SERIAL#, t1.STATUS, t1.PROGRAM, t1.LOGON_TIME, t1.EVENT, t1.SECONDS_IN_WAIT, t2.SPID
from v$session t1,
       v$process t2,
       (select sql_id, sql_text
          from v$sql
         group by sql_id, sql_text) t3
where t1.paddr = t2.addr
   and t1.status = 'ACTIVE'
   and t1.sql_id = t3.sql_id(+)
order by sql_text;

發現大量的cursor: pin S wait on X等待事件

74c1hdswksgyt	select id,name from V_NE_NETYPE	502	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	single-task message
gts5km94cpd3f	select id,name from v_ne_netype t	515	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	cursor: pin S wait on X
gts5km94cpd3f	select id,name from v_ne_netype t	506	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	single-task message
gts5km94cpd3f	select id,name from v_ne_netype t	523	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:15	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	520	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	531	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:15	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	530	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:15	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	526	4	ACTIVE	JDBC Thin Client	2013/4/22 17:15:15	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	525	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:15	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	18	16	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	508	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	505	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	cursor: pin S wait on X
6ua7g9w10tnrj	select id,name from v_ne_netype where id='20'	495	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	single-task message
cb8d7tmyz0gau	select id,name from v_ne_netype where id='30'	524	2	ACTIVE	JDBC Thin Client	2013/4/22 17:15:15	single-task message
a7k5va9c6x21n	select id,name from v_ne_netype where 1=1	513	7	ACTIVE	JDBC Thin Client	2013/4/22 17:15:16	cursor: pin S wait on X

cursor: pin S wait on X 這是這周來第二次遇到此事件，上次是因為系統bug

cursor: pin S A session waits on this event when it wants to update a shared mutex pin and another session
is currently in the process of updating a shared mutex pin for the same cursor object. This wait event should
rarely be seen because a shared mutex pin update is very fast.(Wait Time: Microseconds)
 
引起這個等待事件有幾個原因
1. 硬解析太高
2. shared_pool 大小
3. bug 
第一個原因，系統已經運好幾年了，雖然很多沒有繫結變數，但也不會這麼嚴重
調大了shared_pool 
alter system set shared_pool_size=2g scope=both;
依然沒有好轉
 
出了awr 報告
 
在SQL ordered by Parse Calls

裡發現

有一個這個sql

begin :id := sys.dbms_transaction.local_transaction_id; end;

被解析1400多次。

這個處理分散式事務的一個application ,諮詢同事有無分散式資料庫的使用，比如dblink, 被告知只有webservice 沒有dblink.（其實是有的，這裡誤導了我）

再回到開始在等待的sql裡找出一

select id,name from v_ne_netype where id='20' 直接hang住，不執行。

再問同事，v_ne_netype 是由一個dblink 的檢視。此dblink 指向系統B

此時的B 透過plsql 已不能正常聯接。

原因找到

登陸B 系統，檢視其監聽，命令響應很慢。不能關閉，也不能重啟。

日誌也沒有。 kill 掉監聽程式，重啟監聽。 B系統正常。 A系統也正常。

原因：B系統因為一些原因，監聽異常，不能正確解析sql ,引發的聯鎖反應。

分散式引起的cursor: pin S wait on X 事件一次問題處理

SQL ordered by Parse Calls

相關文章