10

SQL Azure 问题。

我有一个问题，在我们的（asp.net）网站上表现为以下异常：

超时已过。在操作完成之前超时时间已过或服务器没有响应。该语句已终止。

它还导致更新和插入语句永远不会在 SMSS 中完成。查询时不存在任何 X 或 IX 锁：查询或sys.dm_tran_locks时不存在事务。sys.dm_tran_active_transactionssys.dm_tran_database_transactions

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

数据库未满。

在某一时刻，这个问题并没有自行解决，但我能够通过查询sys.dm_exec_connections找到运行时间最长的会话，然后终止它来解决这个问题。奇怪的是，连接已经存在 15 分钟，但锁定问题已经存在超过 3 个小时。

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

编辑

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

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

select *  from sys.dm_exec_requests

请求统计

正如我们所见，所有的 WAIT 请求都在等待会话 1021，这是复制请求！表示 DTC事务TM Request，我们不使用分布式事务。您还可以看到 wait_typeSE_REPL_COMMIT_ACK再次暗示复制。

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 毫秒，即 134.9 分钟！！！

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

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

问题：在过去三周内（即自从我的问题开始后），这些软限制是否发生了变化？

答：不，没有。

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

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

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

  2. 联系 Windows Azure 支持并告知问题并让他们为您执行选项 1

4

1 回答 1

9

您可能会遇到 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

于 2013-04-04T11:21:31.710 回答