timeout expired.then timeout period elapsed prior to obtaining a connection from the pool.……

问题描述

超时时间已到。超时时间已到，但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用，并且达到了最大池大小
c514
。

说明: 执行当前 Web 请求期间，出现未处理的异常。请检查堆栈跟踪信息，以了解有关该错误以及代码中导致错误的出处的详细信息。

异常详细信息: System.InvalidOperationException: 超时时间已到。超时时间已到，但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用，并且达到了最大池大小。

这是个老问题了！你就查两点：

一、看所有open的连接是否都close了。

二、如果访问量很大，加上Max   Pool   Size=512这一句，当然这是要以损失系统性能为代价的！

这样以后一定可以解决你的问题！

解决方案一

我 想原因可能是并发操作。DataReader是独占连接的，就是说你的程序可能设计上有问题。比如说最大连接设100，假设有100个人同时使用 DataReader正在读取数据库内容，那么当第101人读取的时候，连接池中的连接已经没有了，就会出现上面的错误。DataReader是独占连接 的，每个DataReader都要占用一个连接。当然这个情况是偶尔出现的，所以会很长时间出现一次，因为只有同时有超过连接池最大连接数量的并发操作才 会发生。而且你加大并发数量只能暂时缓解问题，如果你加大到200个并发连接，如果有201
人同时操作怎么办？你说了你使用Connection对象的Close()方法，这是不行的，因为Close()方法仅仅是关闭连接，但这个连接没有释 放，还是被这个对象占用，要释放必须使用Connection的Dispose()方法显式释放连接才可以，否则这个对象占用的连接只能等到垃圾收集的情 况下才能被释放。这种情况肯定会出现“超时时间已到”的错误。

解决方法：

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

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

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

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

         5SqlCommand myCommand = new SqlCommand(myInsertQuery);

          myCommand.Connection.Close();

          myCommand.Dispose();

解决方案二

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

解决方案三

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

   

   连接对象在Open后的操作都放在try块中，后面跟一个finally块：conn.Close();
还有就是没有把语句中的IP改过来！

 

 

 

 解决思路：

 （1）在SQL Server管理器窗口执行存储过程 sp_who 查看所有活动连接。

 （2）使用Kill终止进程，Kill的用法如下。

 

-- 运行以下脚本可以终止所有连接：

-- Author: Eman Lee

-- Date: 11/11/2008

USE [master]

GO

DECLARE @spid sysname, @msg varchar(100), @cmd varchar(1000)

DECLARE table_cur CURSOR FOR

SELECT spid FROM master.dbo.sysprocesses WHERE db_name(dbid)='Database Name'

OPEN table_cur

FETCH NEXT FROM table_cur INTO @spid

WHILE @@fetch_status = 0

BEGIN

IF @@fetch_status = -2

CONTINUE

SELECT @msg ='KILL ' + @spid

PRINT @msg

SELECT @cmd = 'KILL ' + @spid

EXEC (@cmd)

PRINT ' '

FETCH NEXT FROM table_cur INTO @spid

END

DEALLOCATE table_cur

GO

 

KILL (Transact-SQL)

终止基于会话 ID（SQL Server 2000 或更早版本中的 SPID）或工作单元 (UOW) 的用户进程。如果指定的会话 ID 或 UOW 有许多工作要撤消，则 KILL 语句可能需要一些时间来完成，特别是在涉及回滚长事务时。

在 Microsoft SQL Server 2000 和更高版本中，KILL 可用于终止正常连接，这将在内部终止与给定的会话 ID 关联的事务。如果正在使用 Microsoft 分布式事务处理协调器 (MS DTC)，该语句还可用于终止所有孤立和有疑问的分布式事务。



Transact-SQL 语法约定


 语法

KILL { session ID | UOW } [ WITH STATUSONLY ]

 参数

session ID
要终止的进程的会话 ID。session ID 是在建立连接时为每个用户连接分配的唯一整数 (int)。在连接期间，会话 ID 值与该连接捆绑在一起。连接结束时，则释放该整数值，并且可以将它重新分配给新的连接。

使用 KILL session ID 可终止与指定的会话 ID 关联的常规非分布式事务和分布式事务。

UOW
标识分布式事务的工作单元 ID (UOW)。UOW 是可从 sys.dm_tran_locks 动态管理视图的
request_owner_guid 列中获取的 GUID。也可从错误日志中或通过 MS DTC 监视器获取 UOW。有关监视分布式事务的详细信息，请参阅 MS DTC 文档。

