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

18056?
?

客戶端無法重新使用 SPID 為 %d 的會話，該會話已被重置用于連接池。失敗 ID 為 %d。

此錯誤可能是由于先前的操作失敗引起的。

請查看錯誤日志，找出在顯示此錯誤消息之前剛發(fā)生的失敗操作。






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，狀態(tài): 1。




案例說明:


當SQLSERVER的errorlog文件中不停的報錯10856的時候，CPU同時會很低，此時SQL客戶端登陸
數(shù)據(jù)庫查詢操作正常；IIS連接數(shù)暴漲，網(wǎng)站無法操作數(shù)據(jù)庫(如登錄、基本查詢)






分析前提：
該問題很常見，官方解釋沒有很明確的答案，都是說要么需要打補丁要么需要設(shè)置IIS的連接池.
這里分析前提是數(shù)據(jù)庫已經(jīng)打了最新的補丁、IIS連接數(shù)據(jù)庫的字符串正常、用戶名和密碼正常.




分析過程：
如IIS的連接池設(shè)置1500M，IIS連接數(shù)據(jù)正常1500個，那么每個session分到的連接池大小平均1MB，
數(shù)據(jù)庫網(wǎng)絡(luò)數(shù)據(jù)包默認是4096；

如果這個時候有個請求需要返回20M數(shù)據(jù)，那么這個session從數(shù)據(jù)庫返回的數(shù)據(jù)包大小就要超過session
獲得的連接池大小，數(shù)據(jù)包是4096，比正常的請求(請求1M的回話)就需要多的數(shù)據(jù)包傳遞，這個session對應(yīng)的
回話保持時間就需要比平均水平長些，正常情況下，這些獨大的請求不會有太大問題.
如果同一時刻，IIS的請求數(shù)達到3000,每個SESSION分到的連接池大小平均值就會0.5MB，如果同樣返回20MB數(shù)據(jù)，
那么SESSION的時間就會更長！
如果這個時候客戶端請求返回100個30M數(shù)據(jù)，那么此時的請求，當數(shù)據(jù)庫返回給IIS時，IIS會發(fā)現(xiàn)連接池沒有足夠的內(nèi)存空間
分配這個SESSION，此時IIS的連接池大小不會隨著客戶端請求的增加而自動增加或IIS服務(wù)器沒有更多的物理內(nèi)存，此時IIS就會
因為沒有足夠的連接池空間分配來緩存對應(yīng)的SESSION，但是后續(xù)的客戶端回話還是不停的向IIS申請，這個時候問題就來啦！
IIS會釋放掉(或IIS進程down掉或IIS自動重啟)沒法處理的SESSION，當數(shù)據(jù)庫收到IIS端SESSION請求查詢出數(shù)據(jù)準備返回給
IIS的SESSION時，去尋找對應(yīng)請求的SPID，發(fā)現(xiàn)該請求的SPID已經(jīng)不存在，但是數(shù)據(jù)庫的TCP連接不會因為SPID的不存在立即拋棄這些
數(shù)據(jù)，此時網(wǎng)卡的流量會增加！同時數(shù)據(jù)庫ERRORLOG里全是這種錯誤.

解決辦法：
0.首先排除DB是否有死鎖
1.最直接的辦法就是增加IIS連接池大小
2.就是找出程序中大的會話請求，修改代碼
3.限制IIS進程數(shù)上限,根據(jù)日常運行情況設(shè)置連接池大小(不推薦，迫不得已)
4.數(shù)據(jù)庫端限制sql回話時常:SQL防火墻或數(shù)據(jù)庫限制長連接(不推薦，迫不得已,沒辦法的辦法)

SQLSERVER 18056 錯誤