SQLEXCEPTION超时过期而没有达到 [英] SqlException timeout expired without being reached

查看:158
本文介绍了SQLEXCEPTION超时过期而没有达到的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

不时在我们的服务器抛出这个著名的例外:

From time to time our server throw this well-known exception:

超时过期。之前完成操作超时时间已过或服务器没有响应。

此情况下,服务器运行在大的请求时,pressure。 我做了一些研究,发现我可以改变的连接字符串连接超时设置和/或 SqlCommand.Timeout 数据读取器的属性。

This happens under pressure when the server is working on big requests. I did some research and found out that I could change connection string connection timeout setting and/or SqlCommand.Timeout data reader properties.

在默认情况下,SQL命令超时设置为 30 秒,连接超时为 15 ,然后我们从来没有覆盖它们。

By default, sql command timeout is set to 30 seconds and connection timeout to 15, and we never override them.

我转载的背景和执行用手Management Studio中failling请求。 其持续时间大约1 二,始终远远超出30

I reproduced the context and executed the failling requests by hand in management studio. Their duration are around 1 second and always far beyond 30.

但奇怪的是,当我看看服务器日志,抛出此异常马上请求调用。 我的意思是,请求执行一毫秒后的异常。 对不起我,但让我做我的怪胎看这个 8-O

But strangely when I take a look at the server logs, this exception is thrown right away the request call. I mean, the request is executing and one millisecond later the exception is raised. Excuse me but let me do my geek look about this 8-o.

要完成,我们的SQL实例镜像与另一位在同步模式。 我们通过表适配器使用Ado.Net。

To be complete, our sql instance is mirrored with another one in synchronous mode. We use Ado.Net through table adapters.

推荐答案

其实,我们仍然经历了这些随机超时READ_COMMITED_SNAPSHOT设置后还是一样。

In fact we still experienced these random timeouts even after READ_COMMITED_SNAPSHOT was set.

设置在异步模式下镜子没有帮助,在多线程进行查询后约1毫秒还是随机timeouted,总是在繁忙时段。另一方面触发超时(INSERT语句)执行本身非常快(小于1ms的CPU和大约10读取在平均值)与特定的查询。

Setting the mirror in asynchronous mode didn't helped, queries done in multiple threads still randomly timeouted after about 1ms, always on busy periods. On the other hand the specific query that triggered the timeout (an INSERT statement) executed itself really fast (less than 1ms CPU and about 10 reads in average).

调用堆栈是如下:

在System.Data.ProviderBase.DbConnectionPool.GetConnection(的DbConnection owningObject)

at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)

在System.Data.ProviderBase.DbConnectionFactory.GetConnection(的DbConnection owningConnection)

at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)

在System.Data.ProviderBase.DbConnectionClosed.OpenConnection(的DbConnection outerConnection,DbConnectionFactory connectionFactory的)

at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)

在System.Data.SqlClient.SqlConnection.Open()

at System.Data.SqlClient.SqlConnection.Open()

所以超时似乎没有相关的查询本身

So the timeout didn't seem related to the query itself.

根据这个其他职位:<一href="http://stackoverflow.com/questions/5884876/multiple-simultaneous-sql-connection-timeouts-in-multithreaded-windows-service">Multiple同时SQL连接超时在多线程Windows服务并链接<一个href="http://msdnrss.the$c$crblogs.com/2011/05/ado-net-application-connecting-to-a-mirrored-sql-server-database-may-timeout-long-before-the-actual-connection-timeout-elapses-sometimes-within-milliseconds/"相对=nofollow> MSDN博客帖子谈到一个ADO.NET的错误,我们试图连接超时设置为 150 在连接字符串中

According to this other post : Multiple Simultaneous SQL Connection Timeouts In Multithreaded Windows Service and the linked MSDN blog post speaking about an ADO.NET bug, we tried to set the connection timeout to 150 in the connection string.

不能确定,我们正在经历这个bug,但由于这种变化没有更多的超时已被抛出。

Can't be certain we were experiencing this bug, but no more timeouts have been thrown since this change.

这篇关于SQLEXCEPTION超时过期而没有达到的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