Beschreibung der TCP/IP-Einstellungen, die eventuell geändert werden müssen, wenn das SQL Server-Verbindungspooling deaktiviert ist

Anpassen der Einstellungen "MaxUserPort und "TcpTimedWaitDelay"

Beachten Sie, dass die Einstellungen MaxUserPort und TcpTimedWaitDelay nur auf einen Clientcomputer anwendbar sind, der in schneller Folge Verbindungen zu einem Remotecomputer öffnet und schließt, auf dem SQL Server ausgeführt wird und der das Verbindungspooling nicht verwendet. Diese Einstellungen sind zum Beispiel auf einem Internet Information Services-Server (IIS-Server) anwendbar, der eine große Anzahl an eingehenden HTTP-Anforderungen verarbeitet und Verbindungen zu einem Remotecomputer öffnet und schließt, auf dem SQL Server ausgeführt wird und der das TCP/IP-Protocol mit deaktiviertem Verbindungspooling verwendet. Wenn das Verbindungspooling aktiviert ist, müssen Sie die Einstellungen MaxUserPort und TcpTimedWaitDelay nicht anpassen.

Wenn Sie das TCP/IP-Protokoll verwenden, um eine Verbindung zu einem Computer zu öffnen, auf dem SQL Server ausgeführt wird, öffnet die zugrunde liegende SQL Server-Netzwerkbibliothek einen TCP/IP-Socket zu dem Computer, auf dem SQL Server ausgeführt wird. Wenn der Socket geöffnet wird, aktiviert die SQL Server-Netzwerkbibliothek die TCP/IP-Socketoption SO_REUSEADDR nicht. Weitere Informationen zur Socketeinstellung SO_REUSEADDR finden Sie unter dem Thema "Setsockopt" im Microsoft Developer Network (MSDN).

Beachten Sie, dass die SQL Server-Netzwerkbibliothek die TCP/IP-Socketoption SO_REUSEADDR aus Sicherheitsgründen nicht aktiviert. Wenn SO_REUSEADDR aktiviert ist, könnte ein böswilliger Benutzer einen Clientport zu SQL Server unter seine Kontrolle bringen und die vom Client übermittelten Anmeldeinformationen dazu verwenden, sich Zugriff auf den Computer zu verschaffen, auf dem SQL Server ausgeführt wird. Weil die SQL Server-Netzwerkbibliothek die TCP/IP-Socketoption SO_REUSEADDR standardmäßig nicht aktiviert, gelangt der Socket bei jedem Öffnen oder Schließen durch die SQL Server-Netzwerkbibliothek auf der Clientseite für vier Minuten in einen TIME_WAIT-Status. Wenn Sie bei aktiviertem Verbindungspooling in schneller Folge SQL Server-Verbindungen über TCP/IP öffnen und schließen, öffnen und schließen Sie ebenso schnell TCP/IP-Sockets. In anderen Worten: Für jede SQL Server-Verbindung gibt es einen TCP/IP-Socket. Wenn Sie schnell (in weniger als vier Minuten) 4000 Sockets öffnen und schließen, erreichen Sie die standardmäßige Maximaleinstellung für anonyme Clientports und neue Socket-Verbindungsversuche schlagen fehl, bis für die vorhandenen TIME_WAIT-Sockets eine Zeitüberschreitung eintritt.

Auf der Clientseite müssen Sie eventuell die Einstellungen für MaxUserPort und TcpTimedWaitDelay erhöhen, die im KB-Artikel Q319502 erörtert werden, wenn das Verbindungspooling deaktiviert ist. Die Einstellungen für diese Werte werden dadurch bestimmt, wie oft auf der Clientseite SQL Server-Verbindungen geöffnet und geschlossen werden. Sie können feststellen, wie viele Clientports sich in einem TIME_WAIT-Status befinden, indem Sie auf dem Clientcomputer das Dienstprogramm "Netstat" ausführen. Führen Sie das Dienstprogramm "Netstat" mit dem Flag -n wie nachstehend beschrieben aus, und zählen Sie die Clientsockets zu Ihrer SQL Server-IP-Adresse, die sich in einem TIME_WAIT-Status befinden. In diesem Beispiel lautet die IP-Adresse des Remotecomputers, auf dem SQL Server ausgeführt wird, 10.10.10.20, die IP-Adresse des Clientcomputers ist 10.10.10.10. Außerdem gibt es drei erfolgreich eingerichtete Verbindungen und zwei Verbindungen in einem TIME_WAIT-Status:

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

