当一个用户会话（会话1）已经落定了一个资源，而另一个会话（会话2）想要修改该资源，并且会话2也锁定了会话1想要修改的资源时，就会出现死锁(deadlocking)。在另一方释放资源前，会话1和会话2都不可能继续。所以，SQL Server会选择死锁中的一个会话作为死锁牺牲品。

　　注意：死锁牺牲品的会话会被杀死，事务会被回滚。

　　注意：死锁与正常的阻塞是两个经常被混淆的概念。

　　发生死锁的一些原因：

　　1、应用程序以不同的次序访问表。例如会话1先更新了客户然后更新了订单，而会话2先更新了订单然后更新了客户。这就增加了死锁的可能性。

　　2、应用程序使用了长时间的事务，在一个事务中更新很多行或很多表。这样增加了行的表面积，从而导致死锁冲突。

　　3、在一些情况下，SQL Server发出了一些行锁，之后它又决定将其升级为表锁。如果这些行在相同的数据页面中，并且两个会话希望同时在相同的页面升级锁粒度，就会产生死锁。

　　一、使用 SQL Server Profiler 分析死锁

　　http://msdn.microsoft.com/zh-cn/library/ms188246.ASPx

　　二、使用跟踪标志位找出死锁

　　本文主要介绍使用DBCC TRACEON、DBCC TRACEOFF和DBCC TRACESTATUS命令来确保死锁被正确记录到SQL Server Management Studio SQL日志中。这些命令用来启用、关闭、和检查跟踪标志位的状态。

　　■DBCC TRACEON，启用跟踪标志位。用法：DBCC TRACEON ( trace# [ ,...n ][ , -1 ] ) [ WITH NO_INFOMSGS ]

　　详细参看 MSDN:http://msdn.microsoft.com/zh-cn/library/ms187329.ASPx

　　■DBCC TRACESTATUS，检查跟踪标志位状态。用法：DBCC TRACESTATUS ( [ [ trace# [ ,...n ] ] [ , ] [ -1 ] ] ) [ WITH NO_INFOMSGS ]

　　详细参看 MSDN:http://msdn.microsoft.com/zh-cn/library/ms187809.ASPx

　　■DBCC TRACEOFF，关闭跟踪标志位。用法：DBCC TRACEOFF (trace# [ ,...n ] [ , -1 ] ) [ WITH NO_INFOMSGS ]

　　详细参看 MSDN:http://msdn.microsoft.com/en-us/library/ms174401.ASPx

　　下面我们模拟一个死锁：

　　在第一个SQL查询窗口执行：

use AdventureWorks
go
SET NOCOUNT ON
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
WHILE 1=1
BEGIN
BEGIN TRAN
UPDATE Purchasing.Vendor
SET CreditRating = 1
WHERE VendorID = 90
UPDATE Purchasing.Vendor
SET CreditRating = 2
WHERE VendorID = 91
COMMIT TRAN
END        

        

        
        
      
        
it知识库：SQL Server 2008中SQL应用之－“死锁(Deadlocking)”，转载需保留来源！
        
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。