sqlserver表死锁,sqlserver表死锁原因

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

sqlServer查看死锁及解锁

--查看死锁

select spid, blocked, loginame, last_batch, status, cmd, hostname, program_name

from sysprocesses

where spid in

( select blocked from sysprocesses where blocked 0 ) or (blocked 0)

--解锁

kill 进程号（spid）

相关问答

Q1: sqlserver怎么用sql查看具体那个表被锁住了

详细步骤如下：

1、点击【新建查询】按钮，打开SQL命令编辑框，对数据库表的操作以及维护都可以通过编辑SQL命令实现。

2、在编辑框内编辑创建数据库表的代码，确认代码无误后，单击【执行】按钮，创建数据表。

3、创建数据表的源代码如下：

use test go

if exists(select name from sys.tables where name='Student')

drop table Student go

create table Student

(sname nchar(10) primary key,

sex nchar(2) not null,

bir datetime)

数据库管理系统，database management system，简称dbms，是一种操纵和管理数据库的大型软件，用于建立、使用和维护数据库。用户通过dbms访问数据库中的数据，数据库管理员也通过dbms进行数据库的维护工作。它可使多个应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问数据库。

提供数据定义语言（ddl）。用它书写的数据库模式被翻译为内部表示。数据库的逻辑结构、完整性约束和物理储，存结构保存在内部的数据字典中。数据库的各种数据操作（如查找、修改、插入和删除等）和数据库的维护管理都是以数据库模式为依据的。

Q2: 如何监控sqlserver 性能死锁

具体步骤如下：

1.首先使用下面的命令，将有关的跟踪标志启用。

SQL codeDBCC TRACEON (3605,1204,1222,-1)

说明：

3605

将DBCC的结果输出到错误日志。

1204 返回参与死锁的锁的资源和类型，以及受影响的当前命令。

1222

返回参与死锁的锁的资源和类型，以及使用了不符合任何 XSD 架构的 XML 格式的受影响的当前命令(比1204更进一步,SQL

2005及以上可用)。

-1 以全局方式打开指定的跟踪标记。

以上跟踪标志作用域都是全局，即在SQL

Server运行过程中，会一直发挥作用，直到SQL Server重启。

如果要确保SQL Server在重启后自动开启这些标志，可以在SQL

Server服务启动选项中，使用 /T 启动选项指定跟踪标志在启动期

间设置为开。(位于SQL Server配置管理器-SQL

Server服务-SQL Server-属性-高级-启动参数)

在运行上面的语句后，当SQL

Server中发生死锁时，已经可以在错误日志中看到了，但还不够直观(和其它信息混在一起)。（SSMS

- SQL Server实例 -

管理 - SQL Server日志）

2.建表，存放死锁记录

SQL codeUSE [Cole] --Cole是我的示例数据库，你可以根据实际情况修改。 GO

CREATE TABLE DeadLockLog ( id int IDENTITY (1, 1) NOT NULL, LogDate DATETIME, ProcessInfo VARCHAR(10), ErrorText VARCHAR(MAX) )

3.建立JOB

新建一个JOB（假设名称为DeadLockJob）,在"步骤"中新建一步骤，随便写一个步骤名称，数据库为"Cole",在"命令"栏中输入以下语句：

SQL code--新建临时表 IF OBJECT_ID('tempdb.dbo.#ErrorLog') IS Not Null

DROP TABLE #ErrorLog

CREATE TABLE #ErrorLog (Id int IDENTITY (1, 1) NOT NULL, a DATETIME, b VARCHAR(10), c VARCHAR(MAX)) --将当前日志记录插入临时表

INSERT INTO #ErrorLog EXEC master.dbo.sp_readerrorlog --将死锁信息插入用户表

insert DeadLockLog

select a, b, c from #ErrorLog where id = (select MAX(id) from #ErrorLog WHERE c Like '%Deadlock encountered%')

DROP TABLE #ErrorLog

4.新建警报

在"新建警报"窗体的"常规"选项卡中,进行以下设置：

