客户端无法重新使用 SPID 为 XX 的会话，该会话已被重置用于连接池。失败 ID 为 XX。此错误可能是由于先前的操作失败引起的。...

对于配置了报警的SQLServer数据库服务器，就可能收到这样的一个错误。

而20号报警是属于进程中的错误。

百度找原因；

分析过程：
如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防火墙或数据库限制长连接(不推荐，迫不得已,没办法的办法)

检查一下发现数据库压力一般，对应的web的内存到95%了，而错误日志不是连续这个错误，根据服务器上的trace发现之前对应时间的spid的查询是一同事正在调试的语句。

转载于:https://www.cnblogs.com/foucs-jiang/p/7374687.html