db2 V9.1 死锁答案

【问题标题】：db2 V9.1 deadlocksdb2 V9.1 死锁
【发布时间】：2014-12-12 15:16:51
【问题描述】：

我的应用程序中有 4 个不同的服务，SELECT 和 UPDATE 在 AIX 6.1 上我的数据库 (db2 v9.1) 的同一张表上，而不是大约 300,000 条记录的大表。这 4 项服务并行执行方式，并且每个服务以顺序方式执行（非并行）。每天我都面临可怕的死锁问题，数据库挂起大约 5 到 10 分钟，然后恢复正常性能。我的服务以一种使它们永远不会在同一行上SELECT 或UPDATE 的方式同步，所以我相信即使发生死锁，它也应该在行级别而不是表级别，对吧？此外，在我的SELECT 查询中，我使用"ONLY FOR FETCH WITH UR"，在db2 v9.1 中，这意味着不将行锁定为仅用于读取目的，并且不会有更新（UR = 未提交的读取）。关于发生了什么以及为什么发生的任何想法？

【问题讨论】：

WITH UR not 是否意味着您的 SELECT 语句不会持有锁！ WITH UR 表示你愿意通读其他事务的锁。
@IanBjorhovde -- 实际上，UR 隔离级别确实意味着 SELECT 无论如何都不会锁定数据。
好吧，那为什么锁等待要花那么多时间呢？这是正常的行为，没有考虑到我的应用程序中的所有查询都不会同时读取或更新同一行？
事情是这样的：我注意到问题发生时几乎是同时发生的。例如 01:02 到 01:07、03:03 到 03:08 等等。有线但真实。此外，我们检查了该服务器上是否有任何计划作业或任何监控作业，但实际上我们一无所获。

标签： sql db2 odbc deadlock

【解决方案1】：

首先，这些肯定不是死锁：DB2 会在几秒钟内通过回滚其中一个冲突事务来解决死锁。您遇到的很可能是锁定等待。

至于发生了什么，您需要在锁定发生时对其进行监控。您可以使用 db2pd 实用程序，例如

db2pd -d mydb -locks showlocks

或

db2pd -d mydb -locks wait

您也可以使用快照监视器：

db2 update monitor switches using statement on lock on
db2 get snapshot for locks on mydb

或快照视图：

select * from sysibmadm.locks_held
select * from sysibmadm.lockwaits

【讨论】：

好吧，那为什么锁等待要花那么多时间呢？这是正常的行为，没有考虑到我的应用程序中的所有查询都不会同时读取或更新同一行？
事情是这样的：我注意到问题发生时几乎是同时发生的。例如 01:02 到 01:07、03:03 到 03:08 等等。有线但真实。此外，我们检查了该服务器上是否有任何计划作业或任何监控作业，但实际上我们什么也没找到。
我建议的方法应该可以回答你所有的问题。
谢谢，还有一个问题：如果我更改了数据库级别的 LOCKTIMEOUT 属性，它会起作用吗？
将 LOCKTIMEOUT 更改为更少，比如 60 秒。它会使锁过期吗？对吗？