SQL Server 死锁检测与结束死锁

　　以下的文章主要向大家讲述的是SQL Server 死锁检测与结束死锁得实际操作过程，我们大家都知道在 Microsoft® SQL Server™ 2000 数据库中，单个用户会话都可能有一个或多个代表它运行的线程  。每个线程可能获取或等待获取各种资源，如：

　　锁  。

　　与并行查询执行相关的资源（与交换端口相关联的处理协调器、发生器和使用者线程）  。

　　线程  。

　　内存  。

　　上述这些资源除内存外都参与 SQL Server 死锁检测方案  。对于内存，SQL Server 使用基于超时的机制，该机制由 sp_configure 中的 query wait 选项控制  。

　　在 SQL Server 2000 中，SQL Server 死锁检测由一个称为锁监视器线程的单独的线程执行  。在出现下列任一情况时，锁监视器线程对特定线程启动死锁搜索：

　　·线程已经为同一资源等待了一段指定的时间  。锁监视器线程定期醒来并识别所有等待某个资源的线程  。如果锁监视器再次醒来时这些线程仍在等待同一资源，则它将对等待线程启动锁搜索  。

　　·线程等待资源并启动急切的死锁搜索  。

　　SQL Server 通常只执行定期死锁检测，而不使用急切模式  。因为系统中遇到的死锁数通常很少，定期死锁检测有助于减少系统中死锁检测的开销  。

　　当锁监视器对特定线程启动SQL Server 死锁检测时，它识别线程正在等待的资源  。然后，锁监视器查找特定资源的拥有者，并递归地继续执行对那些线程的死锁搜索，直到找到一个循环  。用这种方式识别的循环形成一个死锁  。

　　在识别死锁后，SQL Server 通过自动选择可以打破死锁的线程（死锁牺牲品）来结束死锁  。SQL Server 回滚作为死锁牺牲品的事务，通知线程的应用程序（通过返回 1205 号错误信息），取消线程的当前请求，然后允许不间断线程的事务继续进行  。

　　SQL Server 通常选择运行撤消时花费最少的事务的线程作为死锁牺牲品  。另外，用户可以使用 SET 语句将会话的 DEADLOCK_PRIORITY 设置为 LOW  。DEADLOCK_PRIORITY 选项控制在死锁情况下如何衡量会话的重要性  。如果会话的设置为 LOW ，则当会话陷入死锁情况时将成为首选牺牲品  。

　　识别死锁：识别死锁后，SQL Server 选择特定的线程作为死锁牺牲品，并返回一条列出死锁中涉及的资源的错误信息  。该死锁信息采用下列形式：

　　Your transaction (process ID #52) was deadlocked>死锁中涉及的线程和资源位于错误日志中  。

　　以上的相关内容就是对SQL Server 死锁检测和结束死锁的介绍，望你能有所收获  。