SQL Server 18056 錯誤導致效能驟降：根因分析與解決方案

錯誤 18056：連接池 Session 重置失敗的深度剖析

錯誤訊息：
The client was unable to reuse a session with SPID xxx, which had been reset for connection pooling. The failure ID is 1. This error may have been caused by an earlier operation failing.

現象：ERRORLOG 大量刷 18056 錯誤、CPU 使用率異常偏低、IIS 連線數暴增、網站無法操作資料庫（登入、查詢皆失敗），但 SSMS 直連資料庫卻正常。

核心成因：連接池記憶體不足導致 Session 被迫釋放

1. IIS 連接池大小固定（如 1500 MB），連線數達上限（如 1500），平均每 Session 可用 ~1 MB 緩衝區。
2. 大量資料回傳請求（如單次 20~30 MB），需大量 4KB 網路封包傳輸，佔用連接池記憶體遠超平均值，導致 Session 持有時間拉長。
3. 並發尖峰：同時湧入大量大資料請求，IIS 連接池記憶體耗盡，無法分配新 Session 緩衝區。
4. IIS 強制釋放/重啟：為求生存，IIS 釋放無法處理的 Session（或進程 Down/自動回收）。
5. 資料庫端無感知：SQL Server 已備妥資料準備回傳，卻找不到對應 SPID（Session 已被 IIS 端釋放），TCP 連線未立即斷開，網卡流量飆升，ERRORLOG 狂噴 18056。

排除與解決路徑

實戰檢核清單

• ☐ 確認 SQL Server 已套用最新 CU/SP 修補程式（官方多個 18056 相關修正）。
• ☐ 檢查 IIS 連接字串：Pooling=true; Max Pool Size=... 設定合理。
• ☐ 監控 sys.dm_exec_sessions、sys.dm_exec_requests 觀察大資料查詢模式。
• ☐ 啟用 sp_WhoIsActive 或 Extended Events 長期捕捉等待類型（ASYNC_NETWORK_IO 通常伴隨）。
• ☐ 規劃容量：依峰值並發 × 平均大資料回傳量 估算所需連接池記憶體，預留 30% 緩衝。

總結

18056 本質是 應用層（IIS）連接池記憶體瓶頸倒逼資料庫層 Session 異常終止。治標擴大連接池，治本優化大資料查詢與架構（如引入快取、分頁、非同步串流），並建立完善的容量規劃與監控機制。