怎么查看数据库死锁,和解决方法(查询数据库死锁语句)

execsp_lock快捷键C_2

execsp_whoactiveexecsp_who快捷键C_1

用Profiler里面的Locks->Deadlockgraph监控看看，如果看到了死锁图，就可以比较形象地展现死锁发生的过程，还可以看到锁的具体类型和过程里面的语句，对你诊断会有帮助。

Declare@LockTabtable(spidint,dbidint,ObjIdint,IndIdint,Typevarchar(50),Resourcevarchar(50),Modevarchar(50),Statusvarchar(50))

insertinto@LockTabexecsp_lock

Declare@ActiveTabtable(spidint,ecidint,statusvarchar(50),loginnamevarchar(50),hostnamevarchar(50),blkint,dbnamevarchar(50),cmdvarchar(50),request_idint)

insertinto@ActiveTabexecsp_whoactive

selectfrom@LockTablt

leftjoin@ActiveTabatonltspid=atspid

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

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

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

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

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

如果两个用户进程分别锁定了不同的资源，接着又试图锁定对方所锁定的资源，就会产生死锁。此时，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]

SQL Server死锁使我们经常遇到的问题 下面就为您介绍如何查询SQL Server死锁 希望对您学习SQL Server死锁方面能有所帮助

SQL Server死锁的查询方法

exec master dbo p_lockinfo 显示死锁的进程 不显示正常的进程

exec master dbo p_lockinfo 杀死死锁的进程 不显示正常的进程

SQL Server死锁的解除方法

Create proc p_lockinfo

@kill_lock_spid bit= 是否杀掉死锁的进程 杀掉 仅显示

@show_spid_if_nolock bit= 如果没有死锁的进程 是否显示正常进程信息 显示 不显示

as

declare @count int @s nvarchar（ ） @i int

select id=identity（int ） 标志

进程ID=spid 线程ID=kpid 块进程ID=blocked 数据库ID=dbid

数据库名=db_name（dbid） 用户ID=uid 用户名=loginame 累计CPU时间=cpu

登陆时间=login_time 打开事务数=open_tran 进程状态=status

工作站名=hostname 应用程序名=program_name 工作站进程ID=hostprocess

域名=nt_domain 网卡地址=net_address

into #t from（

select 标志= 死锁的进程

spid kpid a blocked dbid uid loginame cpu login_time open_tran

status hostname program_name hostprocess nt_domain net_address

s =a spid s =

from mastersysprocesses a join （

select blocked from mastersysprocesses group by blocked

）b on a spid=b blocked where a blocked=

union all

select |_牺牲品_>

spid kpid blocked dbid uid loginame cpu login_time open_tran

status hostname program_name hostprocess nt_domain net_address

s =blocked s =

from mastersysprocesses a where blocked<>

）a order by s s

select @count=@@rowcount @i=

if @count= and @show_spid_if_nolock=

begin

insert #t

select 标志= 正常的进程

spid kpid blocked dbid db_name（dbid） uid loginame cpu login_time

open_tran status hostname program_name hostprocess nt_domain net_address

from mastersysprocesses

set @count=@@rowcount

end

if @count>

begin

create table #t （id int identity（ ） a nvarchar（ ） b Int EventInfo nvarchar（ ））

if @kill_lock_spid=

begin

declare @spid varchar（ ） @标志 varchar（ ）

while @i<=@count

begin

select @spid=进程ID @标志=标志 from #t whereid=@i

insert #t exec（ dbcc inputbuffer（ +@spid+ ） ）

if @标志= 死锁的进程 exec（ kill +@spid）

set @i=@i+

end

end

else

while @i<=@count

begin

select @s= dbcc inputbuffer（ +cast（进程ID as varchar）+ ） from #t whereid=@i

insert #t exec（@s）

set @i=@i+

end

select a 进程的SQL语句=b EventInfo

from #t a join #t b on a id=b id

lishixinzhi/Article/program/SQLServer/201311/22183

