如何分析 Azure SQL 死锁？答案

【问题标题】：How to profile azure SQL deadlocks?如何分析 Azure SQL 死锁？
【发布时间】：2013-03-19 15:14:53
【问题描述】：

我知道有人问过这个问题here，但 1) 它相对较旧，2) 它对我没有多大帮助。

在我的数据库上进行一些操作时，我遇到了相对大量的死锁。设置如下：

表格：

表 A 用外键插入表 B。

操作：

插入表A

插入表B

更新表 B 中的行

删除表 B 中的行

删除表 A 中的行

问题：

这些操作基本上可以按任何顺序发生，因为我有多个工作角色，所以这些操作必须是幂等的，但是，每个工作角色将使用表 A 中的不同主键。我仍在努力解决问题表上锁的概念，据我了解，A 上的任何删除都将首先锁定表 B，在那里删除相关行，然后从 A 中删除行。我目前认为这是一个原子操作，没有时间执行锁定表 B 和锁定表 A 之间的额外锁，因为我无法想象有办法解决这个问题。

我目前能够在 Microsoft Visual Studio 中捕获以下格式的异常：

事务（进程 ID xxx）在锁资源上与另一个进程死锁，并已被选为死锁牺牲品。重新运行事务。

此异常似乎可能发生在上述任何操作中。

我的问题是：我如何知道哪些锁/事务是导致死锁的？有谁知道在我们得到异常后有用的任何查询？

【问题讨论】：

级联删除的流程是什么。你有[ ON DELETE CASCADE ]？如果是这样，我会取消它并在您拥有更多控制权的存储过程中执行此操作。对于一个明确的行锁。
是的，是级联删除。我会看看删除级联是否适合我们。
您的堆栈跟踪应该告诉您代码的哪一部分导致了死锁。查看所有堆栈跟踪，您可能会注意到死锁错误可能发生在多个点。

标签： tsql azure azure-sql-database

【解决方案1】：

sys.event_log 是这里的答案。

它存在于您服务器的主数据库中，并且应该包含一个条目，其中包含您的数据库在上个月遇到的所有死锁图。

有了死锁图，sql serverdeadlock graph debugging上有很多教程。

【讨论】：

这是迄今为止最简单的方法。下面的查询完成了这项工作，尽管文件在更改后需要一些时间来更新（约 10 分钟）。 select * from sys.event_log where event_type='deadlock' and database_name = 'system-' order by start_time desc
对于那些像我一样愚蠢的人，强调“MASTERDB”——你的数据库特定的 sys.event_logs 将不包含关于锁的信息。

【解决方案2】：

目前几乎不存在用于 Sql Azure 的分析工具。

标准 Sql Server 和 Sql Azure 世界之间的锁定问题应该没有太大区别，因此我建议尝试使用标准技术（例如良好的旧 Profiler）在“旧”世界中重现该问题：非常有用 article & @ 987654322@.

如果这种方法没有被证明是有效的，那么一个肮脏的解决方案可能是使用 catch/retry logic。

【讨论】：

【解决方案3】：

我最近遇到了类似的问题。尝试通过“with (UPDLOCK)”使用您的更新。

【讨论】：

【解决方案4】：

尝试找出根本原因：

首先只运行一个辅助角色。

然后检查：

您是否锁定在正确级别的表锁、页锁或行锁？
您要释放锁吗？
您的系统是否以这样一种方式设计，即对同一行的所有编辑都将由同一台机器完成？

这里有一篇关于查找阻塞查询的博文：http://blogs.msdn.com/b/sqlazure/archive/2010/08/13/10049896.aspx

【讨论】：