怎么解决sqlhelper 连接超时的问题

解决方法：

1 修改几个关键页面或访问比较频繁的数据库访问 *** 作，使用DataAdapter和DataSet来获取数据库数据，不要使用DataReader。

2 在访问数据库的页面上使用数据缓存，如果页面的数据不是经常更新（几分钟更新一次）的话，使用Cache对象可以不用访问数据库而使用缓存中的内容，那么可以大大减少连接数量。

3 修改代码，把使用Connection对象的地方都在Close()后面加上Dispose()调用。

4 建议对数据库 *** 作进行大的修改，建立自己的数据库 *** 作代理类，继承SystemIDisposable接口，强迫释放资源，这样就不会出现连接数量不够的问题了。

解决方案二

解决方法():WEBconfig 里面:在数据库连接加 Max Pool Size = 512;server=local;uid=;pwd=;database=2004;Max Pool Size = 512;">一劳永逸。

解决方案三

估计是连接(Connection)对象没有Close。倒是不必Dispose，而DataReader用完后应该关闭，但不关闭也没问题，只是不关闭的话此连接对象就一直不能用，只要你最终关闭了连接对象就不会出问题。

连接对象在Open后的 *** 作都放在try块中，后面跟一个finally块：connClose();

池式连接超时的解决方法：

1、修改几个关键页面或访问比较频繁的数据库访问 *** 作，使用DataAdapter和DataSet来获取数据库数据，不要使用DataReader。

2、在访问数据库的页面上使用数据缓存，如果页面的数据不是经常更新（几分钟更新一次）的话，使用Cache对象可以不用访问数据库而使用缓存中的内容，那么可以大大减少连接数量。

3、修改代码，把使用Connection对象的地方都在Close()后面加上Dispose()调用。

池式连接超时的原因

系统割接后，中间件和数据库进行了防火墙隔离，由于数据库和应用都进行了割接，系统架构由原先的单一网络变成了跨系统部署，数据库和应用之间的访问通过防火墙；而防火墙这边对空闲的连接配置了超时时间（一般默认为30分钟），一旦超过时间，会自动将连接断掉。

而断掉后，应用程序这一侧的数据库连接池这边还是认为该连接有效，它只在应用获取该连接时才会进行一个有效性测试，会每间隔一个时间尝试一次，尝试n次后才确定该连接失效，发起重连，最终造成业务耗时长。

由于连接池连接数很多，势必造成有部分连接空闲时间超过了防火墙的设置，而应用程序这边没有配置对空闲连接的维护参数，空闲连接会一直认为有效，所以该现象只会出现在连接池中的空闲连接上；当应用获取已被防火墙断开的空闲连接时，就会造成应用的响应慢，或者直接提示connection timed out异常。

要是你使用了事务那就得尽量启用短事务长事务很容易导致数据库中 *** 作的表被锁死。你可以在数据库中使用sp_who查询出你正在使用的数据库是否有sleeping的或者AWAITING COMMAND的然后调试你的代码看看是什么原因导致出现这个问题的。还有就是可能因为你使用的sql语句查询数据量过大而且使用过多的子查询导致sql语句执行效率很低然后会是数据库无法及时响应。这个是我个人的经历。具体其他的我就不是很清楚了 希望能够帮到你

1由于数据库设计问题造成SQL数据库新增数据时超时

症状:

Microsoft OLE DB Provider for SQL Server 错误 '80040e31' ([ODBC SQL Server Driver]超时已过期);

服务器上看CPU、内存占用率很低;

事件日志中提示: 数据库 '' 中文件 '' 的自动增长在 453 毫秒后已取消或出现超时。使用 ALTER DATABASE 设置更小的 FILEGROWTH 或设置新的大小。

原因:

数据库设置时,[文件增长]按百分比来增长,当数据库文件很大时(1G以上),新增 *** 作都会报超时，而这时候其实CPU、内存占用率都非常非常的低。

解决方法:

把上述的文件增长这里设置为一个更低的百分比或者直接指定增加多少兆字节。

2SQL Server数据库超时设置

修改客户端的连接超时设置。默认情况下，通过企业管理器注册另外一台SQL Server的超时设置是 4 秒，而查询分析器是 15 秒。

企业管理器中的设置:

在企业管理器中，选择菜单上的"工具"，再选择"选项"；

