一直不提交也不回滚，所以这个事务影响的记录就会出于加锁状态，从而导致后来的事务需要操作相同记录的就会出现一个锁等待事件，为了确定是哪个SESSION BLOCK其他事务，于是根据锁等待时间最长的SESSION的SID去V$SESSION视图中查找BLOCKING_SESSION的值，得到是谁BLOCK了这个SESSION，以便找到问题的根源，然后奇怪的问题发生了，找到的这个BLOCKING_SESSION的值去V$LOCK中查找，却发现这个session根本没有LOCK任何资源，而且，把这个SESSION杀掉之后，原先被BLOCK的SESSION还是处于BLOCK的状态，看来是杀错SESSION了。
感觉不可思议，ORACLE BUG碰见的多，碰见这种鬼问题首先想到的就是METALINK了，查了下，果然是个BUG，看看上面是怎么说的吧。

Bug 5481650 GV$SESSION.blocking_session has incorrect value
This note gives a brief overview of bug 5481650.
Affects:
Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions < 11
Versions confirmed as being affected 10.2.0.3

Platforms affected Generic (all / most platforms affected)
Fixed:
This issue is fixed in 10.2.0.4 (Server Patch Set)
Symptoms: Related To:
Wrong Results
(None Specified)
GV$SESSION
V$SESSION
Description
If "Blocker" and "Waiter" are on the same instance then "blocking_session"
in "GV$SESSION" is shown exactly 1 greater than the actual SID.

跟我碰见的一摸一样，每次都是实际显示的BLOCKING_SESSION比真正的BLOCKING_SESSION都大一个。
这个问题可以通过打PATCH来解决，因为没有太多影响，暂时也不想动