Wenn Sie netstat -n ausführen und sehen, dass sich fast 4000 Verbindungen zu der IP-Adresse des Zielcomputers, auf dem SQL Server ausgeführt wird, in einem TIME_WAIT-Status befinden, können Sie die Standardeinstellung MaxUserPort erhöhen und die Standardeinstellung TcpTimedWaitDelay reduzieren, damit die anonymen Clientports nicht zur Neige gehen. Sie können zum Beispiel für die Einstellung MaxUserPort den Wert 20000 und für die Einstellung TcpTimedWaitDelay den Wert 30 festlegen. Eine niedrigere Einstellung für TcpTimedWaitDelay bedeutet, dass sich die Sockets für einen kürzeren Zeitraum im TIME_WAIT-Status befinden. Ein höherer Wert für die Einstellung MaxUserPort bedeutet, dass sich mehr Sockets im TIME_WAIT-Status befinden können.

Wenn Sie die Einstellungen MaxUserPort oder TcpTimedWaitDelay ändern, müssen Sie Microsoft Windows neu starten, damit die neue Einstellung wirksam wird. Die Einstellungen MaxUserPort und TcpTimedWaitDelay gelten für jeden Computer, der über TCP/IP-Sockets mit einem anderen Computer kommuniziert, auf dem SQL Server ausgeführt wird. Diese Einstellungen habe keine Auswirkungen, wenn Sie auf dem SQL Server-Computer festgelegt werden, sofern Sie nicht lokale TCP/IP-Socketverbindungen zu diesem lokalen Computer herstellen.

Anpassen der Einstellung "WinsockListenBacklog"

Weitere Informationen zu dieser SQL Server-spezifischen Registrierungseinstellung finden Sie im folgenden Artikel der Microsoft Knowledge Base:

154628 INF: SQL-Protokolle 17832 mit mehreren TCP\IP-VerbindungsanforderungenStandardmäßig verwendet SQL Server für die Einstellung WinsockListenBacklog einen Wert von 5. Dies bedeutet, dass der Computer, auf dem SQL Server ausgeführt wird, den Wert 5 an den Backlog-Parameter der Winsock API-Abhörung übergibt, wenn er die Listening-Threads für das TCP/IP-Protokoll auf dem Computer festlegt, auf dem SQL Server ausgeführt wird. Die Backlog- oder Rückstandseinstellung steht für die maximale Länge der Warteschlange mit ausstehenden Verbindungen für den Listener. Wenn Sie den Maximalwert für diese Warteschlange überschreiten, werden weitere TCP/IP-Socket-Verbindungsversuche zu dem Computer, auf dem SQL Server ausgeführt wird, unverzüglich mit einem ACK+RESET-Paket zurückgewiesen.

Die Backlog-Einstellung funktioniert wie folgt: Nehmen Sie an, dass ein beliebiger Dienst eingehende TCP/IP-Socketanforderungen abhört. Bei einer Backlog-Einstellung von 5 und vielen Socket-Verbindungsanforderungen, die ständig eingehen, kann der Dienst die Anforderungen eventuell nicht so schnell bearbeiten wie sie eingehen. An diesem Punkt stellt die TCP/IP-Socketebene die eingehenden Anforderungen in die Backlog-Warteschlange, aus der er sie später abrufen und bearbeiten kann. Wenn die Warteschlange vollständig gefüllt ist, weist die TCP/IP-Socketebene unverzüglich alle weiteren Socketanforderungen zurück, indem Sie ein ACK+RESET-Paket an den Client sendet. Wenn Sie die Kapazität der Backlog-Warteschlange vergrößern, erhöht sich die Anzahl der ausstehenden Socket-Verbindungsanforderungen, die von der TCP/IP-Socketebene in die Warteschlange gestellt werden, bevor sie weitere Anforderungen ablehnt.

