說明當停用 SQL Server 連接共用時,您可能要調整的 TCP/IP 設定

文章翻譯 文章翻譯
文章編號: 328476
全部展開 | 全部摺疊

在此頁中

結論

在使用 SQL Server ODBC 驅動程式、SQL Server OLE DB 提供程式或 System.Data.SqlClient Managed 提供者時,可以使用個別的應用程式發展介面 (API,Application Programming Interfaces) 停用連線共用。停用共用時,如果應用程式頻繁地開啟和關閉連線,則基礎 SQL Server 網路程式庫的負荷可能會增加。本文將告訴您在這種情況下,可能需要調整的特定 TCP/IP 設定。

其他相關資訊

關閉共用可能會導致基礎 SQL Server 網路驅動程式針對執行 SQL Server 的電腦,快速地開啟與關閉新的通訊端連線。您可能必須變更作業系統以及執行 SQL Server 之電腦的預設 TCP/IP 通訊端設定,才能處理較高的負荷層級。

請注意,本文只討論在使用 TCP/IP 通訊協定時,對 SQL Server 網路會造成影響的設定。關閉共用可能會導致其他 SQL Server 通訊協定 (例如具名管道) 發生與負荷相關聯的問題,但本文並不會討論這個主題。此資訊僅供進階使用者參考。如果您不瞭解本文中的主題,Microsoft 建議您查閱有關 TCP/IP 通訊端的參考書。

請注意,Microsoft 強烈建議您一定要透過 SQL Server 驅動程式使用共用。使用 SQL Server 驅動程式時如果有利用共用,就能夠同時大幅提升用戶端和 SQL Server 端的整體效能。執行 SQL Server 的電腦的網路流量,也會因為使用共用而大幅降低。例如,在使用 20,000 次開啟和關閉 SQL Server 連線的範例測試中,如果有啟用共用,則使用的 TCP/IP 網路封包為 160 個,網路活動的總量為 23,520 位元組。如果停用共用,則同樣的範例測試所產生的 TCP/IP 網路封包為 225,129 個,網路活動總量則達 27,209,622 位元組。

請注意,當您發現 SQL Server 網路程式庫發生這些與負荷相關聯的 TCP/IP 通訊端問題時,則在嘗試連線至執行 SQL Server 的電腦時,可能會接到一或多個下列的錯誤訊息:
SQL Server 不存在或拒絕存取
Timeout Expired (已超過連接逾時的設定)
一般網路錯誤
請注意,您也可能會在 SQL Server 發生其他問題時接到這些特定的錯誤訊息;例如,如果執行 SQL Server 的遠端電腦關閉、執行 SQL Server 的遠端電腦完全沒有接聽 TCP/IP 通訊端、執行 SQL Server 的電腦的網路連線因為網路電纜線拔起而中斷,或者發生 DNS 解析的問題,您也可能會接到這些錯誤訊息。基本上,任何可能導致用戶端無法對執行 SQL Server 電腦開啟 TCP/IP 通訊端的情況,都可能導致這些錯誤訊息。不過,如果通訊端問題是與負荷相關,則隨著負荷量的高低起伏,問題也會間歇性地發生。電腦可能會執行好幾個小時而沒有錯誤,然後發生一兩次錯誤,接著又連續數個小時沒有任何錯誤。此外,當您發生這種問題時,SQL Server 的一般連線在上一秒鐘可能可以正常運作,下一秒鐘發生問題,但接下來又恢復正常。換言之,與負荷相關的通訊端問題通常都是偶發性的,但是真正的 SQL Server 網路連線問題則通常不會是偶發性的。

如果在使用 SQL Server TCP/IP 通訊協定時停用共用,通常會發生兩種與負荷相關的主要問題:用戶端電腦的匿名通訊埠可能會用盡,或者超出執行 SQL Server 電腦上的預設 WinsockListenBacklog 設定。

如需有關匿名通訊埠的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:
319502 PRB: "WSAEADDRESSINUSE" Error Message When You Try to Connect Through an Anonymous Port After You Increase the IMAP Connection Limit

調整 MaxUserPort 和 TcpTimedWaitDelay 設定

請注意,MaxUserPortTcpTimedWaitDelay 設定所適用的用戶端電腦必須對執行 SQL Server 的遠端電腦快速開啟和關閉連線,且該電腦不得使用連線共用。例如,這些設定適用於提供大量內送 HTTP 要求的 Internet Information Services (IIS) 伺服器,該伺服器會對執行 SQL Server 的遠端電腦開啟和關閉連線,並使用停用了共用的 TCP/IP 通訊協定。如果有啟用共用,您就不必調整 MaxUserPortTcpTimedWaitDelay 設定。

