数据库死锁解决方法

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

先定位一下是哪个程序句柄导致的死锁。方法一、查看db2diag.log文件找到DeadLockorLocktimeout死锁或锁超时信息db2forceapplication(句柄ID)直接结束进程即可。方法二、DB2快照信息1、看一下DB2快照信息可以得到类似信息：数据库锁定快照数据库名称=SAMPLE数据库路径=D:\IBM\DB2\NODE0000\SQL00001\输入数据库别名=SAMPLE挂起的锁定=8当前已连接的应用程序=2当前正等待锁定的代理程序数=1应用程序句柄=54应用程序标识=*LOCAL.DB2.140304192925序号=00001应用程序名=db2bp.exeCONNECT授权标识=DB2ADMIN应用程序状态=锁定等待应用程序代码页=1208挂起的锁定=4总计等待时间（毫秒）=247867锁定列表锁定名称=0x5359534C564C3031DDECEF2841锁定属性=0x00000000发行版标志=0x40000000锁定计数=1挂起计数=0锁定对象名=2312对象类型=行表空间名=IBMDB2SAMPLEREL表模式=DB2ADMIN表名=TEST方式=IX查看锁定的详细信息：----（1728是句柄ID）3、观察命令db2listapplications的输出查看应用程序的状态是否有锁定等待(Lock-wait)状态出现。执行命令;4、db2forceapplication(句柄ID)直接结束进程即可。

2. 在数据库中解决死锁的常用方法有哪些

死锁主要表现以下几种情况：
表现一:
一个用户A 访问表A(锁住了表A),然后又访问表B
另一个用户B 访问表B(锁住了表B),然后企图访问表A
这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B,才能继续，好了他老人家就只好老老实实在这等了
同样用户B要等用户A释放表A才能继续这就死锁了
解决方法：
这种死锁是由于你的程序的BUG产生的，除了调整你的程序的逻辑别无他法
仔细分析你程序的逻辑，
1：尽量避免同时锁定两个资源
2: 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源.
表现二:
用户A读一条纪录，然后修改该条纪录
这是用户B修改该条纪录
这里用户A的事务里锁的性质由共享锁企图上升到独占锁(for update),而用户B里的独占锁由于A有共享锁存在所以必须等A释
放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。
这种死锁比较隐蔽，但其实在稍大点的项目中经常发生。
解决方法:
让用户A的事务（即先读后写类型的操作),在select 时就是用Update lock
语法如下：
select * from table1 with(updlock) where ....

如果真的table被锁住了，可以通过下面的方法来解锁：
Sql server企业管理器－>对应的数据库->管理->当前活动->锁/进程ID
将对应的被锁住的进程关闭。
还有一种方法，就是在你不知道究竟是哪张表被锁，由何种原因被锁，可以重新启动数据库来解决，但不保证下次又被锁住，因为还没有找到问题的根本原因。

要避免锁表，在操作数据库最好不要用独占方式。

3. 多个程序访问一个数据库出现死锁，怎么处理

多个程序访问一个数据库出现死锁，你可以这么处理：
增加电脑整体性能配置，主板、网络、CPU/内存、电源都要好一些；
一些不是很重要的、可以设置延迟连接；
定时对数据库进行维护，优化；
程序也需要维护稳定，管理员工对程序的使用效率。

4. 数据库死锁的死锁原因

一般情况只发生锁超时，就是一个进程需要访问数据库表或者字段的时候，另外一个程序正在执行带锁的访问（比如修改数据），那么这个进程就会等待，当等了很久锁还没有解除的话就会锁超时，报告一个系统错误，拒绝执行相应的SQL操作。
发生死锁的情况比较少，比如一个进程需要访问两个资源（数据库表或者字段），当获取一个资源的时候进程就对它执行锁定，然后等待下一个资源空闲，这时候如果另外一个进程也需要两个资源，而已经获得并锁定了第二个资源，那么就会死锁，因为当前进程锁定第一个资源等待第二个资源，而另外一个进程锁定了第二个资源等待第一个资源，两个进程都永远得不到满足。
数据库死锁的解决方案。
死锁的预防和解除：
理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态的情况下占用资源,在系统运行过程中，对进程发出的每一个系统能够满足的资源申请进行动态检查，并根据检查结果决定是否分配资源，若分配后系统可能发生死锁，则不予分配，否则予以分配 。因此，对资源的分配要给予合理的规划。
如何将死锁减至最少
虽然不能完全避免死锁，但可以使死锁的数量减至最少。将死锁减至最少可以增加事务的吞吐量并减少系统开销，因为只有很少的事务回滚，而回滚会取消事务执行的所有工作。由于死锁时回滚而由应用程序重新提交。
下列方法有助于最大限度地降低死锁：
（1）按同一顺序访问对象。
（2）避免事务中的用户交互。
（3）保持事务简短并在一个批处理中。
（4）使用低隔离级别。
（5）使用绑定连接。
按同一顺序访问对象
如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。
避免事务中的用户交互
避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
保持事务简短并在一个批处理中
在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。
保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。
使用低隔离级别
确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
使用绑定连接
使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。

5. 数据库中死锁是什么产生的

