原文链接自：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]