在d出的"SQL Server企业管理器属性"窗口中，点击"高级"选项卡；

在"连接设置"下的"登录超时(秒)"右边的框中输入一个比较大的数字，如 30。

查询分析器中的设置:

单击“工具”->"选项"->"连接"; 将登录超时设置为一个较大的数字，连接超时改为0。

3查询语句时超时

原因分析:

查询超时一般来说首先要从sql语句和数据表的结构上找原因，优化sql语句和为数据库的查询字段建索引是最常用的办法。

另外，数据库的查询超时设置一般是sqlserver自己维护的(在你没有修改query wait配置前)，只有当你的实际查询时间超过估计查询时间的25倍时，才会超时。

而造成超出估计值那么多的原因有两种可能:

估计时间不准确；

sql语句涉及到大量占用内存的查询(如排序和哈希 *** 作)，内存不够，需要排队等待资源造成的。

解决办法:

优化语句,创建\使用合适的索引;

解决第一个问题的方法,更新要查询表的索引分发统计，保证估计时间的正确性，UPDATE STATISTICS 表名;

增加内存

如果想手动设置查询超时，可以使用以下语句：

sp_configure 'show advanced options', 1 GO RECONFIGURE GO sp_configure 'query wait', 2147483647 GO RECONFIGURE GO

4应用程序连接失败

故障:

在应用程序中我们也会遇到类似的错误信息，例如：

Microsoft OLE DB Provider for ODBC Drivers 错误 '80004005' [Microsoft][ODBC SQL Server Driver]超时已过期

解决方法:

A如果遇到连接超时的错误，我们可以在程序中修改 Connection 对象的超时设置，再打开该连接。例如：

＜%Set Conn = ServerCreateObject("ADODBConnection")DSNtest="DRIVER={SQL Server};SERVER=ServerName;UID=USER;PWD=password;DATABASE=mydatabase"Conn Properties("Connect Timeout") = 15 '以秒为单位Connopen DSNtest%＞

B　 如果遇到查询超时的错误，我们可以在程序中修改 Recordset 对象的超时设置，再打开结果集。例如：

Dim cn As New ADODBConnectionDim rs As ADODBRecordset cmd1 = txtQueryTextSet rs = New ADODBRecordsetrsProperties("Command Time Out") = 300'同样以秒为单位，如果设置为 0 表示无限制rsOpen cmd1, cnrsMoveFirst

另外,一些硬件及网络方面的原因也可能造成SQL数据库连接超时

方法1：修改SERVICE_NAME为SID；

方法2：删掉sqlnetora，然后重试；

方法3：试试telnet 17020519947 1521 看看通不通，不通的话可能是服务端防火墙，可能是listener设置不对。

原因分析:

查询超时一般来说首先要从sql语句和数据表的结构上找原因，优化sql语句和为数据库的查询字段建索引是最常用的办法。

另外，数据库的查询超时设置一般是sqlserver自己维护的（在你没有修改query wait配置前），只有当你的实际查询时间超过估计查询时间的25倍时，才会超时。

而造成超出估计值那么多的原因有两种可能:

一是估计时间不准确；

二是sql语句涉及到大量占用内存的查询（如排序和哈希 *** 作），内存不够，需要排队等待资源造成的。

解决办法:

A优化语句,创建/使用合适的索引;

B解决第一个问题的方法,更新要查询表的索引分发统计，保证估计时间的正确性，UPDATE STATISTICS 表名;

C增加内存

如果想手动设置查询超时，可以使用以下语句：

sp_configure 'show advanced options', 1 GO RECONFIGURE GO sp_configure 'query wait', 2147483647 GO RECONFIGURE GO

老大你那数据量太大了这个要是想不超时的话得从系统结构上重新考虑尽可能重新有效的规划你要查的表的PK并在查询中利用PK做查询的条件开头~~~否则你的数据量太大IO要花很久的有可能的话尽量要把磁盘的性能提升上来RAID5表内一行的数据量尽可能控制在比较小的尺寸不行的话就考虑水平(分区表)或是垂直对表进行划分用PK关联

以上就是关于怎么解决sqlhelper 连接超时的问题全部的内容，包括:怎么解决sqlhelper 连接超时的问题、池式连接超时怎么解决、asp.net连接数据库超时的原因是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！