DB2数据库发生死锁了怎么办

先定位一下是哪个程序句柄导致的死锁。

方法一、查看db2diaglog文件

找到DeadLock or Lock timeout 死锁或锁超时信息

db2 force application(句柄ID)

直接结束进程即可。

方法二、DB2快照信息

1、看一下DB2快照信息

db2 get snapshot for locks on sample

可以得到类似信息：

数据库锁定快照

数据库名称 = SAMPLE

数据库路径 = D:\IBM\DB2\NODE0000\SQL00001\

输入数据库别名 = SAMPLE

挂起的锁定 = 8

当前已连接的应用程序 = 2

当前正等待锁定的代理程序数 = 1

应用程序句柄 = 54

应用程序标识 = LOCALDB2140304192925

序号 = 00001

应用程序名 = db2bpexe CONNECT

授权标识 = DB2ADMIN

应用程序状态 = 锁定等待

应用程序代码页 = 1208

挂起的锁定 = 4

总计等待时间（毫秒） = 247867

锁定列表

锁定名称 = 0x5359534C564C3031DDECEF2841

锁定属性 = 0x00000000

发行版标志 = 0x40000000

锁定计数 = 1

挂起计数 = 0

锁定对象名 = 2312

对象类型 = 行

表空间名 = IBMDB2SAMPLEREL

表模式 = DB2ADMIN

表名 = TEST

方式 = IX

查看锁定的详细信息：db2 get snapshot for locks for application agentid 1728

----（1728是句柄ID）

3、观察命令db2 list applications的输出

查看应用程序的状态是否有锁定等待(Lock-wait)状态出现。

执行命令 list applications for db sample show detail;

4、db2 force application(句柄ID)

直接结束进程即可。

如果两个用户进程分别锁定了不同的资源，接着又试图锁定对方所锁定的资源，就会产生死锁。此时，SQL Server将自动地选择并中止其中一个进程以解除死锁，使得另外一个进程能够继续处理。系统将回退被中止的事务，并向被回退事务的用户发送错误信息。

大多数设计良好的应用都会在接收到这个错误信息之后重新提交该事务，此时提交成功的可能性是很大的。但是，如果服务器上经常出现这种情况，就会显著地降低服务器性能。为避免死锁，设计应用应当遵循一定的原则，包括:

◆让应用每次都以相同的次序访问服务器资源。

◆在事务期间禁止任何用户输入。应当在事务开始之前收集用户输入。

◆尽量保持事务的短小和简单。

◆如合适的话，为运行事务的用户连接指定尽可能低的隔离级别。[适用于65，70，2000]

此外，对于SQL Server的死锁问题，下面是几则实践中很有用的小技巧。

◆使用SQL Server Profiler的Create Trace Wizard运行“Identify The Cause of a Deadlock”跟踪来辅助识别死锁问题，它将提供帮助查找数据库产生死锁原因的原始数据。[适用于70，2000]

◆如果无法消除应用中的所有死锁，请确保提供了这样一种程序逻辑:它能够在死锁出现并中止用户事务之后，以随机的时间间隔自动重新提交事务。这里等待时间的随机性非常重要，这是因为另一个竞争的事务也可能在等待，我们不应该让两个竞争的事务等待同样的时间，然后再在同一时间执行它们，这样的话将导致新的死锁。[适用于65，70，2000]

◆尽可能地简化所有T-SQL事务。此举将减少各种类型的锁的数量，有助于提高SQL Server应用的整体性能。如果可能的话，应将较复杂的事务分割成多个较简单的事务。[适用于65，70，2000]

◆所有条件逻辑、变量赋值以及其他相关的预备设置 *** 作应当在事务之外完成，而不应该放到事务之内。永远不要为了接受用户输入而暂停某个事务，用户输入应当总是在事务之外完成。[适用于65，70，2000]

