通过SQL Server Profiler来监视分析死锁

核心提示： 让我们再对SQL Server Profiler监视到的数据，作一次整理：回顾图：1. 在第3行SQL:BatchStarting, SPID 54 （第一个会话启动）,在索引PK__DealLock__3214EC274222D4EF获得一个排它锁，通过SQL Server Profiler来

让我们再对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 （第二个会话）执行成功。

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

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