Beachten Sie, dass die Einstellung WinsockListenBacklog SQL Server-spezifisch ist. SQL Server versucht, diese Registrierungseinstellung zu lesen, wenn der SQL Server-Dienst erstmals gestartet wird. Wenn diese Einstellung nicht vorhanden ist, wird der Standardwert 5 verwendet. Ist diese Registrierungseinstellung vorhanden, liest SQL Server sie und verwendet den festgelegten Wert als Backlog-Einstellung, wenn bei der Einrichtung der TCP/IP-Listening-Threads in SQL Server die WinSock API-Abhörung aufgerufen wird.

Um festzustellen, ob Ihnen dieses Problem droht, können Sie eine Netzwerkmonitor-Ablaufverfolgung auf dem Client oder auf dem Computer ausführen, auf dem SQL Server ausgeführt wird, und dann nach Socket-Verbindungsanforderungen suchen, die unverzüglich mit einem ACK+RESET-Paket abgelehnt werden. Wenn Sie die TCP/IP-Pakete im Netzwerkmonitor überprüfen, sehen Sie ein Paket wie das folgende, wenn das beschriebene Problem auftritt:

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)

Beachten Sie, dass der Quellport 0x599 ist (1433 dezimal). Dies bedeutet, dass das Paket von einem typischen Computer stammt, auf dem SQL Server ausgeführt und der Standardport 1433 verwendet wird. Beachten Sie außerdem, dass die Flags Bestätigungsfeld signifikant (Acknowledgement field significant) und Verbindung zurücksetzen (Reset the connection) gesetzt sind. Wenn Sie mit dem Filtern einer Netzwerkmonitor-Ablaufverfolgung vertraut sind, können Sie den Wert der TCP-Flags durch 0x14 hexadezimal filtern, um nur die ACK+RESET-Pakete in der Netzwerkmonitor-Ablaufverfolgung zu sehen.

Ähnliche ACK+RESET-Pakete sehen Sie auch, wenn der SQL Server-Computer außer Betrieb ist oder das TCP/IP-Protokoll nicht abhört. Das Vorhandensein von ACK+RESET-Paketen ist also kein endgültiger Beweis dafür, dass das beschriebene Problem bei Ihnen vorliegt. Wenn der Wert für die Einstellung WinsockListenBacklog zu niedrig ist, erhalten einige Verbindungen Accept-Pakete, während andere Verbindungen im gleichen Zeitraum unverzüglich ACK+RESET-Pakete erhalten.

In sehr seltenen Fällen müssen Sie diese Einstellung eventuell auch dann anpassen, wenn das Verbindungspooling auf den Clientcomputern aktiviert ist. Wenn zum Beispiel sehr viele Clientcomputer mit einem einzelnen Computer kommunizieren, auf dem SQL Server ausgeführt wird, kann es jederzeit auch bei aktiviertem Verbindungspooling zu einer großen Anzahl zeitgleicher Verbindungsanforderungen kommen.

Hinweis: Wenn Sie die Einstellung WinsockListenBacklog ändern, müssen Sie Microsoft Windows neu starten, damit die neue Einstellung wirksam wird. Beenden Sie einfach den SQL Server-Dienst und starten Sie ihn dann neu, damit die Einstellung wirksam wird. Die Registrierungseinstellung WinsockListenBacklog gilt nur für den Computer, auf dem SQL Server ausgeführt wird. Sie hat keinerlei Auswirkungen auf Clientcomputer, die mit SQL Server kommunizieren.