program:
last wait for 'enq: TX - row lock contention' wait_time=2.929926 sec, seconds since wait started=3
name|mode=54580006, usn<<16 | slot=56002b, sequence=33647
blocking sess=0x700000ccf400390 seq=49119
可知获得了很多信息啊，一看就懂了，不在说明。其中 blocking sess=0x700000ccf400390 seq=49119是关键信息，另外还有enq: TX - row lock contention，
在谈enq: TX - row lock contention：
简单介绍三种情况：
Waits for TX in mode 4 can also occur if a session is waiting due to potential duplicates in UNIQUE index. If two sessions try to insert the same key value the second session has to wait to see if an ORA-0001 should be raised or not. This type of TX enqueue wait corresponds to the wait event enq: TX - row lock contention.
The solution is to have the first session holding the lock perform a COMMIT or ROLLBACK.
Waits for TX in mode 6: occurs when a session is waiting for a row level lock that is held by another session. This occurs when one user is updating or deleting a row, which another session wants to update or delete. This type of TX enqueue wait corresponds to the wait event enq: TX - row lock contention.
The solution is to have the first session holding the lock perform a COMMIT or ROLLBACK.
Waits for TX in mode 4 is also possible if the session is waiting due to shared bitmap index fragment. Bitmap indexes index key values and a range of rowids. Each entry in a bitmap index can cover many rows in the actual table. If two sessions want to update rows covered by the same bitmap index fragment, then the second session waits for the first transaction to either COMMIT or ROLLBACK by waiting for the TX lock in mode 4. This type of TX enqueue wait corresponds to the wait event enq: TX - row lock contention.
那具体属于那种呢？还行进一步分析。（如果对问题处理有经验了，目前已经知道了问题所在了。呵呵）
继续看：
在采样中如下：
The history is displayed in reverse chronological order.
sample interval: 1 sec, max history 120 sec
---------------------------------------------------
[3 samples, 10:00:17 - 10:00:19]
waited for 'enq: TX - row lock contention', seq_num: 49119
p1: 'name|mode'=0x54580006
p2: 'usn<<16 | slot'=0x56002b
p3: 'sequence'=0x33647
[4 samples, 10:00:13 - 10:00:16]
waited for 'enq: TX - row lock contention', seq_num: 49116
p1: 'name|mode'=0x54580006
p2: 'usn<<16 | slot'=0x5e000c
p3: 'sequence'=0x344b1
time_waited: 0.778215 sec (sample interval: 3 sec)
可以看到该会话依然在等待
p2: 'usn<<16 | slot'=0x56002b
p3: 'sequence'=0x33647
time_waited: >= 2 sec (still in wait)
至此通过slot可以看到对应了开始的TX-0056002b-00033647 这是问题关键。那是什么导致的呢？
继续看：
下面就是library cache 的内容了。其pin有三种模式分别是N，s，X，那么我们关注后面两个：
LIBRARY OBJECT LOCK: lock=700000c98ff6210 handle=700000cd6e943b8 mode=N
call pin=0 session pin=0 hpc=0000 hlc=0000
htl=700000c98ff6290[700000ae75279e8,700000c430397a0] htb=700000ae75279e8 ssga=700000ae7526aa0
user=700000cd047d060 session=700000cd047d060 count=1 flags=[0000] savepoint=0x5330e331
LIBRARY OBJECT HANDLE: handle=700000cd6e943b8 mtx=700000cd6e944e8(4) lct=379499 pct=1 cdp=4
name=
update T_CONTRACT_CONTENT set classify=:1,classifyName=:2, TemplateID=:3, NAME=:4,bidType=:5, CONJUNCTION=:6,FrameWorkMode=:7, DEGREE=:8, PRIORITY=:9,PRECONDITION=:10, Cnt=:11, Comments=:12, Mobile=:13,UpdateTime=sysdate, professionalType=:14, REQUIRENAME=:15, phone=:16,fixedAmount=:17,SIGNDEPTNAME=:18, BIDQUALIFITIONEXP = :19, ISREADY = :20, signer=:21,overView=:22, SelectModel = :23,PaymentType = :24, IsBudget = :25,IsBeforehand = :26, PerformProperty =:27,PerformTimeLimit=:28,
hash=39b51e91e5a0ae1f78856df46eab74e3 timestamp=02-13-2014 22:16:32
namespace=CRSR fl