SQL Server 串連基礎知識(筆記)

SQL Server 串連基礎知識(筆記) SQL Server 的查詢分析器和企業管理器是通過 ODBC 進行串連  用戶端 Net-LibraryNet-Library：在 API 或物件程式庫（應用程式使用它與 SQL Server 進行通訊）與網路通訊協定（用於與網路交換資料）之間提供了一個通道。支援的用戶端協議包括 TCP/IP、具名管道、NWLink、多協議 (RPC) 和其他一些協議  串連用戶端進行串連時，SQL Server 的使用者模式排程器 (UMS) 組件將它指定給特定的排程器。啟動時，SQL Server 為系統上的每個 CPU 建立一個單獨的 UMS 排程器。當用戶端串連到伺服器時，這些用戶端將指定給具有最少串連數的排程器。串連後，用戶端將不會更換排程器 - 它將始終受到指定排程器的控制，直到串連斷開。  串連記憶體SQL Server 為用戶端請求的每個串連保留三個資料包緩衝區。每個緩衝區的大小取決於 sp_configure 預存程序指定的預設網路資料包大小。如果預設網路資料包大小小於 8 KB，則這些資料包的記憶體將由 SQL Server 的緩衝池提供。否則，該記憶體將由 SQL Server 的 MemToLeave 地區分配。 值得一提的是，.NET Framework Data Provider for SQL Server 的預設網路資料包大小為 8KB，因此，與Managed 程式碼用戶端串連關聯的緩衝區通常由 SQL Server 的 MemToLeave 地區提供。而典型的 ADO 應用程式卻不同，它們的預設資料包大小為 4 KB，因此緩衝區將由 SQL Server 緩衝池分配。  事件串連後的用戶端請求通常分為兩種廣泛類別：語言事件和遠端程序呼叫（RPC）使用 sp_executesql 執行的動態查詢比使用 EXEC() 的查詢能夠在更大程度上避免不必要的編譯和資源消耗。  TDS從用戶端發送到 SQL Server 的 RPC、語言事件和其他類型的請求被格式化為稱作表格式資料流 (TDS) 的 SQL Server 特定資料格式。TDS 是 SQL Server 用戶端和伺服器之間使用的“語言”。目前，SQL Server 支援三種版本的 TDS：TDS 8.0（適用於 SQL 2000 用戶端）、TDS 7.0（適用於 SQL Server 7.0 用戶端）和 TDS 4.2（適用於 SQL Server 4.2、6.0 和 6.5 用戶端）。完全支援所有 SQL Server 2000 功能的版本只有 TDS 8.0。其他版本保持向後相容。  伺服器端 Net-Library在伺服器端，用戶端請求最初由 SQL Server 為偵聽特定網路通訊協定而建立的接聽程式接收。這些接聽程式由伺服器上的網路程式庫以及伺服器端的 Net-Library（在它們與伺服器之間提供管道）構成。您可以使用 SQL Server 網路公用程式設定管理員偵聽的協議。SQL Server 與用戶端支援同樣範圍的網路通訊協定（處理群集的情況除外）。對於群集化的 SQL Server，只有 TCP/IP 和具名管道可用。SQL Server 為偵聽用戶端請求所使用的每個網路通訊協定設定一個線程，並使用 Windows 的 I/O 完成連接埠機制等待和有效處理請求。從網路接收到 TDS 資料包時，Net-Library 接聽程式將其重新彙編為它們的原始用戶端請求，並將這些請求傳遞到 SQL Server 的命令處理層，即開放式資料服務 (ODS)。  將結果返回到用戶端伺服器在準備將特定用戶端請求的結果返回時，將使用最初接收請求時所用的網路堆棧。它通過伺服器端 Net-Library 將結果發送到相應的網路通訊協定，隨後這些結果將通過網路以 TDS 格式返回到用戶端。 在用戶端上，用戶端 Net-Library 將從伺服器接收的 TDS 資料包從 IPC 層重新彙編，並將其繼續轉寄到初始化該請求的 API 或物件程式庫。  小結儘管涉及了所有組件，但 SQL Server 用戶端與伺服器之間的往返過程卻相當快 - 特別是在使用記憶體 Net-Library 時，亞秒回應時間非常普遍。構建和調整您自己的 SQL Server 用戶端應用程式時，以下幾個與資料相關的問題值得注意： l         如果應用程式與 SQL Server 運行在同一台電腦上，則建議您使用共用記憶體 Net-Library（如果尚未使用它）。基於共用記憶體 Net-Library 的串連通常比其他類型的串連快很多。在注意上述內容的同時，還應：始終全面測試解決方案並將它與其他可行方案進行對比，這樣才能判斷它是否確實更好或更快。事實勝於雄辯。 l         由於用戶端在第一次串連時將指定給特定的 UMS 排程器，並只有在中斷連線後，才會擺脫該排程器的控制，因此確保在應用程式與伺服器建立的串連上均衡分配工作負載非常重要。工作負載不均衡可導致不必要的 CPU 爭用並降低資源使用率。 l         在伺服器上配置的預設網路資料包大小以及用戶端在串連時指定的網路資料包大小將直接影響它們在伺服器上所需的記憶體量和分配記憶體的池。對伺服器進行擴充性和速度配置時，應記住這一點。還應記住，預設情況下，ADO.NET 應用程式的網路資料包大小比 ADO 應用程式的更大。 l         通常，在向伺服器發送請求時，應首選 RPC 而非語言事件。為此，應在使用的 ADO 或 ADO.NET 對象中設定相應的屬性。 l         執行動態 T-SQL 時，應在可能的情況下使用 sp_executesql 代替 EXEC()。唯一例外的情況是，當使用 EXEC() 的功能將查詢片斷串連而成的動態查詢字串的大小超過單個本地變數的儲存大小時（這種情況非常少見）。 l         當遇到用戶端問題，並且懷疑它可能和串連伺服器時所用的物件程式庫或 API 有關時，可以使用的一個故障排除技巧就是更改所用的用戶端機制，這樣可以將問題歸結為特定的組件。例如，假設您升級 MDAC 並開始在 SQL Server 錯誤記錄檔中看到 17805 錯誤，這表明用戶端 ADO 應用程式發送的 TDS 資料包的格式不正確。您可能嘗試讓應用程式轉為使用 ODBC 的 OLE DB 提供者，如果您可以較為容易地做到這一點，應看看該問題是否與 SQLOLEDB 提供者有一定的關係。相反，如果基於 ADO 的應用程式一直通過 ODBC 進行串連，則可以切換到 SQLOLEDB，看看這是否能解決問題，或至少協助您縮小問題的範圍。 l         同樣，在對串連問題進行故障排除時，更改正在使用的 Net-Library 有時會有所協助。如果使用 TCP/IP，具名管道也許值得一試。例如，如果 DHCP 伺服器出現問題，並且沒有有效 IP 位址，則您將無法使用 TCP/IP 串連到 SQL Server。通過切換到具名管道，可以快速地將問題歸結為 TCP/IP 特定的因素上。另一方面，如果在切換 Net Library 後仍存在同樣的問題，則可以排除 Net-Library 方面的問題。問題的原因可能是伺服器已關閉，或在您與伺服器之間的某處網路基礎設施無法正常工作。最後，還可以容易地更改應用程式使用的 Net-Library，而不必更改應用程式本身，這樣就為您提供一個協助縮小問題範圍的工具。儘管從長遠角度而言，使用某一特定 Net-Library 並不可行，但讓用戶端臨時使用它可以協助您縮小串連相關問題的範圍。  原貼地址