时间戳

首页 > 技术文章 > 事务(进程 ID 133)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品的解决方案

事务(进程 ID 133)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品的解决方案

yidanda888 2019-11-23 10:29 原文

并发大了，经常出现这个提示：

/”应用程序中的服务器错误。
事务(进程 ID 133)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务。
说明: 执行当前 Web 请求期间，出现未经处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。

异常详细信息: System.Data.SqlClient.SqlException: 事务(进程 ID 133)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。请重新运行该事务。

源错误:

执行当前 Web 请求期间生成了未经处理的异常。可以使用下面的异常堆栈跟踪信息确定有关异常原因和发生位置的信息。

估计就是抢锁造成的，查看了这篇文章终于找到了解决方案：SELECT COUNT(*) FROM Example WITH(NOLOCK)    ，加上WITH(NOLOCK)就可以了

原文地址

 
NOLOCK

NOLOCK在概念上类似于READ UNCOMMITTED隔离级别，并且只针对于SELECT查询语句，它不会获取表的共享锁，换句话说不会阻止排它锁来更新数据行。当我们对表进行NOLOCK有什么好处呢？它能够提高并发性能，因为此时SQL Server数据库引擎不必去维护共享锁，由于不会对正在读取的表获取共享锁，所以可能导致未提交的事务也会被读取，所以此时缺点显而易见将导致脏读

SELECT COUNT(*) FROM Example WITH(NOLOCK)
READPAST

当在表中用READPAST指定提示时此时SQL Server数据库引擎在返回结果集时将不会返回锁定的行或者数据页。它除了和NOLOCK一样不会导致查询阻塞外，因为不会返回锁定的行记录所以其优点好包括不存在脏读。但是其缺点则是因为不包含锁定的行记录但是很难保证结果集或者修改语句是否包含我们所必须需要返回的行。有可能在我们的业务逻辑中，需要返回我们必须需要的行。它的使用方式和NOLOCK一样

SELECT COUNT(*)FROM Example WITH(READPAST)
UPDLOCK

UPDLOCK只是针对于表中的某一行记录来锁定从而阻止其他操作对该行的数据更新，说到这里想必我们已经明了，UPDLOCK是行级别，而排它锁则是表级别，二者不可同日而语。也就说当我们对某一行添加UPDLOCK提示时并不会阻塞其他查询操作

BEGIN TRAN
 select * from Example WITH (UPDLOCK) where SaleID = 1
此时我们再来开一个窗口进行查询，如下：
select * from Example
HOLDLOCK

使用HOLDLOCK提示时，此时查询将锁定表且被强制序列化，直到事务完成，才会被释放，其类似于SERIALIZABLE最高隔离级别

BEGIN TRAN
 select * from Example WITH (UPDLOCK,HOLDLOCK) where SaleID = 1

访问一个内部调研页面，打开第二次就死锁了，搜索了一下，一种可能的情况类似下面这种场景，SQLServer中似乎嵌套的SQL语句会造成死锁，用nolock

hint可以解决这个问题。

update  t_sms_send set msg_flag =-1  where id in (select top 100 id from t_sms_send  where msg_flag=-2)

此句应该改为

update  t_sms_send set msg_flag =-1  where id in (select top 100 id from t_sms_send with (nolock) where msg_flag=-2)

在存储过程、触发器、动态SQL语句段中，若对某些整张表select操作较频繁，则可能在该表上与其他访问该表的用户产生死锁。对于检查账号是否存在，但被检查的字段在检查期间不会被更新等非关键语句，可以采用在select命令中使用at  isolation  read  uncommitted子句的方法解决。

该方法实际上降低了select语句对整张表的锁级别，提高了其他用户对该表操作的并发性。在系统高负荷运行时，该方法的效果尤为显著。    




例如：    

   select * from  titles  at  isolation  read  uncommitted   

 查询数据的时候 提示事务(进程 ID **)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。
vip__888
于 2010-12-20 22:13:00 发布 25866
收藏
分类专栏： Sqlserver 文章标签： 脚本 测试 数据库 .net c
版权
Sqlserver 专栏收录该内容
14 篇文章 0 订阅
订阅专栏
所有Select加 With (NoLock)解决阻塞死锁
在查询语句中使用 NOLOCK 和 READPAST

处理一个数据库死锁的异常时候，其中一个建议就是使用 NOLOCK 或者 READPAST 。有关 NOLOCK 和 READPAST的一些技术知识点：

对于非银行等严格要求事务的行业，搜索记录中出现或者不出现某条记录，都是在可容忍范围内，所以碰到死锁，应该首先考虑，我们业务逻辑是否能容忍出现或者不出现某些记录，而不是寻求对双方都加锁条件下如何解锁的问题。

NOLOCK 和 READPAST 都是处理查询、插入、删除等操作时候，如何应对锁住的数据记录。但是这时候一定要注意NOLOCK 和 READPAST的局限性，确认你的业务逻辑可以容忍这些记录的出现或者不出现：


简单来说：

NOLOCK  可能把没有提交事务的数据也显示出来．

READPAST 会把被锁住的行不显示出来  

不使用 NOLOCK 和 READPAST ，在 Select 操作时候则有可能报错误：事务(进程 ID **)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。



下面就来演示这个情况。

为了演示两个事务死锁的情况，我们下面的测试都需要在SQL Server Management Studio中打开两个查询窗口。保证事务不被干扰。



演示一 没有提交的事务，NOLOCK 和 READPAST处理的策略：

查询窗口一请执行如下脚本：

CREATE TABLE t1 (c1 int IDENTITY(1,1), c2 int)
go

BEGIN TRANSACTION
insert t1(c2) values(1)



在查询窗口一执行后，查询窗口二执行如下脚本：

select count(*) from t1 WITH(NOLOCK)
select count(*) from t1 WITH(READPAST)



结果与分析：

查询窗口二依次显示统计结果为： 1、0

查询窗口一的命令没有提交事务，所以 READPAST 不会计算没有提交事务的这一条记录，这一条被锁住了，READPAST 看不到；而NOLOCK则可以看到被锁住的这一条记录。



如果这时候我们在查询窗口二中执行：

select count(*) from t1 就会看到这个执行很久不能执行完毕，因为这个查询遇到了一个死锁。



清除掉这个测试环境，需要在查询窗口一中再执行如下语句：

ROLLBACK TRANSACTION
drop table t1



演示二：对被锁住的记录，NOLOCK 和 READPAST处理的策略



这个演示同样需要两个查询窗口。

请在查询窗口一中执行如下语句：

CREATE TABLE t2 (UserID int , NickName nvarchar(50))
go
insert t2(UserID,NickName) values(1,'郭红俊')
insert t2(UserID,NickName) values(2,'蝈蝈俊')
go

BEGIN TRANSACTION
update t2 set NickName = '蝈蝈俊.net' where UserID = 2



请在查询窗口二中执行如下脚本：

select * from t2 WITH(NOLOCK) where UserID = 2
select * from t2 WITH(READPAST) where UserID = 2



结果与分析：

查询窗口二中， NOLOCK 对应的查询结果中我们看到了修改后的记录，READPAST对应的查询结果中我们没有看到任何一条记录。 这种情况下就可能发生脏读
————————————————
版权声明：本文为CSDN博主「vip__888」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/vip__888/article/details/6087850

推荐阅读