SQL Server 用戶端連接架構深度解析：從 ADO.NET 到 Net-Library 與 UMS 排程器

理解用戶端如何連接 SQL Server，是排查連線效能、驗證失敗、協議錯誤的基礎。本文自上而下剖析：物件庫 (ADO/OLE DB, ADO.NET) → Net-Library (網路協議抽象層) → 共享記憶體優化 → UMS 排程器連線綁定機制。

第一層：物件庫 / API 層 (應用程式視角)

連接字串關鍵差異

• ADO/OLE DB： Provider=SQLOLEDB; Data Source=...; Initial Catalog=...; Integrated Security=SSPI
• ADO.NET： Data Source=...; Initial Catalog=...; Integrated Security=True (無 Provider 關鍵字，直接使用 System.Data.SqlClient)。
• ODBC 橋接： ADO/OLE DB 可透過 MSDASQL (OLE DB Provider for ODBC) 使用 DSN 連接。

第二層：Net-Library (網路程式庫) - 協議抽象層

位於物件庫與網路傳輸協議之間，透明轉換請求/回應封包。SQL Server 提供所有主流協議的 Net-Library：

• TCP/IP (預設、跨網段首選)
• Named Pipes (本機/內網高效能、SMB 依賴)
• Shared Memory (本機極致效能、繞過網路堆疊)
• VIA (Virtual Interface Adapter, 高效能叢集專用)
• 舊版：NWLink IPX/SPX, AppleTalk, Banyan VINES (已淘汰)。

共享記憶體 Net-Library 詳細機制

• 前提： 用戶端與伺服器**同一台實體機器**。
• 原理： 使用 Windows 共享記憶體區域 + 同步物件 (Mutex/Event) 進行進程間通訊 (IPC)。
• 效能優勢： 繞過 TCP/IP 堆疊、網卡驅動、中斷處理，延遲極低，吞吐極高。
• 啟用方式：
  • 連接字串指定 (local) 或 . 作為伺服器名稱。
  • 或明確前綴 lpc: (Local Procedure Call) → lpc:MyServer\Instance。
• 擴展性警示： 高併發下共享記憶體同步物件爭用可能成為瓶頸，**壓測驗證**後再決定是否強制啟用。

第三層：用戶端連線與 UMS 排程器綁定

• SQL Server 啟動時，每個邏輯 CPU 建立一個 **UMS (User Mode Scheduler) 排程器**。
• 新連線建立時，指派給**當前連線數最少**的排程器 (Round-robin with load balancing)。
• 關鍵特性： 連線**終身綁定**該排程器，不會遷移。

實戰啟示：連線分配不均導致 CPU 熱點

場景：雙 CPU 伺服器，應用建立 4 條連線
排程器 0 (CPU 0) ← 連線 1, 3
排程器 1 (CPU 1) ← 連線 2, 4

問題：業務邏輯 90% 走連線 1, 3 → CPU 0 100% 滿載，CPU 1 閒置

解決方案

1. 調整連線池大小/分配邏輯：使工作負載均勻分散於所有連線。
2. 重新連線 (重啟應用/連線池)：期望新連線分配到不同排程器 (無法指定)。
3. 長期：改用分區資料表/資源調控器 從引擎層面平衡負載。

故障排查檢查清單

1. 確認用戶端使用哪種資料存取技術 (ADO.NET / OLE DB / ODBC)。
2. 檢查連接字串指定的協議 (TCP/NP/Shared Memory) 是否在**用戶端網路公用程式**啟用。
3. 伺服端 **SQL Server 組態管理員** → 網路配置 → 協議是否啟用、埠號/IP 是否正確。
4. 本機連線優先嘗試 Shared Memory 或 Named Pipes，跨機器強制 TCP/IP。
5. 連線失敗時，檢查 SQL Server 錯誤記錄、Windows 事件檢視器、Ring Buffer (連線環狀緩衝)。