SQL Server数据库客户端无法重新使用 SPID 为 %d 的会话，该会话已被重置用于连接池。失败 ID 为 %d。

此错误可能是由于先前的操作失败引起的。
请查看错误日志，找出在显示此错误消息之前刚发生的失败操作。

2011-11-19 16:33:53.91 spid5495    The client was unable to reuse a session with SPID 5495, which had been
reset for connection pooling. The failure ID is 1. This error may have been caused by an earlier operation
failing. Check the error logs for failed operations immediately before this error message.
2011-11-19 16:33:53.93 spid2991    错误: 18056，严重性: 20，状态: 1。

案例说明：

当SQLSERVER的errorlog文件中不停的报错10856的时候，CPU同时会很低，此时SQL客户端登陆数据库查询操作正常；IIS连接数暴涨，网站无法操作数据库(如登录、基本查询)

分析前提：
该问题很常见，官方解释没有很明确的答案，都是说要么需要打补丁要么需要设置IIS的连接池。
这里分析前提是数据库已经打了最新的补丁、IIS连接数据库的字符串正常、用户名和密码正常。

分析过程：
如IIS的连接池设置1500M，IIS连接数据正常1500个，那么每个session分到的连接池大小平均1MB，数据库网络数据包默认是4096；

如 果这个时候有个请求需要返回20M数据，那么这个session从数据库返回的数据包大小就要超过session获得的连接池大小，数据包是4096，比 正常的请求(请求1M的回话)就需要多的数据包传递，这个session对应的回话保持时间就需要比平均水平长些，正常情况下，这些独大的请求不会有太大 问题。
如果同一时刻，IIS的请求数达到3000，每个SESSION分到的连接池大小平均值就会0.5MB，如果同样返回20MB数据，那么SESSION的时间就会更长！
如果这个时候客户端请求返回100个30M数据，那么此时的请求，当数据库返回给IIS时，IIS会发现连接池没有足够的内存空间分配这个SESSION，此时IIS的连接池大小不会随着客户端请求的增加而自动增加或IIS服务器没有更多的物理内存，此时IIS就会因为没有足够的连接池空间分配来缓存对应的SESSION，但是后续的客户端回话还是不停的向IIS申请，这个时候问题就来啦！
IIS会释放掉(或IIS进程down掉或IIS自动重启)没法处理的SESSION，当数据库收到IIS端SESSION请求查询出数据准备返回给IIS的SESSION时，去寻找对应请求的SPID，发现该请求的SPID已经不存在，但是数据库的TCP连接不会因为SPID的不存在立即抛弃这些数据，此时网卡的流量会增加！同时数据库ERRORLOG里全是这种错误。

解决办法：
0、首先排除DB是否有死锁
1、最直接的办法就是增加IIS连接池大小
2、就是找出程序中大的会话请求，修改代码
3、限制IIS进程数上限，根据日常运行情况设置连接池大小(不推荐，迫不得已)
4、数据库端限制sql回话时常：SQL防火墙或数据库限制长连接(不推荐，迫不得已,没办法的办法)