active會話不斷增多案例處理

wenhual43發表於2012-04-24
會話
今天巡檢一個資料庫， 作業系統AIX裡檢視資源情況，記憶體使用維持在95%，cpu在90%，分頁用了27% ，磁碟bisy在1%。查詢select count(*) from v$session where status='ACTIVE‘  發現有300多活動會話，平時就40，50個。真的嚇我一跳。檢視鎖資訊，沒有鎖。檢視等待事件，
select sid,p1,p1raw,p2,p2raw,p3,p3raw,wait_time,seconds_in_wait,state,event
  from v$session_wait where event not in (select name from v$event_name where wait_class='Idle');  
發現300多個“cursor: pin S wait on X”事件。檢視活動的會話，都是查的一張表infec表，LOGON_TIME 都在4月9號，還有一部分是4月10號，還有少些是4月24號的。今天都是4月24號了，這麼早的會話還保持活動。原來該表是通過dblink查的別的資料庫的表，而4月9號那個源庫down過機器，這可能是導致會話一直沒有釋放的原因。
解決方法：把有問題的sesion查出來，殺掉。
kill session語句如下：
select 'ALTER SYSTEM KILL SESSION ''' || sid || ',' || serial# || ''';'
  FROM (select DISTINCT s.sid AS sid, s.serial# AS serial#
          from v$sqltext sq, v$session s
         where sq.ADDRESS = s.SQL_ADDRESS
           and sq.SQL_TEXT like '%INFEC%'
           and s.STATUS = 'ACTIVE') P
殺掉這些會話，cpu，記憶體，分頁使用率都降下來了。
總結：如果dblink源庫down過，可能會導致當時的查詢語句一直保持ACTIVE，必須檢查和down庫相關的資料庫的會話，把這些hang住的會話殺掉。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25027760/viewspace-722153/，如需轉載，請註明出處，否則將追究法律責任。

相關文章