数据库操作的死锁是不可避免的，本文并不打算讨论死锁如何产生，重点在于解决死锁，通过SQL
Server
2005,
现在似乎有了一种新的解决办法。
将下面的SQL语句放在两个不同的连接里面，并且在5秒内同时执行，将会发生死锁。
use
Northwind
begin
tran
insert
into
Orders(CustomerId)
values(@#ALFKI@#)
waitfor
delay
@#00:00:05@#
select
*
from
Orders
where
CustomerId
=
@#ALFKI@#
commit
print
@#end
tran@#
SQL
Server对付死锁的办法是牺牲掉其中的一个，抛出异常，并且回滚事务。在SQL
Server
2000，语句一旦发生异常，T-SQL将不会继续运行，上面被牺牲的连接中，
print
@#end
tran@#语句将不会被运行，所以我们很难在SQL
Server
2000的T-SQL中对死锁进行进一步的处理。
现在不同了，SQL
Server
2005可以在T-SQL中对异常进行捕获，这样就给我们提供了一条处理死锁的途径：
下面利用的try
...
catch来解决死锁。
SET
XACT_ABORT
ON
declare
@r
int
set
@r
=
1
while
@r
<=
3
begin
begin
tran
begin
try
insert
into
Orders(CustomerId)
values(@#ALFKI@#)
waitfor
delay
@#00:00:05@#
select
*
from
Orders
where
CustomerId
=
@#ALFKI@#
commit
break
end
try
begin
catch
rollback
waitfor
delay
@#00:00:03@#
set
@r
=
@r
+
1
continue
end
catch
end
解决方法当然就是重试，但捕获错误是前提。rollback后面的waitfor不可少，发生冲突后需要等待一段时间，@retry数目可以调整以应付不同的要求。
但是现在又面临一个新的问题:
错误被掩盖了，一但问题发生并且超过3次，异常却不会被抛出。SQL
Server
2005
有一个RaiseError语句，可以抛出异常，但却不能直接抛出原来的异常，所以需要重新定义发生的错误，现在，解决方案变成了这样:
declare
@r
int
set
@r
=
1
while
@r
<=
3
begin
begin
tran
begin
try
insert
into
Orders(CustomerId)
values(@#ALFKI@#)
waitfor
delay
@#00:00:05@#
select
*
from
Orders
where
CustomerId
=
@#ALFKI@#
commit
break
end
try
begin
catch
rollback
waitfor
delay
@#00:00:03@#
set
@r
=
@r
+
1
continue
end
catch
end
if
ERROR_NUMBER()
<>
0
begin
declare
@ErrorMessage
nvarchar(4000);
declare
@ErrorSeverity
int;
declare
@ErrorState
int;
select
@ErrorMessage
=
ERROR_MESSAGE(),
@ErrorSeverity
=
ERROR_SEVERITY(),
@ErrorState
=
ERROR_STATE();
raiserror
(@ErrorMessage,

@ErrorSeverity,

@ErrorState

);
end

6. 数据库死锁怎么产生，怎样能解决

数据库操作的死锁是不可避免的，本文并不打算讨论死锁如何产生，重点在于解决死锁，通过SQL Server 2005, 现在似乎有了一种新的解决办法。

将下面的SQL语句放在两个不同的连接里面，并且在5秒内同时执行，将会发生死锁。

use Northwind
begin tran
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
print @#end tran@#

SQL Server对付死锁的办法是牺牲掉其中的一个，抛出异常，并且回滚事务。在SQL Server 2000，语句一旦发生异常，T-SQL将不会继续运行，上面被牺牲的连接中， print @#end tran@#语句将不会被运行，所以我们很难在SQL Server 2000的T-SQL中对死锁进行进一步的处理。

现在不同了，SQL Server 2005可以在T-SQL中对异常进行捕获，这样就给我们提供了一条处理死锁的途径：

下面利用的try ... catch来解决死锁。

SET XACT_ABORT ON
declare @r int
set @r = 1
while @r <= 3
begin
begin tran

begin try
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#

commit
break
end try

begin catch
rollback
waitfor delay @#00:00:03@#
set @r = @r + 1
continue
end catch
end

解决方法当然就是重试，但捕获错误是前提。rollback后面的waitfor不可少，发生冲突后需要等待一段时间，@retry数目可以调整以应付不同的要求。

但是现在又面临一个新的问题: 错误被掩盖了，一但问题发生并且超过3次，异常却不会被抛出。SQL Server 2005 有一个RaiseError语句，可以抛出异常，但却不能直接抛出原来的异常，所以需要重新定义发生的错误，现在，解决方案变成了这样:

declare @r int
set @r = 1
while @r <= 3
begin
begin tran

begin try
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#

commit
break
end try

begin catch
rollback
waitfor delay @#00:00:03@#
set @r = @r + 1
continue
end catch
end
if ERROR_NUMBER() <> 0
begin
declare @ErrorMessage nvarchar(4000);
declare @ErrorSeverity int;
declare @ErrorState int;
select
@ErrorMessage = ERROR_MESSAGE(),
@ErrorSeverity = ERROR_SEVERITY(),
@ErrorState = ERROR_STATE();
raiserror (@ErrorMessage,
@ErrorSeverity,
@ErrorState
);
end

我希望将来SQL Server 2005能够直接抛出原有异常，比如提供一个无参数的RaiseError。

因此方案有点臃肿，但将死锁问题封装到T-SQL中有助于明确职责，提高高层系统的清晰度。现在，对于DataAccess的代码，或许再也不需要考虑死锁问题了。

7. 数据库中解决死锁的常用方法有什么

1、要求每个事务一次就将所有要使用的数据全部加锁,否则不能执行。
2、采用按序加锁法.预先规定一个封锁顺序,所有的事务都必须按这个顺序对数据执行封锁。
3、不采取任何措施来预防死锁的发生,而是周期性地检查系统中是否有死锁.如果发现死锁就设法解除。