DetailPage-MSS-KB

Knowledge Base

Artikel-ID: 328476 - Geändert am: Dienstag, 6. Februar 2007 - Version: 7.1

Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
328476  (http://support.microsoft.com/kb/328476/EN-US/ ) Description of TCP/IP settings that you may have to adjust when SQL Server connection pooling is disabled
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.

Auf dieser Seite

Zusammenfassung

Wenn Sie den SQL Server-ODBC-Treiber, den OLE DB Provider für SQL Server oder den Managed Provider "System.Data.SqlClient" verwenden, können Sie das Verbindungspooling über die entsprechenden APIs (Application Programming Interfaces) deaktivieren. Wenn Sie das Verbindungspooling deaktivieren und Ihre Anwendung häufig Verbindungen öffnet und schließt, kann die Beanspruchung der zugrunde liegenden SQL Server-Netzwerkbibliothek zunehmen. Dieser Artikel beschreibt bestimmte TCP/IP-Einstellungen, die Sie unter diesen Bedingungen eventuell anpassen müssen.

Weitere Informationen

Das Deaktivieren des Verbindungspoolings kann dazu führen, dass der zugrunde liegende SQL Server-Netzwerktreiber in schneller Folge neue Socketverbindungen zu dem Computer öffnet und schließt, auf dem SQL Server ausgeführt wird. Sie müssen möglicherweise die standardmäßigen TCP/IP-Socketeinstellungen für das Betriebssystem und den Computer ändern, auf dem SQL Server ausgeführt wird, um den höheren Belastungen des Systems Rechnung zu tragen.

Beachten Sie, dass nur die Einstellungen Gegenstand dieses Artikels sind, die bei Verwendung des TCP/IP-Protokolls Auswirkungen auf die SQL Server-Netzwerkbibliothek haben. Das Deaktivieren des Verbindungspoolings kann auch Belastungsprobleme in Bezug auf andere SQL Server-Protokolle (zum Beispiel Named Pipes) mit sich bringen, die in diesem Artikel jedoch nicht erörtert werden. Dieser Artikel richtet sich ausschließlich an fortgeschrittene Benutzer. Falls Sie die in diesem Artikel behandelten Themen nicht verstehen, empfiehlt Microsoft, zunächst ein gutes Buch über TCP/IP-Sockets zu lesen.

Beachten Sie, dass Microsoft dringend empfiehlt, in Verbindung mit den SQL Server-Treibern immer das Verbindungspooling zu verwenden. Die Verwendung des Verbindungspoolings verbessert die Gesamtleistung sowohl auf der Client- als auch auf der SQL Server-Seite erheblich, wenn Sie die SQL Server-Treiber verwenden. Außerdem wird der Netzwerkverkehr zu dem Computer, auf dem SQL Server ausgeführt wird, erheblich reduziert. Bei einem Beispieltest mit Öffnen und Schließen von 20.000 SQL Server-Verbindungen bei aktiviertem Verbindungspooling wurden ca. 160 TCP/IP-Netzwerkpakete verwendet, was Netzwerkaktivitäten mit einem Umfang von 23.520 Byte zur Folge hatte. Bei deaktiviertem Verbindungspooling wurden im Rahmen dieses Tests 225.129 TCP/IP-Netzwerkpakete generiert, was Netzwerkaktivitäten mit einem Umfang von 27.209.622 Byte zur Folge hatte.

Bei diesen durch hohe Belastung bedingten TCP/IP-Socketproblemen mit den SQL Server-Netzwerkbibliotheken, können die folgenden Fehlermeldungen angezeigt werden (eine oder mehrere), wenn Sie versuchen, eine Verbindung zu einem Computer herzustellen, auf dem SQL Server ausgeführt wird:
SQL Server ist nicht vorhanden, oder der Zugriff wurde verweigert.
Timeout abgelaufen
Allgemeiner Netzwerkfehler
Beachten Sie, dass diese Fehlermeldungen auch bei anderen Problemen in Verbindung mit SQL Server angezeigt werden können; zum Beispiel wenn der Remotecomputer, auf dem SQL Server ausgeführt wird, heruntergefahren wird oder TCP/IP-Sockets gar nicht abhört, wenn die Netzwerkverbindung zu dem SQL Server-Remotecomputer durch Herausziehen des Netzwerkkabels unterbrochen wird oder wenn es Probleme mit der DNS-Namensauflösung gibt. Grundsätzlich können alle Umstände, die dazu führen, dass der Client einen TCP/IP-Socket zu dem Computer, auf dem SQL Server ausgeführt wird, nicht öffnen kann, auch die genannten Fehlermeldungen verursachen. Durch hohe Belastung verursachte Socketprobleme treten jedoch wegen der während des Betriebs steigenden und abnehmenden Belastungen nur zeitweise auf. Der Computer kann beispielsweise stundenlang ohne Fehler ausgeführt werden, dann kann der Fehler ein oder zwei Mal auftreten, während der Computer danach wieder für mehrere Stunden fehlerfrei läuft. Außerdem kann die allgemeine Konnektivität zu SQL Server einmal funktionieren, beim nächsten Mal fehlschlagen und dann wieder einwandfrei funktionieren. Durch hohe Belastungen bedingte Socketprobleme treten also typischerweise nur sporadisch auf, was bei echten Verbindungsproblemen mit SQL Server nicht der Fall ist, die dauerhaft auftreten.

Zwei wichtige belastungsbedingte Probleme treten typischerweise dann auf, wenn Sie das Verbindungspooling deaktivieren, während Sie das SQL Server-TCP/IP-Protokoll verwenden: Die anonymen Ports auf dem Clientcomputer können zur Neige gehen oder Sie überschreiten eventuell die standardmäßige WinsockListenBacklog-Einstellung auf dem Computer, auf dem SQL Server ausgeführt wird.

Weitere Informationen zu anonymen Ports finden Sie im folgenden Artikel der Microsoft Knowledge Base:
319502  (http://support.microsoft.com/kb/319502/DE/ ) PRB: "WSAEADDRESSINUSE" Fehlermeldung, Fehlermeldung über einen anonymen Anschluss zu verbinden, nachdem Sie das IMAP-Verbindungslimit erhöhen

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  (http://support.microsoft.com/kb/154628/DE/ ) INF: SQL-Protokolle 17832 mit mehreren TCP\IP-Verbindungsanforderungen
Standardmäß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.

Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft ODBC Driver for Microsoft SQL Server 3.7
  • Microsoft OLE DB Provider for SQL Server
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft ADO.NET 1.0
  • Microsoft ADO.NET 1.1
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Keywords: 
kbinfo KB328476
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Freigeben
Weitere Supportoptionen
Microsoft Community-Supportforen
Kontaktieren Sie uns direkt
Zertifizierten Partner finden
Microsoft Store
Folgen Sie uns: