事务_进程 ID 60_与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务

事务(进程 ID 60)与另一个进程被死锁在锁资源上，并且已被选作死锁牺牲品。

请重新运行该事务。

一、问题描述近期，由于二十多台电脑同时访问一台SQL Server 2005服务器，并且数据每间隔3分钟从另一个Oracle数据库中读取数据信息供20多台电脑查询与显示，在信息显示时，经常报下面的错误，导致程序出错。

‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐事务(进程 ID 60)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。

请重新运行该事务。

在 System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)在 System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)在 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)在 System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)在 System.Data.SqlClient.SqlDataReader.HasMoreRows()在 System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)在 System.Data.SqlClient.SqlDataReader.Read()在 HonryLCD.honry.lcd.LcdPatientFrm.getBed()二、处理说明1、查看锁状态连上数据库后，在查询界面中按 Ctrl+2 键可以查询状态，如下：2、事务(进程 ID 59)与另一个进程被死锁在 锁 资源上，并且已被选作死锁牺牲品。

请重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)事务（进程 ID ）与另一个进程已被死锁在 lock 资源上，且该事务已被选作死锁牺牲品。

请重新运行该事务其实所有的死锁最深层的原因就是一个:资源竞争 表现一:一个用户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 ....==========================在联机事务处理(OLTP)的数据库应用系统中，多用户、多任务的并发性是系统最重要的技术指标之一。

为了提高并发性，目前大部分RDBMS都采用加锁技术。

然而由于现实环境的复杂性，使用加锁技术又不可避免地产生了死锁问题。

因此如何合理有效地使用加锁技术，最小化死锁是开发联机事务处理系统的关键。

死锁产生的原因在联机事务处理系统中，造成死机主要有两方面原因。

一方面，由于多用户、多任务的并发性和事务的完整性要求，当多个事务处理对多个资源同时访问时，若双方已锁定一部分资源但也都需要对方已锁定的资源时，无法在有限的时间内完全获得所需的资源，就会处于无限的等待状态，从而造成其对资源需求的死锁。

另一方面，数据库本身加锁机制的实现方法不同，各数据库系统也会产生其特殊的死锁情况。

如在Sybase SQL Server 11中，最小锁为2K一页的加锁方法，而非行级锁。

如果某张表的记录数少且记录的长度较短(即记录密度高，如应用系统中的系统配置表或系统参数表就属于此类表)，被访问的频率高，就容易在该页上产生死锁。

几种死锁情况及解决方法清算应用系统中，容易发生死锁的几种情况如下:● 不同的存储过程、触发器、动态SQL语句段按照不同的顺序同时访问多张表;● 在交换期间添加记录频繁的表，但在该表上使用了非群集索引(non‐clustered);● 表中的记录少，且单条记录较短，被访问的频率较高；● 整张表被访问的频率高(如代码对照表的查询等)。

以上死锁情况的对应处理方法如下：● 在系统实现时应规定所有存储过程、触发器、动态SQL语句段中，对多张表的操作总是使用同一顺序。

如：有两个存储过程proc1、proc2，都需要访问三张表zltab、z2tab和z3tab，如果proc1按照zltab、z2tab和z3tab的顺序进行访问，那么，proc2也应该按照以上顺序访问这三张表。

● 对在交换期间添加记录频繁的表，使用群集索引(clustered)，以减少多个用户添加记录到该表的最后一页上，在表尾产生热点，造成死锁。

这类表多为往来账的流水表，其特点是在交换期间需要在表尾追加大量的记录，并且对已添加的记录不做或较少做删除操作。

● 对单张表中记录数不太多，且在交换期间select或updata较频繁的表可使用设置每页最大行的办法，减少数据在表中存放的密度，模拟行级锁，减少在该表上死锁情况的发生。

这类表多为信息繁杂且记录条数少的表。

如：系统配置表或系统参数表。

在定义该表时添加如下语句：with max_rows_per_page=1● 在存储过程、触发器、动态SQL语句段中，若对某些整张表select操作较频繁，则可能在该表上与其他访问该表的用户产生死锁。

对于检查账号是否存在，但被检查的字段在检查期间不会被更新等非关键语句，可以采用在select命令中使用at isolation read uncommitted子句的方法解决。

该方法实际上降低了select语句对整张表的锁级别，提高了其他用户对该表操作的并发性。

在系统高负荷运行时，该方法的效果尤为显著。

