在我之前的文章中，曾经分析过产生TX锁的几种情况。但是，在发现TX锁时，我们如何鉴别是哪一种情况导致的呢？当存在TX等待队列时，如何找到锁所在的对象呢？

记录锁

这类锁是事务插入/删除/更新数据记录时加在记录的锁。对于插入操作，数据在未提交之前对其他事务是“不可见”的，因而不会导致TX等待。这一类的TX锁是比较容易鉴别的——只有这类锁的模式（mode）是6（即排它锁，exclusive）。通过v$lock很容易鉴定出来：

可以看到，Lock Mode为6.

等待队列分析

当发现系统中由于此类锁导致的等待而致使会话hung住时，可以通过以下过程来找到导致阻塞的会话、语句和对象。

续上，在Session 2中执行：

此时，锁等待队列形成。从V$ENQUEUE_LOCK中可以查询到这一锁队列：

注意：V$ENQUEUE_LOCK的结构与V$LOCK结构很相似，但是，V$LOCK查询到的是被持有的锁及其SID，V$ENQUEUE_LOCK查询到的导致队列等待的锁以及请求锁的SID。

同时，通过v$session_event可以查询到会话等待事件是"enq: TX - row lock contention":

这一类锁是代码逻辑造成的——第一个获取锁的事务没有提交或回滚，导致其他会话等待。因此，找到逻辑代码是解决此类锁等待的关键。对于等待事务，由于其语句被锁阻塞住，因此从V$SESSION中得到的SQL信息就是其当前正在执行的语句，也就是发生等待的语句：

对于持有锁的会话，由于其在申请到锁资源后还可能会执行其他语句，因此不能通过v$session直接查询到发生锁的语句，而需要通过v$open_cursor来找到该语句：

这一查询结果可能会存在多条记录，那我们就需要结合等待会话的语句，从逻辑上分析是哪一条语句产生的锁。

除了语句，我们还可以通过会话信息中找到发生等待的具体数据记录：

通过得到的rowid，可以查询到具体记录：

死锁分析

对于此类锁所引发的死锁问题，通过Trace文件可以很快定位出来。首先，我们可以通过锁的请求、持有模式（x）可以知道这是行级锁：

同时，我们还可以找到导致死锁的语句、执行语句的用户、客户端及模块信息：

此外，还能知道锁所在的对象和数据记录（ROWID）：

然后再通过以上语句及会话的其它信息，找到相应代码，结合数据对象及产生锁的记录分析逻辑过程，修正会导致死锁的代码。

解决方法

要解决等待会话被“僵死”的问题，关键要看导致阻塞的会话正在做什么、或者正在等待什么，找到其事务长时间不提交的根本原因：

根本解决方法就是要调整应用逻辑，避免死锁。

例如，我们有一个案例：一个应用是多线程服务的，当收到请求事件后，服务进程会打开一个游标，对游标中数据逐一进行业务处理、统一更新。由于不同进程打开游标的时间不同，游标查询语句获取的数据顺序也会不同，因此这个应用经常抛出死锁错误。我们给出的解决方案就是在游标查询语句中加入排序，使更新数据按某一特定顺序进行，从而避免死锁。