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

Question

SQL Azure 问题。

我遇到了一个问题，在我们的 (asp.net) 网站上表现为以下异常:

Timeout expired. The timeout period elapsed prior to completion ofthe operation or the server is not responding. The statement has beenterminated.

这还会导致 SMSS 中的更新和插入语句永远无法完成。查询时不存在任何 X 或 IX 锁:sys.dm_tran_locks查询sys.dm_tran_active_transactions时没有任何交易或sys.dm_tran_database_transactions .

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

数据库未满。

此问题一度未能自行解决，但我能够通过查询 sys.dm_exec_connections 解决该问题找到运行时间最长的 session ，然后终止它。奇怪的是，连接已经建立了 15 分钟，但锁定问题已经存在了 3 个多小时。

还有什么我可以检查的吗？

编辑

正如下面保罗的回答。在他回答之前我实际上已经找到了问题所在。我将在下面发布我用来解决此问题的步骤，以防对其他人有所帮助。

存在“超时期限”时运行以下查询。

select *  from sys.dm_exec_requests

正如我们所看到的，所有 WAIT 请求都在 session 1021 上等待，这是复制请求! TM Request表示DTC事务，我们不使用分布式事务。还可以看到SE_REPL_COMMIT_ACK的wait_type这再次暗示了复制。

select * from  sys.dm_tran_locks

再次等待 session 1021

SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc

是的，SE_REPL_CATCHUP_THROTTLE总等待时间为 8094034ms，那就是134.9分钟!!!

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

I've been given the following answer in my communication withMicrosoft (we've seen this issue with 4 of our 15 databases in the EUdata center):

Question: Have there been changes to these softthrottling limits in the last three weeks ie since my problemsstarted?

Answer: No, there has not.

Question: Are there ways we canprevent or be warned we are approaching a limit?

Answer: No. The issuemay not be caused by your application but can be caused by othertenants relying on the same physical hardware. In other words, yourapplication can have very little load and still run into the problem.In other words, your own traffic may be a cause of this problem, butit can just as well be caused by other tenants relying on the samephysical hardware. There's no way to know beforehand that the issuewill soon occur - it can occur at any time without warning. The SQLAzure operations team does not monitor this type of error, so theywon't automatically try to solve the problem for you. So if you runinto it you have two opitions:

1. Create a copy of your db and use that and hope the db is placed on another server with less load.

2. Contact Windows Azure Support and inform the about the problem and let them do Option 1 for you

Answer 1

您可能会遇到 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* 等待就会发生。基本上整个数据库在复制 catch 时暂停查询:/

因此，本质上使 Sql Azure 具有高可用性的方面是导致数据库随机不可用。如果这不是要了我们的命，我会 mock 这个讽刺。

查看此线程以了解详细信息: http://social.technet.microsoft.com/Forums/en-US/ssdsgetstarted/thread/c3003a28-8beb-4860-85b2-03cf6d0312a8