详解SQLServerProfiler分析死锁几大步骤

本文将为大家讲的是SQL Server Profiler分析死锁几大步骤，这里也是为了大家更好的做好数据库的管理工作。

10年的阳西网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。全网整合营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整阳西建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联公司从事“阳西网站设计”,“阳西网站推广”以来，每个客户项目都认真落实执行。

在两个或多个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两个表：

脚本：

   
 
 
 
    
    
  
  
  
  1. useTest 
    2.     
  
  
  
  2. --创建分析死锁使用到的两个表DealLockTest_1&DealLockTest_2 
    3.     
  
  
  
  3. go 
    4.     
  
  
  
  4. SetNocountOn 
    5.     
  
  
  
  5. Go 
    6.     
  
  
  
  6. ifobject_id('DealLockTest_1')IsNotNull 
    7.     
  
  
  
  7. DropTableDealLockTest_1 
    8.     
  
  
  
  8. go 
    9.     
  
  
  
  9. CreateTableDealLockTest_1 
    10.     
  
  
  
  10. ( 
    11.     
  
  
  
  11. IDintIdentity(1,1)PrimaryKey, 
    12.     
  
  
  
  12. Namenvarchar(512) 
    13.     
  
  
  
  13. ) 
    14.     
  
  
  
  14. ifobject_id('DealLockTest_2')IsNotNull 
    15.     
  
  
  
  15. DropTableDealLockTest_2 
    16.     
  
  
  
  16. go 
    17.     
  
  
  
  17. CreateTableDealLockTest_2 
    18.     
  
  
  
  18. ( 
    19.     
  
  
  
  19. IDintIdentity(1,1)PrimaryKey, 
    20.     
  
  
  
  20. Namenvarchar(512) 
    21.     
  
  
  
  21. ) 
    22.     
  
  
  
  22. Go
    23.

--插入一些测试数据 

   
 
 
 
    
    
  
  
  
  1. InsertIntoDealLockTest_1(Name) 
    2.     
  
  
  
  2. SelectnameFromsys.all_objects 
    3.     
  
  
  
  3. InsertIntoDealLockTest_2(Name) 
    4.     
  
  
  
  4. SelectnameFromsys.all_objects 
    5.     
  
  
  
  5. Go
    6.

创建好表和插入测试数据后，先执行脚本代码（因为我们不需要跟踪该代码），紧接着，我们就模拟两个会话，一个会话里面包含一个事务。这里我们就新建两个查询，其中***个会话，是更新DealLockTest_1表后，等待5秒钟，更新DealLocktest_2.

    
 
 
 
    
     
  
  
  
  1. UseTest 
    2.      
  
  
  
  2. Go 
    3.      
  
  
  
  3. --***个会话 
    4.      
  
  
  
  4. BeginTran 
    5.      
  
  
  
  5. UpdateDealLockTest_1 
    6.      
  
  
  
  6. SetName=N'test1'
    7.      
  
  
  
  7. WhereID>0 
    8.      
  
  
  
  8. /*这里的Waitfor等待，是为了容易获取死锁的发生*/ 
    9.      
  
  
  
  9. WaitforDelay'00:00:05'
    10.      
  
  
  
  10. UpdateDealLockTest_2 
    11.      
  
  
  
  11. SetName=N'test2'
    12.      
  
  
  
  12. WhereID>0 
    13.      
  
  
  
  13. CommitTran 
    14.      
  
  
  
  14. Go
    15.

代码写好后，我们先不要执行代码，接下来就写第二个会话代码； 第二个会话更新表的顺序，刚好与***个会话相反，是更新DealLockTest_2表后，等待5秒钟，更新DealLocktest_1.

    
 
 
 
    
     
  
  
  
  1. UseTest 
    2.      
  
  
  
  2. Go 
    3.      
  
  
  
  3. --第二个会话 
    4.      
  
  
  
  4. BeginTran 
    5.      
  
  
  
  5. UpdateDealLockTest_2 
    6.      
  
  
  
  6. SetName=N'test1'
    7.      
  
  
  
  7. WhereID>0 
    8.      
  
  
  
  8. /*这里的Waitfor等待，是为了容易获取死锁的发生*/ 
    9.      
  
  
  
  9. WaitforDelay'00:00:05' 
    10.      
  
  
  
  10. UpdateDealLockTest_1 
    11.      
  
  
  
  11. SetName=N'test2'
    12.      
  
  
  
  12. WhereID>0 
    13.      
  
  
  
  13. CommitTran 
    14.      
  
  
  
  14. Go
    15.

第二个会话代码，也先不要执行。

2.启动SQL Server Profiler，创建Trace(跟踪).

启动SQL Server Profiler工具(在Microsoft SQL Server Management Studio的工具菜单上就发现它)，创建一个Trace,Trace属性选择主要是包含:

Deadlock graph Lock: Deadlock Lock: Deadlock Chain RPC:Completed SP:StmtCompleted SQL:BatchCompleted SQL:BatchStarting

点执行按钮，启动Trace。

3.执行测试代码&监视死锁。

转到 Microsoft SQL Server Management Studio界面，执行***个会话&第二个会话的代码，稍稍等待5秒钟，我们就会发现其中一个会话收到报错消息

我们再切换到SQL Server Profiler界面，就能发现SQL Server Profiler收到执行脚本过程发生死锁的信息。

OK,这里就先停止SQL Server Profiler上的“暂停跟踪” Or "停止跟踪"按钮，下面我们具体分析死锁发生过程。

4.分析死锁