如果两个用户进程分别锁定了不同的资源 接着又试图锁定对方所锁定的资源 就会产生死锁 此时 SQL Server将自动地选择并中止其中一个进程以解除死锁 使得另外一个进程能够继续处理 系统将回退被中止的事务 并向被回退事务的用户发送错误信息 大多数设计良好的应用都会在接收到这个错误信息之后重新提交该事务 此时提交成功的可能性是很大的 但是 如果服务器上经常出现这种情况 就会显著地降低服务器性能 为避免死锁 设计应用应当遵循一定的原则 包括 ▲ 让应用每次都以相同的次序访问服务器资源 ▲ 在事务期间禁止任何用户输入 应当在事务开始之前收集用户输入 ▲ 尽量保持事务的短小和简单 ▲ 如合适的话 为运行事务的用户连接指定尽可能低的隔离级别 [适用于 ]此外 对于SQL Server的死锁问题 下面是几则实践中很有用的小技巧 ■ 使用SQL Server Profiler的Create Trace Wizard运行 Identify The Cause of a Deadlock 跟踪来辅助识别死锁问题 它将提供帮助查找数据库产生死锁原因的原始数据 [适用于 ]■ 如果无法消除应用中的所有死锁 请确保提供了这样一种程序逻辑 它能够在死锁出现并中止用户事务之后 以随机的时间间隔自动重新提交事务 这里等待时间的随机性非常重要 这是因为另一个竞争的事务也可能在等待 我们不应该让两个竞争的事务等待同样的时间 然后再在同一时间执行它们 这样的话将导致新的死锁 [适用于 ]■ 尽可能地简化所有T SQL事务 此举将减少各种类型的锁的数量 有助于提高SQL Server应用的整体性能 如果可能的话 应将较复杂的事务分割成多个较简单的事务 [适用于 ]■ 所有条件逻辑 变量赋值以及其他相关的预备设置 *** 作应当在事务之外完成 而不应该放到事务之内 永远不要为了接受用户输入而暂停某个事务 用户输入应当总是在事务之外完成 [适用于 ]■ 在存储过程内封装所有事务 包括BEGIN TRANSACTION和MIT TRANSACTION语句 此举从两个方面帮助减少阻塞的锁 首先 它限制了事务运行时客户程序和SQL Server之间的通信 从而使得两者之间的任何消息只能出现于非事务运行时间（减少了事务运行的时间） 其次 由于存储过程强制它所启动的事务或者完成 或者中止 从而防止了用户留下未完成的事务（留下未撤销的锁） [适用于 ]■ 如果客户程序需要先用一定的时间检查数据 然后可能更新数据 也可能不更新数据 那么最好不要在整个记录检查期间都锁定记录 假设大部分时间都是检查数据而不是更新数据 那么处理这种特殊情况的一种方法就是 先选择出记录（不加UPDATE子句 UPDATE子句将在记录上加上共享锁） 然后把它发送给客户 如果用户只查看记录但从来不更新它 程序可以什么也不做 反过来 如果用户决定更新某个记录 那么他可以通过一个WHERE子句检查当前的数据是否和以前提取的数据相同 然后执行UPDATE 类似地 我们还可以检查记录中的时间标识列（如果它存在的话） 如果数据相同 则执行UPDATE *** 作 如果记录已经改变 则应用应该提示用户以便用户决定如何处理 虽然这种方法需要编写更多的代码 但它能够减少加锁时间和次数 提高应用的整体性能 [适用于 ]■ 尽可能地为用户连接指定具有最少限制的事务隔离级别 而不是总是使用默认的READ MITTED 为了避免由此产生任何其他问题 应当参考不同隔离级别将产生的效果 仔细地分析事务的特性 [适用于 ] ■ 使用游标会降低并发性 为避免这一点 如果可以使用只读的游标则应该使用READ_ONLY游标选项 否则如果需要进行更新 尝试使用OPTIMISTIC游标选项以减少加锁 设法避免使用SCROLL_LOCKS游标选项 该选项会增加由于记录锁定引起的问题 [适用于 ]■ 如果用户抱怨说他们不得不等待系统完成事务 则应当检查服务器上的资源锁定是否是导致该问题的原因 进行此类检查时可以使用SQL Server Locks Object: Average Wait Time (ms) 用该计数器来度量各种锁的平均等待时间 如果可以确定一种或几种类型的锁导致了事务延迟 就可以进一步探究是否可以确定具体是哪个事务产生了这种锁 Profiler是进行这类具体分析的最好工具 [适用于 ]■ 使用sp_who和sp_who （SQL Server Books Online没有关于sp_who 的说明 但sp_who 提供了比sp_who更详细的信息）来确定可能是哪些用户阻塞了其他用户 [适用于 ]■ 试试下面的一个或多个有助于避免阻塞锁的建议 ）对于频繁使用的表使用集簇化的索引 ）设法避免一次性影响大量记录的T SQL语句 特别是INSERT和UPDATE语句 ）设法让UPDATE和DELETE语句使用索引 ）使用嵌套事务时 避免提交和回退冲突 [适用于 ] lishixinzhi/Article/program/SQLServer/201311/22222

1、首先需要判断是哪个用户锁住了哪张表

查询被锁表

select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName 

from sysdm_tran_locks where resource_type='OBJECT'

查询后会返回一个包含spid和tableName列的表

其中spid是进程名,tableName是表名

2了解到了究竟是哪个进程锁了哪张表后,需要通过进程找到锁表的主机

查询主机名

exec sp_who2 'xxx'

xxx就是spid列的进程,检索后会列出很多信息,其中就包含主机名

3通过spid列的值进行关闭进程

关闭进程

declare @spid int

Set @spid = xxx --锁表进程

declare @sql varchar(1000)

set @sql='kill '+cast(@spid as varchar)

exec(@sql)

PS:有些时候强行杀掉进程是比较危险的,所以最好可以找到执行进程的主机,在该机器上关闭进程

解决死锁的4种基本方法（文末有惊喜）

1、预防死锁：通过设置一些限制条件，去破坏产生死锁的必要条件

2、避免死锁：在资源分配过程中，使用某种方法避免系统进入不安全的状态，从而避免发生死锁

3、检测死锁：允许死锁的发生，但是通过系统的检测之后，采取一些措施，将死锁清除掉

4、解除死锁：该方法与检测死锁配合使用

死锁介绍

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。

产生条件

虽然进程在运行过程中，可能发生死锁，但死锁的发生也必须具备一定的条件，死锁的发生必须具备以下四个必要条件。

1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。

2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。

3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。

4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源。

小关注来一波，我为你们准备了最新java学习资料文档以及高清视频教程，有需要的小伙伴扫一扫更直接

以上就是关于怎么查看数据库死锁,和解决方法(查询数据库死锁语句)全部的内容，包括:怎么查看数据库死锁,和解决方法(查询数据库死锁语句)、如何解决多线程造成的数据库死锁、减少SQLServer数据库死锁的方法等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！