客戶端無法重新使用 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防火牆或數據庫限制長連接(不推薦 ，迫不得已,沒辦法的辦法)
查看本欄目