名称：可根据实际自行命名，这里我用DeadLockAlert

类型：选择"SQL

Server性能条件警报"

对象：SQLServer:Locks

计数器：Number of

Deadlocks/sec

实例：_Total

计数器满足以下条件时触发警报：高于

值：0

在"响应"选项卡中，选中"执行作业"，并选择步骤3中我们新建的作业(即DeadlockJob)

到这里为止，我们已经完成了全部步骤，以后，你就可以随时查询DeadLockLog表，来显示死锁信息了。

Q3: sqlserver 数据库死锁后多长时间解锁

您好：

SQL SERVER 通过锁管理器自动发现和解决死锁。在 SQL SERVER 中 Lock Monitor 管理线程（spid=4）每 5 秒钟检查一次系统中是否存在死锁，同时也会使用死锁发现计数器（Deadlock Detection Counter）控制检查死锁的频率。

死锁发现计数器初始值为 3，当发现死锁时被重新设置为 3，当没有发现死锁时此值减 1。如果死锁发现计数器大于 0，则在每次有进程获取锁被阻止时，锁管理器都要求 Lock Monitor 线程检查死锁；而如果计数器等于 0，则在每次有进程获取锁被阻止时，锁管理器不会要求 Lock Monitor 线程检查死锁，只是每 5 秒钟检查一次。

Lock Monitor 线程通过检查锁的等待列表发现保持锁的进程和等待锁的进程间的关系，从而发现死锁。

Q4: 如何处理SQL Server死锁问题

死锁，简而言之，两个或者多个trans，同时请求对方正在请求的某个对象，导致双方互相等待。简单的例子如下：

trans1 trans2

------------------------------------------------------------------------

1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction

2.update table A 2.update table B

3.update table B 3.update table A

4.IDBConnection.Commit 4.IDBConnection.Commit

那么，很容易看到，如果trans1和trans2，分别到达了step3，那么trans1会请求对于B的X锁，trans2会请求对于A的X锁，而二者的锁在step2上已经被对方分别持有了。由于得不到锁，后面的Commit无法执行，这样双方开始死锁。

好，我们看一个简单的例子，来解释一下，应该如何解决死锁问题。

-- Batch #1

CREATE DATABASE deadlocktest

USE deadlocktest

SET NOCOUNT ON

DBCC TRACEON (1222, -1)

-- 在SQL2005中，增加了一个新的dbcc参数，就是1222，原来在2000下，我们知道，可以执行dbcc

--traceon(1204,3605,-1)看到所有的死锁信息。SqlServer 2005中，对于1204进行了增强，这就是1222。

IF OBJECT_ID ('t1') IS NOT NULL DROP TABLE t1

IF OBJECT_ID ('p1') IS NOT NULL DROP PROC p1

IF OBJECT_ID ('p2') IS NOT NULL DROP PROC p2

CREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000))

DECLARE @x int

SET @x = 1

WHILE (@x = 1000) BEGIN

INSERT INTO t1 VALUES (@x*2, @x*2, @x*2, @x*2)

SET @x = @x + 1

END

CREATE CLUSTERED INDEX cidx ON t1 (c1)

CREATE NONCLUSTERED INDEX idx1 ON t1 (c2)

CREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

CREATE PROC p2 @p1 int AS

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1

上述sql创建一个deadlock的示范数据库，插入了1000条数据，并在表t1上建立了c1列的聚集索引，和c2列的非聚集索引。另外创建了两个sp，分别是从t1中select数据和update数据。

好，打开一个新的查询窗口，我们开始执行下面的query：

-- Batch #2

USE deadlocktest

SET NOCOUNT ON

WHILE (1=1) EXEC p2 4

开始执行后，然后我们打开第三个查询窗口，执行下面的query：

-- Batch #3

USE deadlocktest

SET NOCOUNT ON

CREATE TABLE #t1 (c2 int, c3 int)

WHILE (1=1) BEGIN

INSERT INTO #t1 EXEC p1 4

TRUNCATE TABLE #t1

END

开始执行，哈哈，很快，我们看到了这样的错误信息：

