SQLSERVER 18056 錯誤

From:http://blog.csdn.net/yangzhawen/article/details/8209167

18056 
 

用戶端無法重新使用 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防火牆或資料庫限制長串連(不推薦，迫不得已,沒辦法的辦法)