原文链接自：Miladin Modrakovic’s Blog – Oraclue
实际上，昨天刚有朋友问怎么找到TX enqueu的锁对象以及语句。在Oracle11gR2中我们可以使用oradebug unit_test per_session_find_one_waiter语句来进行简单的blocker定位。
oradebug unit_test per_session_find_one_waiter的用法如下：
usage:
oradebug unit_test per_session_find_one_waiter
find_waiters_for=
wait_event=""
waiter_min_secs_blkd=
min_results=
[ timeout_mins= ]
实际测试如下，还是测试简单的enq: TX – row lock contention等待事件。
在第1个session中：
[sourcecode language=”sql”]SQL> create table t (n int primary key);
Table created.
SQL> insert into t values(1);
1 row created.
SQL> commit;
Commit complete.
SQL> update t set n=2 where n=1;
1 row updated.[/sourcecode]
在第2个session中：
[sourcecode language=”sql” light=”true”]SQL> update t set n=3 where n=1;[/sourcecode]
在第3个session中：
[sourcecode language=”sql” light=”true”]SQL> update t set n=4 where n=1;[/sourcecode]
在另外一个session中用sysdba登陆，然后执行oradebug。
[sourcecode language=”sql”]SQL> oradebug unit_test per_session_find_one_waiter find_waiters_for=all_local_sess wait_event="enq: TX – row lock contention" waiter_min_secs_blkd=1 min_results=1
WAITERS_FOUND_BEGIN
(inst=1, sid=16, osid=30658) is blocking (inst=1, sid=17) for at least 501 secs
(inst=1, sid=17, osid=30668) is blocking (inst=1, sid=25) for at least 486 secs
WAITERS_FOUND_END[/sourcecode]
从以上的输出中可以得知：
1. sid=16的会话锁住了sid=17的会话，已经有至少501秒
2. sid=17的会话锁住了sid=25的会话，已经有至少486秒
此时如果commit会话1，那么会话2和会话3的”enq: TX – row lock contention” 锁都会消失，但是两个会话都不会更新到任何记录，因为n=1的记录已经被会话1更新为n=2。
在目前的测试中，如果在oradebug中指定的wait_event在当前数据库中并不存在，那么oradebug命令将长时间没有反应，并最终报出ORA-00600的错误，这应该是bug，有望在今后的版本中得到修改。
[sourcecode language=”sql”]SQL> oradebug unit_test per_session_find_one_waiter find_waiters_for=current_sess wait_event="enq: TX – row lock contention" waiter_min_secs_blkd=1 min_results=1
ORA-00600: internal error code, arguments: [ksdhng:waiting_sessions_not_found], [enq: TX – row lock contention], [10], [10], [], [], [], [], [], [], [], [][/sourcecode]