如下图，我们可以看到***个会话在SPID 54,第二个会话在SPID 55,一旦SQL Server发现死锁，它就会确定一个优胜者，可成功执行，和另一个作为牺牲品，要回滚。

可以到看到EventClass列中，两条SQL:BatchCompleted事件紧跟在Lock:DealLock后面，其中一条，它就是作为牺牲品，它会被回滚.而另一条SQL:BatchCompleted将会是优胜者，成功执行。

那么，谁是优胜者，谁是牺牲品呢? 不用着急，通过DealLock graph事件，所返回来的信息，我们可以知道结果。

我们虽然不能明白DealLock graph图示的含义，但通过图中描述的关系，我们知道一些有用的信息。图中左右两旁椭圆形相当一个处理节点(Process Node),当鼠标移动到上面的时候，可以看到内部执行的代码，如Insert,UPdate,Delete.有打叉的左边椭圆形就是牺牲者，没有打叉的右边椭圆形是优胜者。中间两个长方形就是一个资源节点(Resource Node)，描述数据库中的对象,如一个表、一行或一个索引。在我们当前的实例中，资源节点描述的是，在聚集索引请求获得排它锁(X)。椭圆形与长方形之间，带箭头的连线表示，处理节点与资源节点的关系，包含描述锁的模式.

接下来我们更详细的看图里面的数据说明。

先看右边作为优胜者的这椭圆形，我们可以看到内容包含有：

服务器进程 ID： 服务器进程标识符 (SPID)，即服务器给拥有锁的进程分配的标识符。服务器批 ID： 服务器批标识符 (SBID)。执行上下文 ID： 执行上下文标识符 (ECID)。与指定 SPID 相关联的给定线程的执行上下文 ID。ECID = {0,1,2,3, ...n}，其中 0 始终表示主线程或父线程，并且 {1,2,3, ...n} 表示子线程。死锁优先级： 进程的死锁优先级有关可能值的详细信息，请参阅 SET DEADLOCK_PRIORITY (Transact-SQL)。已用日志： 进程所使用的日志空间量。所有者 ID： 正在使用事务并且当前正在等待锁的进程的事务 ID。事务描述符： 指向描述事务状态的事务描述符的指针。

这些数据描述，对于我们理解死锁，只需要知道其中的一些就够，除非我们在专门SQL Server机构工作，才可能要深入理解它们。

下面我们来看左边作为牺牲品的这椭圆形处理节点，它告诉我们以下信息：

1.它是一个失败的事务。（蓝色的交叉表示）

2.它是作为牺牲品的T-SQL代码。

3.它对右下方的资源节点有一个排它锁(X).

4.它对右上方的资源节点请求 一个排它锁（X）.

我们再来看中间两个长方形的资源节点,两个处理节点对它们各自都使用权，来执行它们各自的代码，同时又有对对方使用资源请求的动作，从而发生了资源的竞争。

这也就让我们明白死锁发生的原因。

这里说明下资源节点的一些信息：

HoBT：　　堆或 B 树。 用于保护没有聚集索引的表中的 B 树（索引）或堆数据页的锁

associated objid: 关联的对象ID,这里只是索引关联的对象ID.

Index name:索引名

让我们再对SQL Server Profiler监视到的数据，作一次整理：

回顾图：

1.在第3行SQL:BatchStarting, SPID 54 （***个会话启动）,在索引PK__DealLock__3214EC274222D4EF获得一个排它锁，再处理等待状态，(因为在这个实例中我设置了Waitfor Delay '00:00:05')

2.在第6行SQL:BatchStarting, SPID 55 （第二个会话启动）,在索引PK__DealLock__3214EC2745F365D3获得一个排它锁，再处理等待状态，(因为在这个实例中我设置了Waitfor Delay '00:00:05')

3.两个进程都各自获得一个排它锁(X),几秒过去，它们就开始请求排它锁。

SPID 54 （***个会话）,先对PK__DealLock__3214EC2745F365D3请求一个排它锁(X),但PK__DealLock__3214EC2745F365D3当前已经给SPID 55 （第二个会话）获得。SPID 54要于等待。

同时，

SPID 55 （第二个会话）,开始对PK__DealLock__3214EC274222D4EF请求一个排它锁(X),但PK__DealLock__3214EC274222D4EF当前已经给SPID 54 （***个会话）获得。SPID 55要等待。

这里就出现了进程阻塞，从而发生死锁。

4.SQL Server 检查到这两个进程(***个&第二个会话)发生死锁，并对占用资源比较少的进程，列入牺牲品名单，将它终止（Kill）。通过左右椭圆形进程节点显示，可以发现已用日志最少的是左边的进程节点。

5. SPID 54 （***个会话）被回滚(Rollback)，SPID 55 （第二个会话）执行成功。

到这里我们已算完成了，对死锁的监视和分析。

（注：是于其他死锁的定义，死锁模式，死锁避免&预防,等等，不是本文重点，我没有提出,网上太多这方面的文章）

文章题目：详解SQLServerProfiler分析死锁几大步骤
网址分享：http://www.shufengxianlan.com/qtweb/news21/259871.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

服务器托管知识

分类信息网站

虚拟主机　　 　网站seo优化　　 　移动APP　　 　高防机房　　 　网站排名优化　　 　微信小程序　　 　成都电信服务器托管　　 　主机托管　　 　成都水电改造　　 　手机网站建设　　 　网络口碑营销　　 　邛崃网站建设　　 　成都租用服务器　　 　四川艾名斯　　 　成都小程序开发　　 　眉山电信机房托管　　 　绵阳梓潼网站建设　　 　成都网站运营维护　　 　雪茄烟品牌　　 　网上商城管理系统