分析结果很简单，也很容易看懂。分析重点是从process入手，将当前系统中所有对应的Process信息逐个整理出来，将对应的等待事件wait event理出来。最后，将存在Block的情况整理列出来。
从上面的结果看，可以发现资源Enqueue TX-00060002-00000611被26号会话持有，该会话却处在等待用户信息输入状态。而上面的Process列表中，对于这个资源27号进程是等待持有的。
那么，我们直到了26和27直接有问题，如何定位究竟哪个会话呢？注意：这个26和27对应的就是v$process中数据库内部的进程编号PID。
SQL> select * from v$process where pid in (26,27);
ADDR PID SPID
---------------- ---------- ------------------------
00000001339FDBD0 26 7505
00000001339FEC88 27 8317
SQL> select sid, serial#, paddr, event from v$session where paddr in ('00000001339FDBD0','00000001339FEC88');
SID SERIAL# PADDR EVENT
---------- ---------- ---------------- ----------------------------------------------------------------
319 21 00000001339FDBD0 SQL*Net message from client
479 43 00000001339FEC88 enq: TX - row lock contention
正确定位到319和479会话。
3、结论
数据库资源相互锁定在应用领域非常常见，例如资源释放问题、会话操作失误和事务回滚等，都会引起或大或小的资源锁定。通过awk命令配合ass109.awk命令文件，可以比较方便的让我们快速定位问题，解决问题。