如何查看数据库的锁等待

如何查看数据库的锁等待

这个说明中，涉及的所有操作均需要数据库实例用户。且所获取的信息，与数据库实例的监控器设置有密切的联系，因此不同的环境看到的信息可能存在差异。

图一：

图一说明：

db2 list applications show detail| more

列出目前所有连接到数据库（实例中的所有数据库，执行这个命令无需连接数据库）中的应用连接，即都有哪些人，在做些什么。

特别需要关注的几列：

1.连接到数据库的用户

2.目前连接的状态，除了图中所示，常见的还有UOW Executing，Lock-wait，Rollback 等

3.所连接的数据库名

4.连接的Handle，通过这个Handle，我们可以获得每个连接的具体信息。

图二：

图二说明：

这里就是一个处于锁等待（Lock-wait）连接。下面我们通过它的Handle（5594）来获取它的具体信息。

图三：

图三说明：

db2 get snapshot for application agentid 5594| more

这个命令是对Handle （5594）做一个快照（snapshot）。

第一处标注：Application name和Application ID在一些客户端连接过来的时候，能获取到具体的客户端的信息，这里的Application name=db2bp一般指就在服务器本地提交的命令。第二处标注：是具体执行的sql，如果这个连接并不是执行sql，而是一些数据库的命令，则未必能获取。

第三处标注：这个连接提交到数据库的时间，通常可以根据这个来判断你的具体应用执行了多长时间。

图四：

图四说明：

图四跟图三是同一个命令的结果。

db2 get snapshot for application agentid 5594| more

因此所输出的信息量较大，中间省略了一些信息。

在图四，我们可以看到到Handle 5594 它为什么会处于锁等待。

因为Handle 5594 需要等待5593.

5593 目前的Lock mode: X 排他锁

5594 需要的Lock mode requested：X 排他锁

X排他锁是不兼容的，因此，5594必须要等待5593释放X锁，因此5594就形成了Lock wait 的状态。

图五：

图五说明：

我们继续使用之前发办法，对5593进行一个snapshot，以获取5593的具体信息。这里，我们发现5593也是出于Lock-wait的状态，即5593 也需要等待其他的锁。

图六：

图六说明：

图六是图五是同一个命令的结果。上文已有说明。

在这里，我们可以知道Handle 5593 需要等待Handle 5552所持有的锁。

5552的

Lock object type = Table锁类型是Table表锁

Lock mode = Super Exclusive Lock (Z)超级排他锁，比X锁还要狠。一般是load 命令造成。

Schema of table holding lock = SDATA表的schema是SDATA

Name of table holding lock = DTL_NB_ACCT_SIGN_INFO表名。

图七：

图七说明：

这里可以看到Handle5552的状态是UOW Executing，正在执行中。。。

具体执行的sql，执行的时间也能看到，上文已有说明。

图八：

图八也是图七输出结果的一部分。

图中我们能看到Handle 5552具体执行的sql ，如果这个连接不是执行sql语句，则这个信息看不到。

总结：

通常，当我们发现某个应用提交了之后，没反应，我们就可以发出：

db2 list applications show detail

来看看目前的所有连接的状态，可以通过连接时的用户名，提交的大概时间来判断哪个handle是你所关注的。

如果发现我们的连接提交之后，是Lock wait的状态，就可以按照上述的方式，顺藤摸瓜来进行检查，当找到最终导致Lock wait的handle 时，可以根据具体的情况来处理。

1.继续等待其他应用连接释放锁（等别人执行完）

2.停掉处于锁等待的应用连接（算了，不跑了）（db2 “force applications(handle id)”）

3.停掉目前hold住锁的应用连接（我先跑，你别跑了）（db2 “force applications(handle id)”）。

当要停掉一些正在执行（UOW Executing）时，务必谨慎，例如一个表正在load 数据，如果被force 掉的话，它的状态可能会异常。