[V11功能解说] 用户是否收到关于锁定记录或报错后回滚的消息，你可能有死锁问题
[b]* 本文由赛捷软件（上海）有限公司翻译完成，未经授权不得转载。如需转载，请先联系相应版块的版主取得授权。[/b]用户感到沮丧，并报告收到随机报错，迫使他们重新录入他们的工作。如果你是那个要解决他们的报错的人，那么对于这样一个看似随机又没有什么详细背景的报错，你该从哪里着手呢？可以指望的一个方面是死锁事件。
[b]什么是死锁？[/b]
死锁通常发生在两个或以上的任务永久互相锁定的情况下，因为每个任务都锁定了其他任务试图锁定的资源。
例如：
• 交易A在第1行获得了共享锁。
• 交易B在第2行获得了共享锁。
• 交易A现在请求第2行上的独占锁，并被阻止，需等到交易B完成并释放它在第2行上拥有的共享锁为止。
• 交易B现在请求第1行上的独占锁，并被阻止，需等到交易A完成并释放它在第1行上拥有的共享锁为止。
在交易B完成前交易A都无法完成，但交易B又被交易A锁定了。这种情况也称为循环依赖。
[attach]6530[/attach]
幸运的是，交易不会永远被锁定；SQL server非常智能，能够识别这种情况，并杀死其中一个进程，以便让另一个可以继续执行。
结果是，被选为牺牲者的用户很可能会看到一条报错消息。它看起来可能类似于：
[attach]6531[/attach]
[b]我是否遇到了死锁？[/b]
以前，在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文件。类似于。
[attach]6532[/attach]
为了直观地显示，请查看“死锁”选项卡
[attach]6533[/attach]
注：该图与上面的死锁图非常相似。
[b]下一步呢？[/b]
这可能是SQL Server数据库管理员排除故障的一个有价值的入手点。有许多潜在的原因和解决方案。你将需要与你的SQL DBA合作来确定最佳的行动方案。
例如，你可能需要复查xml_deadlock_report中报告的查询，并复查其查询计划。如果你可以重现这么问题，那么你可能会想要运行一些扩展事件追踪。你可以在知识库中查看我们的KB ID 83828（Microsoft扩展事件和Sage X3）。
解决的方法可能很简单，就像把一个非聚类索引改为聚类索引那样简单。这是知识库文章KB ID 84409的一个示例。
使用死锁事件详细信息确定查询使用了表扫描。通过改变索引，我们改变了查询计划，从而消除了死锁的可能性。
[attach]6534[/attach]
与往常一样，你可能希望记住其他性能故障排除方法，并查看知识库中的KB ID 76348（如何解决Sage X3性能慢的问题？）
页:
[1]