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防火墻或數據庫限制長連接(不推薦，迫不得已,沒辦法的辦法)
該文章在 2019/9/29 15:30:51 編輯過
400 186 1886
