一次TM ENQ故障處理

westzq1984發表於2011-06-02
原文網址 : http://blog.itpub.net/8242091/viewspace-697005/
ENQ
監控到客戶系統下午3點過AAS突然從20多猛增到300多。

檢查發現主要是TM等待
SQL> select blocking_session,P2,COUNT(*)
  2    from v$active_session_history
  3   where sample_time between to_date('20110602 1515', 'yyyymmdd hh24:mi') and
  4         to_date('20110602 1520', 'yyyymmdd hh24:mi')
  5    AND event='enq: TM - contention'
  6    GROUP BY  blocking_session,P2
  7  ;
 
BLOCKING_SESSION         P2   COUNT(*)
---------------- ---------- ----------
            1456      78324          9
             979      78324          2
            2806      78324          3
             797      78324      23054
            1889      78324          1
            1878      78324         24
            2212      78324          2
            3507      78324          1
            1536      78324          4
             831      78324          1
            3252      78324          4
            3179      78324       3020
            1192      78324          3
            4512      78324        109
            2465      78324          2
            3642      78324          5
                      78324         71
            2175      78324          1
           
大量會話被797這個SESSION柱塞

一般情況下，INSERT需要TM2，UPDATE/DELETE需要TM3，那麼能柱塞的一般是TM4及以上

SQL> select distinct chr(bitand(p1, -16777216) / 16777215) ||
  2                  chr(bitand(p1, 16711680) / 65535) lock_type,
  3                  mod(p1, 16) lock_mode,
  4                  sql_id,
  5                  session_id,
  6                  p2
  7    from v$active_session_history a
  8   where sample_time between to_date('20110602 1515', 'yyyymmdd hh24:mi') and
  9         to_date('20110602 1520', 'yyyymmdd hh24:mi')
 10     and event = 'enq: TM - contention'
 11     and mod(p1, 16) > 3
 12  ;
 
LOCK_TYPE  LOCK_MODE SQL_ID        SESSION_ID         P2
--------- ---------- ------------- ---------- ----------
TM                 4 57yrdsxqngs94        797      78324
TM                 4 57yrdsxqngs94       3179      78324

果然，797/3179這2個會話在請求預設TM4，其會柱塞其後請求TM2/3的INSERT/UPDATE/DELETE語句

SQL> SELECT  sql_text FROM v$sql WHERE sql_id='57yrdsxqngs94';
 
SQL_TEXT
--------------------------------------------------------------------------------
DELETE FROM crm.our_staff WHERE ROWID = :PLSQLDEV_ROWID

SQL> select owner,object_name from dba_objects where object_id=78324;
 
OWNER                          OBJECT_NAME
------------------------------ --------------------------------------------------------------------------------
SO                             BUSI_ORDER

檢查發現SO.BUSI_ORDER有指向crm.our_staff的外來鍵，而該外來鍵上沒有索引。
刪除父表crm.our_staff的資料導致了在子表SO.BUSI_ORDER上加TM4的鎖

雖然有的文章說9I以後ORACLE修改了演算法，不會在無索引的情況下，當父表資料修改時，在子表加TM4或者TM5
而且做實驗也沒模擬成功過

但是實際情況下，TM模式的死鎖，還是很常見，無論是9i還是10g
 

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

相關文章