前言:
在两个或多个SQL Server进程中,每一个进程锁定了其他进程试图锁定的资源,就会出现死锁,例如,进程process1对table1持有1个排它锁(X),同时process1对table2请求1个排它锁(X), 进程process2对table2持有1个排它锁(X),同时process2对table1请求1个排它锁(X) 类似这种情况,就会出现死锁,除非当某个外部进程断开死锁,否则死锁中的两个事务都将无限期等待下去。
Microsoft SQL Server 数据库引擎死锁监视器定期检查陷入死锁的任务。
如果监视器检测到循环依赖关系,将选择其中一个任务作为牺牲品(通常是选择占资源比较小的进程作为牺牲品),然后终止其事务并提示错误1205。
我们可以通过SQL Server Profiler来监视分析死锁的发生过程。
1.创建测试表。
在 Microsoft SQL Server Management Studio上,新建一个查询,写创建表DealLockTest_1 & DealLockTest_2两个表:
use Test --创建分析死锁使用到的两个表DealLockTest_1&DealLockTest_2 go Set Nocount On Go if object_id(‘DealLockTest_1‘)Is Not Null Drop Table DealLockTest_1 go Create Table DealLockTest_1 ( ID int Identity(1,1)Primary Key, Name nvarchar(512) ) if object_id(‘DealLockTest_2‘)Is Not Null Drop Table DealLockTest_2 go Create Table DealLockTest_2 ( ID int Identity(1,1)Primary Key, Name nvarchar(512) ) Go Insert Into DealLockTest_1(Name) Select name From sys.all_objects Insert Into DealLockTest_2(Name) Select name From sys.all_objects --SELECT * FROM DealLockTest_1 --SELECT * FROM DealLockTest_2
创建好表和插入测试数据后,先执行脚本代码(因为我们不需要跟踪该代码),紧接着,我们就模拟两个会话,一个会话里面包含一个事务。这里我们就新建两个查询,其中第一个会话,是更新DealLockTest_1表后,等待5秒钟,更新DealLocktest_2.
--第一个会话 Begin Tran Update DealLockTest_1 Set Name=N‘test1‘ Where ID>0 /*这里的Waitfor等待,是为了容易获取死锁的发生*/ Waitfor Delay‘00:00:15‘ --Update DealLockTest_2 --Set Name=N‘test2‘ --Where ID>0 SELECT * FROM DealLockTest_2 Commit Tran Go
代码写好后,我们先不要执行代码,接下来就写第二个会话代码; 第二个会话更新表的顺序,刚好与第一个会话相反,是更新DealLockTest_2表后,等待5秒钟,更新DealLocktest_1.
--第二个会话 Begin Tran Update DealLockTest_2 Set Name=N‘test1‘ Where ID>0 /*这里的Waitfor等待,是为了容易获取死锁的发生*/ Waitfor Delay‘00:00:15‘ --Update DealLockTest_1 --Set Name=N‘test2‘ --Where ID>0 SELECT * FROM DealLockTest_1 Commit Tran
第二个会话代码,也先不要执行。
2.启动SQL Server Profiler,创建一个跟踪,使用: TSQL_Locks模板,在这个基础上面可以增加些自己想要的事件或者事件列,这里需要注意下,你可能只想筛选某个DB的资料,但是不能直接在DB那里进行筛选,不然的话你看不到 Deadlock graph事件,需要的话你可以将监控结果存在某个表里面再进行筛选。
当然精简一些就是:
点执行按钮,启动Trace。
3.执行测试代码&监视死锁。
转到 Microsoft SQL Server Management Studio界面,依次执行第一个会话和第二个会话的代码,稍稍等待15秒钟,我们就会发现其中一个会话收到报错消息
原文地址:https://www.cnblogs.com/ziqiumeng/p/10927554.html