[V11功能解说] 用户是否收到关于锁定记录或报错后回滚的消息，你可能有死锁问题

lynn.yu

* 本文由赛捷软件（上海）有限公司翻译完成，未经授权不得转载。如需转载，请先联系相应版块的版主取得授权。


用户感到沮丧，并报告收到随机报错，迫使他们重新录入他们的工作。如果你是那个要解决他们的报错的人，那么对于这样一个看似随机又没有什么详细背景的报错，你该从哪里着手呢？可以指望的一个方面是死锁事件。


什么是死锁？

死锁通常发生在两个或以上的任务永久互相锁定的情况下，因为每个任务都锁定了其他任务试图锁定的资源。

例如：
•        交易A在第1行获得了共享锁。
•        交易B在第2行获得了共享锁。
•        交易A现在请求第2行上的独占锁，并被阻止，需等到交易B完成并释放它在第2行上拥有的共享锁为止。
•        交易B现在请求第1行上的独占锁，并被阻止，需等到交易A完成并释放它在第1行上拥有的共享锁为止。

在交易B完成前交易A都无法完成，但交易B又被交易A锁定了。这种情况也称为循环依赖。



幸运的是，交易不会永远被锁定；SQL server非常智能，能够识别这种情况，并杀死其中一个进程，以便让另一个可以继续执行。

结果是，被选为牺牲者的用户很可能会看到一条报错消息。它看起来可能类似于：




我是否遇到了死锁？

以前，在SQL Server 2008中，为了捕获死锁，我们必须创建一个服务器端/事件探查器跟踪或使用追踪标识1204和1222。自SQL Server 2012起，增加了一个新的功能，使得在环境中识别死锁变得非常简单。

默认运行着一个名为system_health的扩展事件会话，可以自动捕捉死锁事件。

您也可以在我们的知识库中查看KB ID 84406 (我如何确定死锁事件是否发生在Sage X3上？)
1.        登录到Microsoft SQL Server管理工作室（SSMS）。
2.        展开“管理”文件夹
3.        展开“扩展事件”
4.        展开“会话”
5.        展开“system_health”请注意：system_health是一个默认始终运行的会话
6.        双击package0.event_file
7.        点击“筛选器”，并添加一个筛选条件，已查找xml_deadlock_report，例如
1)        字段= name
2)        操作符 = Contains
3)        值 = deadlock
8.        突出显示相关报表
9.        双击xml_report，查看【明细】选项上涉及的查询的xml内容

你也可以从SQL Server日志文件位置收集system_health.xel文件。类似于。



为了直观地显示，请查看“死锁”选项卡



注：该图与上面的死锁图非常相似。


下一步呢？

这可能是SQL Server数据库管理员排除故障的一个有价值的入手点。有许多潜在的原因和解决方案。你将需要与你的SQL DBA合作来确定最佳的行动方案。

例如，你可能需要复查xml_deadlock_report中报告的查询，并复查其查询计划。如果你可以重现这么问题，那么你可能会想要运行一些扩展事件追踪。你可以在知识库中查看我们的KB ID 83828（Microsoft扩展事件和Sage X3）。

解决的方法可能很简单，就像把一个非聚类索引改为聚类索引那样简单。这是知识库文章KB ID 84409的一个示例。

使用死锁事件详细信息确定查询使用了表扫描。通过改变索引，我们改变了查询计划，从而消除了死锁的可能性。



与往常一样，你可能希望记住其他性能故障排除方法，并查看知识库中的KB ID 76348（如何解决Sage X3性能慢的问题？）