使用 KILL UOW 可终止孤立的分布式事务。这些事务不与任何真实的会话 ID 相关联，与虚拟的会话 ID = '-2' 相关联。可使标识孤立事务变得更为简单，其方法是查询
sys.dm_tran_locks、sys.dm_exec_sessions 或
sys.dm_exec_requests 动态管理视图中的会话 ID 列。

WITH STATUSONLY
生成由于更早的 KILL 语句而正在回滚的指定 session ID 或 UOW 的进度报告。KILL WITH STATUSONLY 不终止或回滚
session ID 或 UOW，该命令只显示当前的回滚进度。


 备注

KILL 命令通常用于终止这样一些进程：它们以锁阻塞了其他重要进程，或者正在执行一个查询，而该查询正在使用必需的系统资源。系统进程和运行扩展存储过程的进程不能被终止。

应当小心使用 KILL，特别是正在运行重要进程时。用户不能取消自己的进程。其他不能取消的进程包括：

AWAITING COMMAND

CHECKPOINT SLEEP

LAZY WRITER

LOCK MONITOR

SIGNAL HANDLER

使用 @@SPID 可显示当前会话的会话 ID 值。

若要获取活动会话 ID 值的报告，可以查询 sys.dm_tran_locks、sys.dm_exec_sessions 和
sys.dm_exec_requests 动态管理视图中的 session_id 列。还可以查看
sp_who 系统存储过程返回的 SPID 列。如果特定 SPID 的回滚正在进行，则该 SPID 的
sp_who 结果集中的 cmd 列将指示 KILLED/ROLLBACK。

当特定的连接在数据库资源上有锁并阻塞其他连接的进程时，sys.dm_exec_requests 的 blocking_session_id 列或
sp_who 返回的 blk 列中将显示该阻塞连接的会话 ID。

KILL 命令可用于解决有疑问的分布式事务。这些事务是未解决的分布式事务，它们是由于无计划地重新启动数据库服务器或 MS DTC 协调器而产生的。有关有疑问事务的详细信息，请参阅使用标记的事务（完整恢复模式）中的“两阶段提交”部分。

使用 WITH STATUSONLY

仅当前面的 KILL session ID|UOW 语句导致会话 ID 或 UOW 当前正在回滚时，KILL WITH STATUSONLY 才会生成报告。进度报告指出已完成的回滚量（百分比）和估计的剩余时间（秒），格式如下：

Spid|UOW <xxx>: Transaction rollback in progress. Estimated rollback completion: <yy>% Estimated time left: <zz> seconds

如果执行 KILL session ID|UOW WITH STATUSONLY 语句时会话 ID 或 UOW 的回滚已完成，或者没有会话 ID 或 UOW 正在回滚，KILL
session ID|UOW WITH STATUSONLY 将返回以下错误：

“Msg 6120，级别 16，状态 1，第 1 行”

“无法获取状态报告。进程 ID <会话 ID> 的回滚操作不在进行中。”

通过重复不带 WITH STATUSONLY 选项的同一 KILL session ID|UOW 语句，可以获得相同的状态报告；但不推荐这样做。如果在运行新的 KILL 语句之前回滚已完成并且已将会话 ID 重新分配给新任务，那么重复 KILL
session ID 语句可能会终止新进程。指定 WITH STATUSONLY 将防止这种情况发生。


 权限

要求具有 sysadmin 或 processadmin 固定服务器角色的成员身份。


 示例

A. 使用 KILL 终止会话

以下示例显示如何终止会话 ID

53

。

复制代码

KILL 53;GO

B. 使用 KILL 会话 ID WITH STATUSONLY 获取进度报告

以下示例为特定的会话 ID 生成回滚进程的状态。

复制代码

KILL 54; KILL 54 WITH STATUSONLY; GO --This is the progress report. spid 54: Transaction rollback in progress. Estimated rollback completion: 80% Estimated time left: 10 seconds.

C. 使用 KILL 终止孤立的分布式事务

以下示例显示如何终止 UOW 为

D5499C66-E398-45CA-BF7E-DC9C194B48CF

的孤立分布式事务（会话 ID = -2）。

复制代码

KILL 'D5499C66-E398-45CA-BF7E-DC9C194B48CF';