使用 TCP/IP 通訊協定對執行 SQL Server 的電腦開啟連線時,基礎的 SQL Server 網路程式庫會對執行 SQL Server 的電腦開啟 TCP/IP 通訊端。在開啟這個通訊端時,SQL Server 網路程式庫不會啟用 SO_REUSEADDR TCP/IP 通訊端選項。如需有關 SO_REUSEADDR 通訊端設定的詳細資訊,請參閱 Microsoft Developer Network (MSDN) 中的 Setsockopt 主題。

請注意,SQL Server 網路程式庫因為安全性因素,而特別不啟用 SO_REUSEADDR TCP/IP 通訊端選項。當 SO_REUSEADDR 啟用時,惡意使用者可能會劫持 SQL Server 的用戶端通訊埠,並使用用戶端所提供的憑證取得執行 SQL Server 的電腦存取權。根據預設,因為 SQL Server 網路程式庫不會啟用 SO_REUSEADDR 通訊端選項,所以每次您透過用戶端的 SQL Server 網路程式庫開啟和關閉通訊端時,該通訊端都會進入 TIME_WAIT 狀態 4 分鐘。如果您要透過停用共用的 TCP/IP 快速地開啟和關閉 SQL Server 連線,就必須快速地開啟和關閉 TCP/IP 通訊端。換言之,每個 SQL Server 連線都具備一個 TCP/IP 通訊端。如果您在 4 分鐘內快速地開啟和關閉 4000 個通訊端,就會達到用戶端匿名通訊埠的預設設定上限,且在現有的 TIME_WAIT 通訊端集逾時前,建立新的通訊端連線的嘗試都會失敗。

在用戶端方面,您可能必須在停用共用時,提高 MaxUserPortTcpTimedWaitDelay 設定,如 Q319502 中所述。這些值的設定是由在用戶端上開啟和關閉的 SQL Server 連線數目而定。您可以藉由在用戶端上使用 Netstat 工具,檢查有多少用戶端通訊埠處於 TIME_WAIT 狀態。請使用 -n 旗標執行 Netstat 工具,並計算連至 SQL Server IP 位址且處於 TIME_WAIT 狀態的用戶端通訊端數目。在這個範例中,執行 SQL Server 的用戶端電腦所用的 IP 位址是 10.10.10.20,用戶端電腦的 IP 位址是 10.10.10.10,而三個已建立的連線和兩個連線是處於 TIME_WAIT 狀態:
C:\>netstat -n

Active Connections

  Proto  Local Address         Foreign Address       State
  TCP    10.10.10.10:2000      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2001      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2002      10.10.10.20:1433      ESTABLISHED
  TCP    10.10.10.10:2003      10.10.10.20:1433      TIME_WAIT
  TCP    10.10.10.10:2004      10.10.10.20:1433      TIME_WAIT
				
如果您執行 netstat -n,而且看到有接近 4000 個執行 SQL Server 的目標電腦的 IP 位址連線是處於 TIME_WAIT 狀態,就可以同時增加 MaxUserPort 的預設設定並減少 TcpTimedWaitDelay 設定,使您不會耗盡用戶端匿名通訊埠。例如,您可以將 MaxUserPort 設定為 20000,並將 TcpTimedWaitDelay 設定為 30。較低的 TcpTimedWaitDelay 設定代表通訊端會處於 TIME_WAIT 狀態較短的時間。較高的 MaxUserPort 設定則代表您可以有更多處於 TIME_WAIT 狀態的通訊端。

請注意,如果調整 MaxUserPortTcpTimedWaitDelay 設定,則必須重新啟動 Microsoft Windows,新設定才會生效。MaxUserPortTcpTimedWaitDelay 設定是針對透過 TCP/IP 通訊端與執行 SQL Server 的電腦通訊的電腦而定。這些設定如果是設定於執行 SQL Server 的電腦則不會有任何效果,除非是對執行 SQL Server 的本機電腦進行本機的 TCP/IP 通訊端連線。

調整 WinsockListenBacklog 設定

如需有關這項 SQL Server 特定登錄設定的詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:
154628 INF:發生多個 TCP\IP 連線請求時 SQL 會記錄 17832
根據預設,SQL Server 會使用 5 的 WinsockListenBacklog 設定。這表示執行 SQL Server 的電腦在設定 TCP/IP 通訊協定接聽執行緒時,會將 5 這個值傳遞給 Winsock API 接聽的積存參數。積存設定是指接聽程式擱置連線佇列的最大長度。如果超過這個佇列,則連到執行 SQL Server 的電腦的其他 TCP/IP 通訊端連線嘗試就會立即被拒絕,並傳送 ACK+RESET 封包。