Msg 1205, Level 13, State 51, Procedure p1, Line 4

Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

spid54发现了死锁。

那么，我们该如何解决它？

在SqlServer 2005中，我们可以这么做：

1.在trans3的窗口中，选择EXEC p1 4，然后right click，看到了菜单了吗？选择Analyse Query in Database Engine Tuning Advisor。

2.注意右面的窗口中，wordload有三个选择：负载文件、表、查询语句，因为我们选择了查询语句的方式，所以就不需要修改这个radio option了。

3.点左上角的Start Analysis按钮

4.抽根烟，回来后看结果吧！出现了一个分析结果窗口，其中，在Index Recommendations中，我们发现了一条信息：大意是，在表t1上增加一个非聚集索引索引：t2+t1。

5.在当前窗口的上方菜单上，选择Action菜单，选择Apply Recommendations，系统会自动创建这个索引。

重新运行batch #3，呵呵，死锁没有了。

这种方式，我们可以解决大部分的Sql Server死锁问题。那么，发生这个死锁的根本原因是什么呢？为什么增加一个non clustered index，问题就解决了呢？这次，我们分析一下，为什么会死锁呢？再回顾一下两个sp的写法：

CREATE PROC p1 @p1 int AS

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

CREATE PROC p2 @p1 int AS

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1

很奇怪吧！p1没有insert，没有delete，没有update，只是一个select，p2才是update。这个和我们前面说过的，trans1里面updata A，update B；trans2里面upate B，update A，根本不贴边啊！

那么，什么导致了死锁？

需要从事件日志中，看sql的死锁信息：

Spid X is running this query (line 2 of proc [p1], inputbuffer “… EXEC p1 4 …”):

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

Spid Y is running this query (line 2 of proc [p2], inputbuffer “EXEC p2 4”):

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

The SELECT is waiting for a Shared KEY lock on index t1.cidx. The UPDATE holds a conflicting X lock.

The UPDATE is waiting for an eXclusive KEY lock on index t1.idx1. The SELECT holds a conflicting S lock.

首先，我们看看p1的执行计划。怎么看呢？可以执行set statistics profile on，这句就可以了。下面是p1的执行计划

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [t1].[c1]))

|--Index Seek(OBJECT:([t1].[idx1]), SEEK:([t1].[c2] = [@p1] AND [t1].[c2] = [@p1]+(1)) ORDERED FORWARD)

|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[t1].[c1] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)

我们看到了一个nested loops，第一行，利用索引t1.c2来进行seek，seek出来的那个rowid，在第二行中，用来通过聚集索引来查找整行的数据。这是什么？就是bookmark lookup啊！为什么？因为我们需要的c2、c3不能完全的被索引t1.c1带出来，所以需要书签查找。

好，我们接着看p2的执行计划。

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

|--Clustered Index Update(OBJECT:([t1].[cidx]), OBJECT:([t1].[idx1]), SET:([t1].[c2] = [Expr1004]))

|--Compute Scalar(DEFINE:([Expr1013]=[Expr1013]))

|--Compute Scalar(DEFINE:([Expr1004]=[t1].[c2]+(1), [Expr1013]=CASE WHEN CASE WHEN ...

|--Top(ROWCOUNT est 0)

|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[@p1]) ORDERED FORWARD)

通过聚集索引的seek找到了一行，然后开始更新。这里注意的是，update的时候，它会申请一个针对clustered index的X锁的。

实际上到这里，我们就明白了为什么update会对select产生死锁。update的时候，会申请一个针对clustered index的X锁，这样就阻塞住了（注意，不是死锁！）select里面最后的那个clustered index seek。死锁的另一半在哪里呢？注意我们的select语句，c2存在于索引idx1中，c1是一个聚集索引cidx。问题就在这里！我们在p2中更新了c2这个值，所以sqlserver会自动更新包含c2列的非聚集索引：idx1。而idx1在哪里？就在我们刚才的select语句中。而对这个索引列的更改，意味着索引集合的某个行或者某些行，需要重新排列，而重新排列，需要一个X锁。

