等待事件--enq:TX - row lock contention
enq是一種保護共享資源的鎖定機制﹐一個排隊機制﹐先進先出(FIFO)
發生TX鎖的原因一般有几個

1.不同的session更新或刪除同一個記錄

2.唯一索引有重復索引

3.位圖索引多次更新

4.同時對同一個數據塊更新

5.等待索引塊分裂

排查方式
1.定位wait event

select sql_id,sql_hash_value from gv$session where event='enq: TX - row lock contention';

SELECT l.* FROM gv$lock l,gv$session s WHERE l.sid=s.sid AND s.event='enq: TX - row lock contention' and l.type='TX' and l.inst_id=s.inst_id;

select sid,username,event from v$session where state in('WAITING') and wait_class!='Idle';

2.定位某個程序

SELECT   ss.sid,
         ss.serial#,
         ss.machine,
         ss.osuser,
         ss.terminal,
         ss.program,
         sa.sql_text
  FROM   v$sqlarea sa, v$session ss
 WHERE   ss.sql_address = sa.address
         AND sid IN (SELECT   sid
                       FROM   v$session
                      WHERE   program = 'DCCS.exe')

3.定位SQL對應的SP

SELECT   DISTINCT owner,
                  name,
                  TYPE,
                  text
  FROM   dba_source
 WHERE   TYPE IN ('PACKAGE', 'PROCEDURE', 'FUNCTION', 'TRIGGER')
         AND UPPER (text) LIKE '%UPDATE SFISM4.R_MO_BASE_T%'

結論﹕
結合AWR報告﹐協調開發﹐初步診斷如下﹕
A. DCCS.exe 與 ChangeSN.exe 頻繁 update 同一對象 Table:SFISM4.R_MO_BASE_T

   DCCS.exe: UPDATE SFISM4.R_MO_BASE_T SET INPUT_QTY=INPUT_QTY+1 WHERE MO_NUMBER = :B1
   ChangeSN.exe: UPDATE SFISM4.R_MO_BASE_T SET OUTPUT_QTY = OUTPUT_QTY + 1 WHERE                  MO_NUMBER = :B1

   DCCS 調用 SP ﹕SFIS1.UPDATE_R105
   ChangeSN.exe 調用 SP ﹕SFIS1.SP_INSERT_LINK_DATA(4/7上線)

B. ChangeSN.exe 為多連板處理程序﹐需多次調用 SP ﹕SFIS1.SP_INSERT_LINK_DATA整合事務作     統一commit, 這樣會造成由于某個小板事務未完成而無法commit, 該事務將

無法釋放對   Table:SFISM4.R_MO_BASE_T 持有的lock,DCCS.exe 運行需等待ChangeSN.exe 釋放對   Table:SFISM4.R_MO_BASE_T 占有的資源﹐長時間等待將導致CMC掃描無反應

C. 協調開發作如下處理﹕
   1. 切分SFIS1.SP_INSERT_LINK_DATA中的事務處理﹐將大事務分成几個小事務﹐強制加入     commit,﹐每個事務完成后作自動提交,這樣不會因為某個小板事務未完成而無法

commit,(已完成)
   2.  開發目前正在Check ChangeSN.exe ,發現沒有作自動提交的動作﹐待完全確認后會進行改善(進行中)

注﹕每次出現問題后﹐值班人員會重啟DCCS.exe,導致相關的session消失﹐DBA排查時無法定位﹐建議出現問題后及時聯系DBA處理