積存設定的作業方式如下:假設有任一服務正在接聽內送的 TCP/IP 通訊端要求。如果您將積存設定設定為 5,而有許多通訊端連線要求持續湧入,則服務可能無法在內送要求一進來時就加以回應。此時 TCP/IP 通訊端層便會將這些內容要求佇列於積存佇列中,這麼一來,服務就可以稍後再將要求從此佇列中提取出來,並處理內送的通訊端連線要求。在佇列填滿後,TCP/IP 通訊端層會藉由回傳 ACK+RESET 封包給用戶端,立刻拒絕任何內送的其他通訊端要求。增加積存佇列大小會增加擱置的通訊端連線要求的數量,TCP/IP 通訊端層會先將這些要求排入佇列,若空間不足才會加以拒絕。

請注意,WinsockListenBacklog 設定是 SQL Server 所專用。SQL Server 會在 SQL Server 服務第一次啟動時,嘗試讀取這個登錄設定。如果該設定不存在,就會使用預設值 5。如果該登錄設定存在,則 SQL Server 會讀取該設定,並在呼叫 WinSock API 接聽時 (在 SQL Server 內部設定 TCP/IP 通訊端的接聽執行緒時),使用提供的值當作積存設定。

若要判斷是否遇到這個問題,可以在執行 SQL Server 的用戶端或電腦上執行網路監視器,尋找被立刻拒絕且傳回 ACK+RESET 的通訊端連線要求。如果是在網路監視器中檢查 TCP/IP 封包,就會在發生這個問題時,看到類似以下的封包:
Frame: Base frame properties
ETHERNET:  EType = Internet IP (IPv4) 
IP: Protocol = TCP - Transmission Control; Packet ID = 40530; Total IP Length = 40; Options = No Options
TCP: Control Bits: .A.R.., len:    0, seq:         0-0, ack:3409265780, win:    0, src: 1433  dst: 4364 
  TCP: Source Port = 0x0599	
  TCP: Destination Port = 0x110C
  TCP: Sequence Number = 0 (0x0)
  TCP: Acknowledgement Number = 3409265780 (0xCB354474)
  TCP: Data Offset = 20 bytes
  TCP: Flags = 0x14 : .A.R..
    TCP: ..0..... = No urgent data
    TCP: ...1.... = Acknowledgement field significant
    TCP: ....0... = No Push function
    TCP: .....1.. = Reset the connection
    TCP: ......0. = No Synchronize
    TCP: .......0 = Not the end of the data
  TCP: Window = 0 (0x0)
  TCP: Checksum = 0xF1E7
  TCP: Urgent Pointer = 0 (0x0)
				
請注意,來源通訊埠是 0x599,或 1433 (十進位格式)。這代表封包是來自於執行 SQL Server 且在預設的 1433 通訊埠上執行的一般電腦。此外也請注意,Acknowledgement field significantReset the connection 旗標也已設定。如果您熟悉如何篩選網路監視器追蹤,就可以藉由 0x14 十六進位篩選 TCP 旗標值,只查看網路監視器追蹤中的 ACK+RESET 封包。

請注意,如果執行 SQL Server 的電腦完全沒有執行,或者執行 SQL Server 的電腦並未接聽 TCP/IP 通訊協定,您也可能看到類似的 ACK+RESET 封包,所以看到 ACK+RESET 封包並不絕對代表發生了這個問題。如果 WinsockListenBacklog 設定過低,則某些連線嘗試會收到接受封包,而同段時程內的某些連線則會立刻收到 ACK+RESET 封包。

請注意,在極少數的狀況中,就算用戶端電腦啟用了共用,您也可能必須調整這個設定。例如,如果許多用戶端電腦與執行 SQL Server 的單一電腦通訊,則即使啟用了共用,也可能在任一特定時間同時發生大量的內送連線嘗試。

注意如果您調整 WinsockListenBacklog 設定,則不必重新啟動 Windows,此設定也可生效。只要停止並重新啟動 SQL Server 服務,此設定即可生效。WinsockListenBacklog 登錄設定只能用於執行 SQL Server 的電腦,對與 SQL Server 通訊的任何用戶端電腦並無效果。

屬性

文章編號: 328476 - 上次校閱: 2011年2月16日 - 版次: 7.2
關鍵字:?
kbsqldeveloper kbinfo KB328476
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應,不負任何擔保責任。Microsoft及(或)其供應商謹此聲明,不負任何對與此資訊有關之擔保責任,包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。

提供意見

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com