以下的文章主要向大家讲述的是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 死锁检测和结束死锁的介绍，望你能有所收获。