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

SQLAzure问题

我在（asp.net）网站上遇到了一个问题，表现为以下异常：

超时已过期。完成之前的超时时间 操作或服务器没有响应。声明已被修改 终止

它还会导致update和insert语句在SMS中永远无法完成。查询时不存在任何X或IX锁：

sys.dm\u trans\u锁

，查询

sys.dm\u trans\u活动事务

或

sys.dm\u trans\u数据库事务

时不存在事务

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

数据库未满

有一次，这个问题没有自行解决，但我通过查询sys.dm_exec_connections找到运行时间最长的会话，然后将其终止，从而解决了这个问题。奇怪的是，连接时间为15分钟，但锁问题已经存在了3个多小时

还有什么我可以查的吗

编辑

根据保罗下面的回答。事实上，在他回答之前，我已经找到了问题所在。我将在下面公布我用来解决这个问题的步骤，以防它们对其他人有所帮助

当存在“超时时间”时，会运行以下查询

select *  from sys.dm_exec_requests

如我们所见，所有等待请求都在会话1021上等待，会话1021是复制请求！

TM请求

表示DTC事务，我们不使用分布式事务。您还可以看到

SE\u REPL\u COMMIT\u ACK

的wait\u类型，它再次暗示了复制

select * from  sys.dm_tran_locks

再次等待会话1021

SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc

是的，

SE_REPL_CATCHUP_THROTTLE

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

有关此问题的详细信息，请参见以下论坛。

在我与客户的沟通中，我得到了以下答案 微软（我们在欧盟的15个数据库中有4个出现了这个问题 数据中心）：

问：这些软件是否有变化 在过去的三个星期里（自从我的问题发生后）限制 开始

答：没有

问题：我们有办法吗 防止或被警告我们正在接近极限

答:没有,问题出在哪里? 可能不是由您的应用程序引起的，但也可能是由其他原因引起的 依赖相同物理硬件的租户。换句话说，你的 应用程序的负载很小，但仍然会遇到问题。 换句话说，您自己的流量可能是导致此问题的原因，但是 这也可能是由于其他租户依赖同样的服务造成的 物理硬件。没有办法事先知道这个问题 将很快发生-它可以在没有警告的情况下随时发生。SQL Azure操作团队不监视此类错误，因此 不会自动尝试为您解决问题。所以如果你跑 你有两种观点：

创建一个数据库副本并使用它，希望该数据库放在另一台负载较少的服务器上

请与Windows Azure支持部门联系，并将问题告知，让他们为您执行选项1

---

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

当您遇到超时时，请尝试检查您的等待请求，以了解以下类型的等待：

• SE_REPL_SLOW_SECONDARY_油门
• 请回复提交确认

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

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

如果你看到很多seu REPL*等待类型，并且这些类型在你的连接上停留了任何时间，那么基本上你就完蛋了。 微软已经意识到了这个问题，但我和他们已经有一周的支持票了，他们显然还在努力解决这个问题

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

因此，从本质上讲，使SQLAzure高度可用的方面是导致数据库随机不可用。 如果这不是要我们的命，我会嘲笑这个讽刺

有关详细信息，请查看此线程：

---

非常感谢保罗，你刚刚证实了我可以得出的结论！我会用我从中获得的数据更新我的帖子，以防它帮助其他人诊断。我还就这一点向MS提出了一个支持问题。我们是黄金搭档，所以希望我们能在圣诞节前找到答案！别担心，很抱歉听到你和我们有同样的问题。这是一个严重的问题，从编码的角度来看，几乎不可能缓解。非常感谢Paul，我一直遇到同样的问题，并且一直在到处寻找合理的答案。这是我的怀疑，而你的询问证实了这一点。别担心，可怜虫，你也在承受这种痛苦。我认为这个问题比微软所说的要广泛得多。我的支持票还开着，坦率地说，和我打交道的那个家伙是个白痴。我从谷歌上学到的关于这个问题的知识比从我的助手那里学到的要多。对我们来说，情况有所改善，这是好事，因为这为我们赢得了时间来决定是否（痛苦、昂贵）迁移到Amazon RDS。遗憾的是MS没有在保留的实例容量中提供Sql Azure:/这个问题一直持续到2014年。在我的例子中，MS支持部门在确认问题时一直很慢，即使诊断报告非常清楚地显示了等待的每个更新

SE\u REPL\u slow\u SECONDARY\u THROTTLE

。我必须将受影响的数据库从SQL Azure中移出。