迁移到 azure 后 SQL 超时

Question

将我的应用程序部署到 Azure 后，我遇到了一些 db 密集型报告的 sql 超时问题。

我尝试更改连接字符串中的 sql 超时，但没有任何效果。我还尝试将数据库从 S2 升级到 P1，然后它的性能足够好，不会超时。但不幸的是，这并不是真的我们的选择。

请问如何更改这些操作的超时值？

这是我收到的错误（以前在机架空间上没有发生过）

“/”应用程序中的服务器错误。

等待操作超时

描述：执行过程中发生了未处理的异常 当前的网络请求。请查看堆栈跟踪以获取更多信息 有关错误的信息以及它在代码中的来源。

异常详细信息：System.ComponentModel.Win32Exception：等待 操作超时

来源错误：

在执行过程中产生了一个未处理的异常 当前的网络请求。有关原产地和位置的信息 可以使用下面的异常堆栈跟踪来识别异常。

堆栈跟踪：

[Win32Exception (0x80004005): 等待操作超时]

[SqlException (0x80131904): 执行超时。超时 在操作完成之前经过的时间段或服务器处于 没有回应。]
System.Data.SqlClient.SqlConnection.OnError（SqlException 异常， 布尔型 breakConnection，动作 1 wrapCloseInAction) +2442634
System.Data.SqlClient.SqlInternalConnection.OnError（SqlException 异常，布尔型 breakConnection，动作 1 wrapCloseInAction) +5766568

Answer 1

如果你将计划从低变大并且它有效，那么它肯定是性能问题。

Azure SQL 使用 DTU 来衡量您使用 CPU、IO 等资源的数量。因此，如果您使用 100% 的 DTU，您的查询会有所延迟，并且使用 100% 的时间越长，您将收到超时异常，因为默认情况下 .net 连接有 30 秒超时。增加可能对您没有帮助，因为问题可能是您多次运行相同的查询并且它开始相互阻塞。

转到您的数据库，然后 Query Performance Insight，查看您的热门查询运行时间。并从那里开始优化。

潜在的地方可能是 EntityFramework Include，如果您使用它，这可能会生成带有大量数据的查询，这会降低查询速度并使用大量 IO。

如果您仍想增加超时，您可以在.config file 中为您的连接字符串添加

;Connection Timeout=60

但正如我所说，它可以工作，但更好的是查看哪些查询很慢并改进它们

PS。我最近在我的应用程序中遇到了同样的问题，有一个我永远不会说会使用这么多 DTU 的特定查询。

PS。好吧，我第一次没有正确阅读您的问题。所以我删除了我之前的答案

Answer 2

截至 2019 年 4 月这个月，同样的问题完全出人意料地出现了。我们在 S3（标准 3）上准备推出我们的应用程序，然后突然间部分查询不起作用。

使用 Visual Studio 进行调试以查找“我们的错误”表明查询都已超时。我发现这篇文章指出必须超过最大 DTU。

我想‘啊哈！ ...这可能是因为我复制了数据库并且必须多次运行我的数据插入查询来更新该数据库'。不。只需阅读查找打印。

我们所在的 S3 最近已更改为“标准”，具有 Microsoft 认为的“典型 IO 工作负载”。看看我们的 DTU 使用率，我们是 0.7%。不可能将查询超时时间强制为 30 秒或更短。

好的，Premium 现在适用于“更多 IO 密集型工作负载”。好像之前 0.7% 的 DTU 使用量是 IO 密集型的。

我把它改成了 P0 和 Bingo！零件查询再次运行。

如果这让我们赚了很多钱，我会提请我们的权力注意。我昨天花了很多时间解决这个问题，所以我不希望其他人有同样的经历。

Answer 3

正如 Volodymyr 所指出的，我肯定会注意优化涉及超时的查询..但我也想指出..

SQLAzure 不会为我们更新索引/统计信息，就像在本地一样..你必须照顾它..

在我们的例子中，我们创建了一个每周任务来每周重建索引和更新统计信息，然后与超时相关的错误下降到 99%..

对于仍然超时的查询，我们采取了优化的方法