SQL Azure - 一个会话锁定整个数据库进行更新和插入

Question

SQL Azure - 一个会话锁定整个数据库进行更新和插入

10

SQL Azure出现问题。

我们的(asp.net)网站上出现以下异常：

操作超时。在操作完成之前超时期已过或者服务器未响应。语句已终止。

它还导致SMSS中的更新和插入语句无法完成。查询sys.dm_tran_locks时不存在X或IX锁，查询sys.dm_tran_active_transactions或sys.dm_tran_database_transactions时也不存在任何事务。

该问题存在于数据库中的每个表中，但是同一实例上的其他数据库不会引起此问题。问题的持续时间可能从2分钟到2小时不等，并且不会在任何特定的一天时间发生。

数据库没有满。

有一次我无法解决这个问题，但我能够通过查询sys.dm_exec_connections找到最长运行的会话，然后将其结束来解决问题。奇怪的是，该连接已经存在15分钟了，但锁定问题已经存在了3个多小时。

还有其他什么我可以检查吗？

编辑

根据Paul以下的答案。实际上，在他回答之前我已经跟踪到了问题。如果以下步骤对其他人有帮助，我将在下面发布我用于解决此问题的步骤。

当出现"超时期"时，运行以下查询：

select *  from sys.dm_exec_requests

请求统计信息

我们可以看到，所有的WAIT请求都在等待会话1021，而该会话是复制请求！TM Request表示DTC事务，我们不使用分布式事务。您还可以看到SE_REPL_COMMIT_ACK的等待类型，这再次说明了复制。

select * from  sys.dm_tran_locks

在这里输入图片描述

再次等待会话1021

SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc

enter image description here

是的，SE_REPL_CATCHUP_THROTTLE 的总等待时间为8094034毫秒，即134.9分钟！！！

另请参阅以下论坛以了解此问题的详细信息。 http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8

我在与 Microsoft 交流中得到了以下答复（我们在欧盟数据中心的15个数据库中有4个出现了此问题）：

问题：在过去的三周内，这些软限制是否有更改，即自我的问题开始以来？

答案：没有。

问题：有什么方法可以防止或警告我们接近限制？

答案：没有。该问题可能不是由您的应用程序引起的，而可能是由依赖于相同物理硬件的其他租户引起的。换句话说，您的应用程序可能负载很少，但仍可能遇到问题。换句话说，您自己的流量可能是此问题的原因，但同样也可能是依赖于相同物理硬件的其他租户引起的。没有办法事先知道问题将很快发生 - 它可能随时发生而没有警告。SQL Azure 运营团队不监视此类错误，因此他们不会自动尝试为您解决问题。因此，如果您遇到问题，有两个选择：

创建数据库的副本并使用它，并希望 DB 放置在负载较轻的另一台服务器上。

联系 Windows Azure 支持，并告知他们有关问题，让他们为您执行选项 1。

- Sam Shiles

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Paul DB · Accepted Answer

您可能遇到了SE_REPL *问题，这些问题目前困扰着许多使用Sql Azure的人（包括我们公司）。

当您遇到超时时，请检查等待请求是否有以下等待类型：

- SE_REPL_SLOW_SECONDARY_THROTTLE - SE_REPL_COMMIT_ACK

运行以下命令以检查当前连接中的等待类型：

SELECT TOP 10 r.session_id, r.plan_handle,
r.sql_handle, r.request_id,
r.start_time, r.status,
r.command, r.database_id,
r.user_id, r.wait_type,
r.wait_time, r.last_wait_type,
r.wait_resource, r.total_elapsed_time,
r.cpu_time, r.transaction_isolation_level,
r.row_count
FROM sys.dm_exec_requests r

您可以通过运行以下命令来查看此类历史记录：

SELECT * FROM sys.dm_db_wait_stats
ORDER BY wait_time_ms desc

如果您看到了大量的SE_REPL*等待类型，并且这些等待类型在连接上停留了任意长度的时间，那么基本上您就完了。微软已经意识到了这个问题，但是我现在已经向他们提交了一份支持票据已经有一个星期了，他们似乎还在努力解决中。

当Sql Azure复制从属服务器落后时，SE_REPL*等待就会发生。基本上，在复制追上之前，整个数据库都会暂停查询 :/

因此，使Sql Azure高度可用的方面实际上导致数据库变得随机不可用。如果这不是在害死我们，我会为这种讽刺而笑。

请参考以下线程获取详细信息： http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8