文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

SQL Server的死锁说明

2023-04-12 11:48

关注

一、了解死锁

死锁是导致数据库中的竞争性并发锁,通常在多步骤事务中。
当两个或多个任务永久相互阻止时,每个任务都锁定了其他任务尝试锁定的资源,就会发生死锁。例如:

事务 A 在事务 B 完成之前无法完成,但事务 B 被事务 A 阻止。此条件也称为循环依赖关系:事务 A 依赖于事务 B,事务 B 通过对事务 A 的依赖来关闭循环。

死锁中的两个事务将永远等待,除非死锁被外部进程打破。SQL Server 数据库引擎死锁监视器定期检查处于死锁状态的任务。如果监视器检测到循环依赖关系,它将选择其中一个任务作为受害者,并在出现错误的情况下终止其事务。这允许其他任务完成其事务。具有因错误而终止的事务的应用程序可以重试该事务,该事务通常在另一个死锁事务完成后完成。

死锁经常与正常阻塞混淆。当一个事务请求锁定另一个事务锁定的资源时,请求事务将等待,直到锁定被释放。默认情况下,除非设置了LOCK_TIMEOUT,否则 SQL Server 事务不会超时。请求事务被阻止,而不是死锁,因为请求事务没有执行任何操作来阻止拥有锁的事务。最终,拥有事务将完成并释放锁,然后请求事务将被授予锁定并继续。死锁几乎可以立即解决,而阻塞理论上可以无限期地持续存在。僵局有时被称为致命的拥抱。

死锁是可能发生在具有多个线程的任何系统上的情况,而不仅仅是在关系数据库管理系统上,并且可能发生在数据库对象上的锁以外的资源上。例如,多线程操作系统中的线程可能会获取一个或多个资源,例如内存块。如果要获取的资源当前由另一个线程拥有,则第一个线程可能必须等待拥有该线程释放目标资源。据说等待线程依赖于该特定资源的拥有线程。在 SQL Server 数据库引擎实例中,会话在获取非数据库资源(如内存或线程)时可能会死锁。

SQL Server的死锁说明

在图中,事务 T1 依赖于表锁资源的事务 T2。同样,事务 T2 依赖于表锁资源的事务 T1。由于这些依赖项形成一个循环,因此事务 T1 和 T2 之间存在死锁。

当对表进行分区并将 的设置设置为 AUTO 时,也会发生死锁。设置为 AUTO 时,通过允许 SQL Server 数据库引擎在 HoBT 级别而不是表级别锁定表分区,并发性会增加。但是,当单独的事务在表中持有分区锁并希望在其他事务分区上的某个位置使用锁时,这会导致死锁。这种类型的死锁可以通过设置为 ;尽管此设置将通过强制对分区进行大量更新以等待表锁定来降低并发性。

二、检测并结束死锁

当两个或多个任务永久相互阻止时,每个任务都锁定了其他任务尝试锁定的资源,就会发生死锁。下图显示了死锁状态的高级视图,其中:

SQL Server的死锁说明

SQL Server 数据库引擎会自动检测 SQL Server 中的死锁周期。SQL Server 数据库引擎选择其中一个会话作为死锁受害者,当前事务将终止,并显示错误以打破死锁。

2.1、可能死锁的资源

每个用户会话可能代表其运行一个或多个任务,其中每个任务可能获取或等待获取各种资源。以下类型的资源可能会导致阻塞,从而导致死锁。

为了使任务在 MARS 下运行,它必须获取会话互斥锁。如果任务在事务下运行,则必须获取事务互斥锁。这保证在给定会话和给定事务中一次只有一个任务处于活动状态。获取所需的互斥锁后,任务就可以执行。当任务完成或在请求中间产生时,它将首先释放事务互斥锁,然后以相反的获取顺序释放会话互斥锁。但是,这些资源可能会发生死锁。在以下伪代码中,两个任务(用户请求 U1 和用户请求 U2)在同一会话中运行。

从用户请求 U1 执行的存储过程已获取会话互斥锁。如果存储过程需要很长时间才能执行,则 SQL Server 数据库引擎假定存储过程正在等待用户的输入。用户请求 U2 正在等待会话互斥锁,而用户正在等待来自 U2 的结果集,U1 正在等待用户资源。这是死锁状态,逻辑上说明为:

SQL Server的死锁说明

三、处理死锁

当 SQL Server 数据库引擎实例选择某个事务作为死锁受害者时,它将终止当前批处理,回滚该事务,并向应用程序返回错误消息 1205。

由于提交 Transact-SQL 查询的任何应用程序都可以被选为死锁受害者,因此应用程序应具有可以捕获错误消息 1205 的错误处理程序。如果应用程序未捕获错误,则应用程序可以在不知道其事务已回滚并可能发生错误的情况下继续操作。

实现捕获错误消息 1205 的错误处理程序允许应用程序处理死锁情况并采取补救措施(例如,自动重新提交死锁中涉及的查询)。通过自动重新提交查询,用户无需知道发生了死锁。

在重新提交查询之前,应用程序应短暂暂停。这使死锁中涉及的其他事务有机会完成并释放构成死锁循环一部分的锁。这样可以最大程度地降低在重新提交的查询请求其锁时再次发生死锁的可能性。

四、最大限度地减少死锁

尽管无法完全避免死锁,但遵循某些编码约定可以最大程度地减少生成死锁的可能性。最小化死锁可以提高事务吞吐量并减少系统开销,因为事务较少:

要帮助最大程度地减少死锁,请执行以下操作:

4.1、以相同的顺序访问对象

如果所有并发事务都以相同的顺序访问对象,则不太可能发生死锁。例如,如果两个并发事务在表上获取锁,然后在表上获得锁,则一个事务在表上被阻止,直到另一个事务完成。第一个事务提交或回滚后,第二个事务将继续,并且不会发生死锁。对所有数据修改使用存储过程可以标准化访问对象的顺序。

SQL Server的死锁说明

4.2、避免事务中的用户交互

避免编写包含用户交互的事务,因为无需用户干预即可运行的批处理的速度比用户必须手动响应查询(例如回复应用程序请求的参数提示)的速度快得多。例如,如果事务正在等待用户输入,并且用户周末去吃午饭甚至回家,则用户会延迟事务完成。这会降低系统吞吐量,因为事务持有的任何锁仅在提交或回滚事务时释放。即使没有出现死锁情况,访问相同资源的其他事务也会在等待事务完成时被阻止。

4.3、保持交易简短且在一个批次中

当多个长时间运行的事务在同一数据库中同时执行时,通常会发生死锁。事务时间越长,独占锁或更新锁的持有时间就越长,从而阻止其他活动并导致可能的死锁情况。

将事务保存在一个批次中可最大程度地减少事务期间的网络往返,从而减少完成事务和释放锁定时可能出现的延迟。

4.4、使用较低的隔离级别

确定事务是否可以在较低的隔离级别运行。实现 read commit 允许事务读取先前由另一个事务读取(未修改)的数据,而无需等待第一个事务完成。与较高的隔离级别(如可序列化)相比,使用较低的隔离级别(如已提交的读取)保留共享锁的持续时间更短。这减少了锁定争用。

4.5、使用基于行版本控制的隔离级别

当数据库选项设置为 ON 时,在读取提交隔离级别下运行的事务在读取操作期间使用行版本控制而不是共享锁。
快照隔离还使用行版本控制,在读取操作期间不使用共享锁。在事务可以在快照隔离下运行之前,必须设置数据库选项ALLOW_SNAPSHOT_ISOLATIONON。

实现这些隔离级别,以最大程度地减少读取和写入操作之间可能发生的死锁。

4.6、使用绑定连接

使用绑定连接,同一应用程序打开的两个或多个连接可以相互协作。辅助连接获取的任何锁都像由主连接获取一样保存,反之亦然。因此,它们不会相互阻塞。

4.7、停止事务

在死锁方案中,受害事务会自动停止并回滚。在死锁情况下无需停止事务。

总结

有些应用程序依赖于读取提交隔离的锁定和阻止行为。对于这些应用程序,在启用使用基于行版本控制的隔离级别之前需要进行一些更改。

以上就是SQL Server的死锁说明的详细内容,更多关于SQL Server死锁的资料请关注我们其它相关文章!

阅读原文内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-数据库
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