在使用 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 設定
請注意，MaxUserPort 和 TcpTimedWaitDelay 設定所適用的用戶端電腦必須對執行 SQL Server 的遠端電腦快速開啟和關閉連線，且該電腦不得使用連線共用。例如，這些設定適用於提供大量內送 HTTP 要求的 Internet Information Services (IIS) 伺服器，該伺服器會對執行 SQL Server 的遠端電腦開啟和關閉連線，並使用停用了共用的 TCP/IP 通訊協定。如果有啟用共用，您就不必調整 MaxUserPort 和 TcpTimedWaitDelay 設定。
使用 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 通訊端集逾時前，建立新的通訊端連線的嘗試都會失敗。
在用戶端方面，您可能必須在停用共用時，提高 MaxUserPort 和 TcpTimedWaitDelay 設定，如 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 狀態的通訊端。
請注意，如果調整 MaxUserPort 或 TcpTimedWaitDelay 設定，則必須重新啟動 Microsoft Windows，新設定才會生效。MaxUserPort 和 TcpTimedWaitDelay 設定是針對透過 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 significant 和 Reset 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 通訊的任何用戶端電腦並無效果。
