检测及结束死锁.docVIP

检测和结束死锁 在两个或多个任务中，如果每个任务锁定了其他任务试图锁定的资源，此时会造成这些任务永久阻塞，从而出现死锁。下图清楚地显示了死锁状态，其中： 任务 T1 具有资源 R1 的锁（通过从 R1 指向 T1 的箭头指示），并请求资源 R2 的锁（通过从 T1 指向 R2 的箭头指示）。 任务 T2 具有资源 R2 的锁（通过从 R2 指向 T2 的箭头指示），并请求资源 R1 的锁（通过从 T2 指向 R1 的箭头指示）。 因为这两个任务都需要有资源可用才能继续，而这两个资源又必须等到其中一个任务继续才会释放出来，所以陷入了死锁状态。 SQL Server 数据库引擎自动检测 SQL Server 中的死锁循环。数据库引擎选择一个会话作为死锁牺牲品，然后终止当前事务（出现错误）来打断死锁。 可以死锁的资源 每个用户会话可能有一个或多个代表它运行的任务，其中每个任务可能获取或等待获取各种资源。以下类型的资源可能会造成阻塞，并最终导致死锁。 锁。等待获取资源（如对象、页、行、元数据和应用程序）的锁可能导致死锁。例如，事务 T1 在行 r1 上有共享锁（S 锁）并等待获取行 r2 的排他锁（X 锁）。事务 T2 在行 r2 上有共享锁（S 锁）并等待获取行 r1 的排他锁（X 锁）。这将导致一个锁循环，其中，T1 和 T2 都等待对方释放已锁定的资源。 工作线程。排队等待可用工作线程的任务可能导致死锁。如果排队等待的任务拥有阻塞所有工作线程的资源，则将导致死锁。例如，会话 S1 启动事务并获取行 r1 的共享锁（S 锁）后，进入睡眠状态。在所有可用工作线程上运行的活动会话正尝试获取行 r1 的排他锁（X 锁）。因为会话 S1 无法获取工作线程，所以无法提交事务并释放行 r1 的锁。这将导致死锁。 内存。当并发请求等待获得内存，而当前的可用内存无法满足其需要时，可能发生死锁。例如，两个并发查询（Q1 和 Q2）作为用户定义函数执行，分别获取 10MB 和 20MB 的内存。如果每个查询需要 30MB 而可用总内存为 20MB，则 Q1 和 Q2 必须等待对方释放内存，这将导致死锁。 并行查询执行的相关资源。通常与交换端口关联的处理协调器、发生器或使用者线程至少包含一个不属于并行查询的进程时，可能会相互阻塞，从而导致死锁。此外，当并行查询启动执行时，SQL Server 将根据当前的工作负荷确定并行度或工作线程数。如果系统工作负荷发生意外更改，例如，当新查询开始在服务器中运行或系统用完工作线程时，则可能发生死锁。 多个活动的结果集 (MARS) 资源。这些资源用于控制在 MARS 下交叉执行多个活动请求（请参阅批处理执行环境和 MARS）。 用户资源。线程等待可能被用户应用程序控制的资源时，该资源将被视为外部资源或用户资源，并将按锁进行处理。 会话互斥体。在一个会话中运行的任务是交叉的，意味着在某一给定时间只能在该会话中运行一个任务。任务必须独占访问会话互斥体，才能运行。 事务互斥体。在一个事务中运行的所有任务是交叉的，意味着在某一给定时间只能在该事务中运行一个任务。任务必须独占访问事务互斥体，才能运行。 任务必须获取会话互斥体，才能在 MARS 下运行。如果任务在事务下运行，则它必须获取事务互斥体。这将确保在某一给定会话和给定事务中一次仅有一个任务处于活动状态。获取所需互斥体后，任务就可以执行了。任务完成或在请求过程中生成时，它将按获取的相反顺序先释放事务互斥体，然后释放会话互斥体。但是，这些资源可能导致死锁。在下面的代码示例中，两个任务（用户请求 U1 和用户请求 U2）在同一会话中运行。 复制 U1: Rs1=Command1.Execute(insert sometable EXEC usp_someproc); U2: Rs2=Command2.Execute(select colA from sometable); 用户请求 U1 执行的存储过程已获取会话互斥体。如果执行该存储过程花费了很长时间，则数据库引擎会认为存储过程正在等待用户的输入。用户等待 U2 的结果集时，用户请求 U2 正在等待会话互斥体，U1 正在等待用户资源。死锁状态的逻辑说明如下： 死锁检测 上面列出的所有资源均参与数据库引擎死锁检测方案。死锁检测是由锁监视器线程执行的，该线程定期搜索数据库引擎实例的所有任务。以下几点说明了搜索进程： 默认时间间隔为 5 秒。 如果锁监视器线程查找死锁，根据死锁的频率，死锁检测时间间隔将从 5 秒开始减小，最小为 100 毫秒。 如果锁监视器线程停止查找死锁，数据库引擎将两个搜索间的时间间隔增加到 5 秒。 如果刚刚检测到死锁，则假定必须等待锁的下一个线程正进入死锁循环。检测到死锁后，第一对锁等待将