SO………，问题就这样被发现了。

总结一下，就是说，某个query使用非聚集索引来select数据，那么它会在非聚集索引上持有一个S锁。当有一些select的列不在该索引上，它需要根据rowid找到对应的聚集索引的那行，然后找到其他数据。而此时，第二个的查询中，update正在聚集索引上忙乎：定位、加锁、修改等。但因为正在修改的某个列，是另外一个非聚集索引的某个列，所以此时，它需要同时更改那个非聚集索引的信息，这就需要在那个非聚集索引上，加第二个X锁。select开始等待update的X锁，update开始等待select的S锁，死锁，就这样发生鸟。

那么，为什么我们增加了一个非聚集索引，死锁就消失鸟？我们看一下，按照上文中自动增加的索引之后的执行计划：

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

|--Index Seek(OBJECT:([deadlocktest].[dbo].[t1].[_dta_index_t1_7_2073058421__K2_K1_3]), SEEK:([deadlocktest].[dbo].[t1].[c2] = [@p1] AND [deadlocktest].[dbo].[t1].[c2] = [@p1]+(1)) ORDERED FORWARD)

哦，对于clustered index的需求没有了，因为增加的覆盖索引已经足够把所有的信息都select出来。就这么简单。

实际上，在sqlserver 2005中，如果用profiler来抓eventid：1222，那么会出现一个死锁的图，很直观的说。

下面的方法，有助于将死锁减至最少（详细情况，请看SQLServer联机帮助，搜索：将死锁减至最少即可。

按同一顺序访问对象。

避免事务中的用户交互。

保持事务简短并处于一个批处理中。

使用较低的隔离级别。

使用基于行版本控制的隔离级别。

将 READ_COMMITTED_SNAPSHOT 数据库选项设置为 ON，使得已提交读事务使用行版本控制。

使用快照隔离。

使用绑定连接。

Q5: 如何处理SQL Server死锁问题？

死锁，简而言之，两个或者多个trans，同时请求对方正在请求的某个对象，导致双方互相等待。简单的例子如下：\x0d\x0a trans1 trans2\x0d\x0a ------------------------------------------------------------------------\x0d\x0a 1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction\x0d\x0a 2.update table A 2.update table B\x0d\x0a 3.update table B 3.update table A\x0d\x0a 4.IDBConnection.Commit 4.IDBConnection.Commit \x0d\x0a 那么，很容易看到，如果trans1和trans2，分别到达了step3，那么trans1会请求对于B的X锁，trans2会请求对于A的X锁，而二者的锁在step2上已经被对方分别持有了。由于得不到锁，后面的Commit无法执行，这样双方开始死锁。\x0d\x0a 好，我们看一个简单的例子，来解释一下，应该如何解决死锁问题。\x0d\x0a -- Batch #1\x0d\x0a CREATE DATABASE deadlocktest\x0d\x0a GO\x0d\x0a USE deadlocktest\x0d\x0a SET NOCOUNT ON\x0d\x0a DBCC TRACEON (1222, -1)\x0d\x0a -- 在SQL2005中，增加了一个新的dbcc参数，就是1222，原来在2000下，我们知道，可以执行dbcc \x0d\x0a --traceon(1204,3605,-1)看到所有的死锁信息。SqlServer 2005中，对于1204进行了增强，这就是1222。\x0d\x0a GO \x0d\x0a \x0d\x0a IF OBJECT_ID ('t1') IS NOT NULL DROP TABLE t1\x0d\x0a IF OBJECT_ID ('p1') IS NOT NULL DROP PROC p1\x0d\x0a IF OBJECT_ID ('p2') IS NOT NULL DROP PROC p2\x0d\x0a GO\x0d\x0a CREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000)) \x0d\x0a GO\x0d\x0a DECLARE @x int\x0d\x0a SET @x = 1\x0d\x0a WHILE (@x = [@p1] AND [t1].[c2] = [@p1] AND [deadlocktest].[dbo].[t1].[c2]

回答于 2022-11-16