◆在存储过程内封装所有事务，包括BEGIN TRANSACTION和COMMIT TRANSACTION语句。此举从两个方面帮助减少阻塞的锁。首先，它限制了事务运行时客户程序和SQL Server之间的通信，从而使得两者之间的任何消息只能出现于非事务运行时间(减少了事务运行的时间)。其次，由于存储过程强制它所启动的事务或者完成、或者中止，从而防止了用户留下未完成的事务(留下未撤销的锁)。[适用于65，70，2000]

◆如果客户程序需要先用一定的时间检查数据，然后可能更新数据，也可能不更新数据，那么不要在整个记录检查期间都锁定记录。假设大部分时间都是检查数据而不是更新数据，那么处理这种特殊情况的一种方法就是:先选择出记录(不加UPDATE子句。UPDATE子句将在记录上加上共享锁)，然后把它发送给客户。

如果用户只查看记录但从来不更新它，程序可以什么也不做;反过来，如果用户决定更新某个记录，那么他可以通过一个WHERE子句检查当前的数据是否和以前提取的数据相同，然后执行UPDATE。

类似地，我们还可以检查记录中的时间标识列(如果它存在的话)。如果数据相同，则执行UPDATE *** 作;如果记录已经改变，则应用应该提示用户以便用户决定如何处理。虽然这种方法需要编写更多的代码，但它能够减少加锁时间和次数，提高应用的整体性能。[适用于65，70，2000]

◆尽可能地为用户连接指定具有最少限制的事务隔离级别，而不是总是使用默认的READ COMMITTED。为了避免由此产生任何其他问题，应当参考不同隔离级别将产生的效果，仔细地分析事务的特性。[适用于65，70，2000]

◆使用游标会降低并发性。为避免这一点，如果可以使用只读的游标则应该使用READ_ONLY游标选项，否则如果需要进行更新，尝试使用OPTIMISTIC游标选项以减少加锁。设法避免使用SCROLL_LOCKS游标选项，该选项会增加由于记录锁定引起的问题。[适用于65，70，2000]

◆如果用户抱怨说他们不得不等待系统完成事务，则应当检查服务器上的资源锁定是否是导致该问题的原因。进行此类检查时可以使用SQL Server Locks Object: Average Wait Time (ms)，用该计数器来度量各种锁的平均等待时间。

如果可以确定一种或几种类型的锁导致了事务延迟，就可以进一步探究是否可以确定具体是哪个事务产生了这种锁。Profiler是进行这类具体分析的工具。[适用于70，2000]

◆使用sp_who和sp_who2(SQL Server Books Online没有关于sp_who2的说明，但sp_who2提供了比sp_who更详细的信息)来确定可能是哪些用户阻塞了其他用户。[适用于65，70，2000]

◆试试下面的一个或多个有助于避免阻塞锁的建议:1)对于频繁使用的表使用集簇化的索引;2)设法避免一次性影响大量记录的T-SQL语句，特别是INSERT和UPDATE语句;3)设法让UPDATE和DELETE语句使用索引;4)使用嵌套事务时，避免提交和回退冲突。[适用于65，70，2000]

每个使用关系型数据库的程序都可能遇到数据死锁

的情况。理解什么是死锁之前先要了解锁定的概念：

多数情况下，可以认为如果一个资源被锁定，它总会在以后某个时间被释放。而死锁发生在当多个进程访问同一数据库时，其中每个进程拥有的锁都是其他进程所需的，由此造成每个进程都无法继续下去。简单的说，进程A等待进程B释放他的资源，B又等待A释放他的资源，这样就互相等待就形成死锁。

多线程是很容易造成死锁，一般情况下死锁都是因为并发 *** 作引起的。我不懂JAVA,但死锁这个问题每种开发工具和数据库都会碰到解决办法是：

1、程序方面优化算法（如有序资源分配法、银行算法等），在一个程序里，能不用多线程更新同一张数据库表

尽量不要用，如果要用，其避免死锁的算法就很复杂。

2、数据库方面设置等待超时时间

3、发生死锁后直接KILL掉数据库进程

以上就是关于DB2数据库发生死锁了怎么办全部的内容，包括:DB2数据库发生死锁了怎么办、减少SQLServer数据库死锁的方法、数据库死锁的基本解释等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！