例如：select*from titles at isolation read uncommitted● 对流水号一类的顺序数生成器字段，可以先执行updata流水号字段+1，然后再执行select 获取流水号的方法进行操作。

小结笔者对同城清算系统进行压力测试时，分别对采用上述优化方法和不采用优化方法的两套系统进行测试。

在其他条件相同的情况下，相同业务笔数、相同时间内，死锁发生的情况如下： 采用优化方法的系统: 0次/万笔业务;不采用优化方法的系统：50～200次/万笔业务。

所以，使用上述优化方法后，特别是在系统高负荷运行时效果尤为显著。

总之，在设计、开发数据库应用系统，尤其是OLTP系统时，应该根据应用系统的具体情况，依据上述原则对系统分别优化，为开发一套高效、可靠的应用系统打下良好的基础。

3、SQL Server死锁总结1. 死锁原理根据操作系统中的定义：死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态。

死锁的四个必要条件：互斥条件(Mutual exclusion)：资源不能被共享，只能由一个进程使用。

请求与保持条件(Hold and wait)：已经得到资源的进程可以再次申请新的资源。

非剥夺条件(No pre-emption)：已经分配的资源不能从相应的进程中被强制地剥夺。

循环等待条件(Circular wait)：系统中若干进程组成环路，该环路中每个进程都在等待相邻进程正占用的资源。

对应到SQL Server中，当在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁；这些资源可能是：单行(RID，堆中的单行)、索引中的键(KEY，行锁)、页(PAG，8KB)、区结构(EXT，连续的8页)、堆或B树(HOBT) 、表(TAB，包括数据和索引)、文件(File，数据库文件)、应用程序专用资源(APP)、元数据(METADATA)、分配单元(Allocation_Unit)、整个数据库(DB)。

一个死锁示例如下图所示：说明：T1、T2表示两个任务；R1和R2表示两个资源；由资源指向任务的箭头(如R1-<T1，R2-<T2)表示该资源被改任务所持有；由任务指向资源的箭头(如T1-<S2，T2-<S1)表示该任务正在请求对应目标资源；其满足上面死锁的四个必要条件：(1).互斥：资源S1和S2不能被共享，同一时间只能由一个任务使用；(2).请求与保持条件：T1持有S1的同时，请求S2；T2持有S2的同时请求S1；(3).非剥夺条件：T1无法从T2上剥夺S2，T2也无法从T1上剥夺S1；(4).循环等待条件：上图中的箭头构成环路，存在循环等待。

2. 死锁排查(1). 使用SQL Server的系统存储过程sp_who和sp_lock，可以查看当前数据库中的锁情况；进而根据objectID(@objID)(SQL Server 2005)/ object_name(@objID)(Sql Server 2000)可以查看哪个资源被锁，用dbcc ld(@blk)，可以查看最后一条发生给SQL Server的Sql语句；CREATE Table #Who(spid int,ecid int,status nvarchar(50),loginname nvarchar(50),hostname nvarchar(50),blk int,dbname nvarchar(50),cmd nvarchar(50),request_ID int);CREATE Table #Lock(spid int,dpid int,objid int,indld int,[Type]nvarchar(20),Resource nvarchar(50),Mode nvarchar(10),Status nvarchar(10));INSERT INTO #WhoEXEC sp_who active --看哪个引起的阻塞，blkINSERT INTO #LockEXEC sp_lock --看锁住了那个资源id，objidDECLARE@DBName nvarchar(20);SET@DBName='NameOfDataBase'SELECT #Who.*FROM #Who WHERE dbname=@DBNameSELECT #Lock.*FROM #LockJOIN #WhoON #Who.spid=#Lock.spidAND dbname=@DBName;--最后发送到SQL Server的语句DECLARE crsr Cursor FORSELECT blk FROM #Who WHERE dbname=@DBName AND blk<<0;DECLARE@blk int;open crsr;FETCH NEXT FROM crsr INTO@blk;WHILE (@@FETCH_STATUS=0)BEGIN;dbcc inputbuffer(@blk);FETCH NEXT FROM crsr INTO@blk;END;close crsr;DEALLOCATE crsr;--锁定的资源SELECT #Who.spid,hostname,objid,[type],mode,object_name(objid) as objName FROM #Lock JOIN #WhoON #Who.spid=#Lock.spidAND dbname=@DBNameWHERE objid<<0;DROP Table #Who;DROP Table #Lock;(2). 使用 SQL Server Profiler 分析死锁: 将 Deadlock graph 事件类添加到跟踪。