我们每天都会遇到一些实例，其中我们从多个应用程序收到大量 SQL 超时错误(System.Data.SqlClient.SqlException:超时已过期。在操作或服务器完成之前超时期限已过没有响应。)我们的网络上有 100 多个不同的应用程序，包括 Web 和桌面应用程序。从 VB6 和经典 ASP 到 .NET 4 的一切。我可以找到显示副作用的各种数据，但无法查明是什么原因造成的。我们的 DBA 说 SQL 服务器没有任何问题，IT 部门也说 Web 服务器或网络没有任何问题，所以我当然只能在中间尝试解决这个问题。
我实际上只是在寻找有关我可以采取哪些其他故障排除措施的建议来尝试追踪此问题。
我们在集群中运行 SQL Server 2008 R2。有一些不同的服务器连接到它，从 Windows Server 2003 到 2008 等不同类型。
这是我到目前为止所做的事情:
- 运行长时间运行的查询和死锁的 SQL 跟踪。这表明出现问题时没有死锁，并且长时间运行的查询都与我们的超时错误一致，但看起来是副作用，而不是原因。通常立即返回的非常基本的查询有时需要 30、60 或 120 秒才能运行。这种情况会持续几分钟，然后一切都会恢复正常。
- 使用性能监视器跟踪连接池连接。这有时会在接近超时时间时显示连接数量出现一些峰值，但仍然没有达到默认 100 个连接限制的一半。再说一次，这里似乎没有任何迹象表明原因。
- 将网络应用程序分离到不同的应用程序池中。我们尝试缩小我们认为可能是主要问题的应用程序(最闲聊等)，并将它们放入单独的应用程序池中，但这并不能解决问题。似乎会影响任何事情或帮助我们缩小任何范围。
- 监控 SQL Server 上的磁盘使用情况。我们对 SQL Server 进行了一些监控，发现在发生超时时没有出现峰值或任何问题迹象。
- 已验证的 TempDB 不是问题的原因。
如果我想到我们还尝试过什么，我会回来添加更多内容。请让我知道一些关于下一步要排除故障的想法。
最佳答案
Run SQL trace of long running queries and deadlocks. This shows no deadlocks at the times of the problems, and long running queries all coincide with our timeout errors, but look to be a side effect, and not the cause. Queries that are very basic that typically return instantly end up taking 30, 60 or 120 seconds to run at times. This happens for a few minutes then everything picks up and works fine after that.
看起来有些查询/事务会锁定您的数据库直到完成。您必须找出哪些查询正在阻塞，并在其他时间重写/运行它们，以避免阻塞其他进程。此时等待查询刚刚超时。
需要深入研究的一个额外点是事务日志和数据库的自动增量大小。将它们设置为固定大小，而不是当前文件的百分比。如果文件变得越来越大，分配足够空间所需的时间最终会随着事务超时而变长。然后你的数据库就停止了。
关于.net - 如何解决间歇性 SQL 超时错误，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7743725/