“故障排除”；“等待操作超时”；在Azure数据库上

由于某种未知的原因，今天，我们的一个Azure web应用程序因其Azure SQL数据库的可用性而崩溃，时间仅为10分钟左右。该web应用程序给出了一个YSOD，上面写着“等待操作超时”。Elmah显示了其他错误，如“登录失败”和“当前命令出现严重错误。如果有结果，应丢弃。”

看看应用程序和数据库负载，我真的不明白为什么。数据库设置为S0级别，我们将其增加到S1，但这似乎很奇怪。我们很少有超过50%的DTU在数据库上的利用率，web应用程序在35个同时请求时达到峰值。总的来说，它看起来不像是超出S0数据库能力之外的负载

所有这些都很糟糕，是的，但最大的问题是我如何解决这个问题？这显然是一个DB问题，但考虑到低负载，我不知道为什么。我当然不想为这种规模的应用升级到每月300美元以上的高级级别

---

我可以设置日志来解决这个问题吗？回顾所发生的事情并就如何防止再次发生得出明确结论的方法？

工具>选项>设计器>表和数据库设计器

确保选中顶部的复选框“覆盖表设计器更新的连接字符串超时值”，并根据需要增加事务超时

或者，取消选中该框并在连接字符串中指定超时

---

我也遇到过同样的问题，它会启用索引，但在同一个索引上总是失败。默认值是30秒，我将我的时间增加到900秒（15分钟），然后让它运行，它成功地做到了。可能只需要30秒多一点，但很好。

我的应用程序偶尔会出现这种情况。我不明白为什么。我已经配置了RetryPolicy，增加默认的SqlConnetion ConnectionTimeout（在连接字符串中）似乎有点帮助。归根结底，我不认为微软能保证与数据库的连接永远正常，你也无法阻止这种情况再次发生。奇怪的是，直到2017年3月，应用程序运行时几乎没有问题，从那时起，我开始一天出现几十次反复出现但间歇性的问题。同样有趣的是，在一些浏览器上，在清除该站点的Cookie之前，该问题将继续发生。这听起来可能与ServiceStack及其处理缓存的方式有关。可能与实例关联有关吗？我在我的应用程序上关闭了实例关联，这大大减少了错误计数。