如何解决消息客户端无法复用SPID 799的会话的问题

错误日志：

消息客户端无法复用。 SPID 2799 的会话，已针对连接池重置。故障 ID 为 46。

此错误可能是由先前失败的操作引起的。检查错误日志以查找紧接此错误消息之前的失败操作。

消息无法继续，因为会话处于终止状态。

消息

错误：18456，严重性：14，状态：46。

消息

用户登录失败'wms'。原因：重新验证用于连接的登录名时，无法打开登录对象中配置的数据库“wms”。

[克莱nt: 192.168.0.52]

消息

错误：18056，严重性：20，状态：46。

消息

客户端无法重用 SPID 2799 的会话，该会话已针对连接池重置。故障 ID 为 46。此错误可能是由较早的操作失败引起的。检查该错误信息之前的错误日志是否有失败的操作。

案例描述：

当SQLSERVER的错误日志文件不断报告错误10856时，CPU也会很低。此时SQL客户端已登录

数据库查询操作正常； IIS连接数暴涨，网站无法操作数据库（如登录、基本查询）

分析前提：

这个问题很常见，官方解释没有明确的答案。都说要么打补丁，要么需要设置IIS连接池。

这里分析的前提是数据库已经打了lat补丁est 补丁。 、IIS连接数数据库的字符串正常，用户名密码正常。

分析过程：

例如，如果IIS连接池设置为1500M， IIS连接数据为1500，那么每个会话会分配平均连接池大小为1MB，

默认数据库网络包大小为4096；

如果此时有一个请求需要返回20M数据，那么本次session从数据库返回的数据包大小就会超过session获取到的连接池大小

会话保持时间需要比平均长。一般情况下，这些占主导地位的请求不会造成太大的问题。

如果IIS请求数量同时达到3000个，每个SESSION的平均大小达到的连接池将为 0.5MB。如果还返回20MB的数据，

那么SESSION时间会更长！

如果此时客户端请求返回100条30M的数据，那么当数据库返回给IIS时，IIS会发现连接池没有足够的内存空间

分配在这个SESSION中，IIS连接池大小不会随着客户端请求的增加或者IIS服务器没有更多的物理内存而自动增加。这时，IIS就会

因为连接池不够了。分配空间来缓存相应的SESSION，但后续的客户端响应仍然继续应用于IIS。这时候，问题就出现了！

IIS将释放（或IIS进程宕机或IIS自动重启）无法处理的SESSION。当数据库收到IIS端的SESSION请求时，查询数据并准备返回给IIS。

SESSION，查找r对应的SPIDequest，发现请求的SPID已经不存在了，但是数据库的TCP连接不会因为SPID不存在而立即丢弃数据。这时候网卡的流量就会增加！同时，数据库ERRORLOG中充满了此类错误。

解决方案：

0。首先排除DB是否出现死锁

1.最直接的方法是增加IIS连接池大小

2。找出程序中的大会话请求并修改代码

3.限制IIS进程数上限，并根据日常运行情况设置连接池大小（不推荐，万不得已）

4.数据库端频繁限制sql响应：SQL防火墙或者数据库限制长连接（不推荐，这是不得已的办法，没有其他办法）

到目前为止，相信大家对“如何解决问题”有了更深入的了解消息客户端无法复用SPID 799的会话。大家不妨实际操作一下！这里是网站，更多相关内容可以进入相关频道查询，关注我们，继续学习！