Behandeln von zeitweiligen oder regelmäßigen Problemen beim Herstellen einer Verbindung mit SQL Server

Zusammenfassung

In diesem Artikel wird erläutert, wie Sie sporadische oder periodisch auftretende netzwerkbezogene Probleme bei der Problembehandlung identifizieren, die dazu führen, dass SQL Server-Verbindungen fehlschlagen, bei denen ein Timeout auftritt oder die unerwartet zurückgesetzt werden. Es beschreibt die häufigsten Fehlermeldungen, die zugrunde liegenden Ursachen (z. B. verworfene Pakete, Antivirenfilter oder erschöpfte ephemerale Ports) und einen datengesteuerten Problembehandlungsprozess basierend auf SQLCHECK, SQLTRACE und Netzwerkablaufverfolgungsanalyse mit SQL Network Analyzer (SQLNA). Verwenden Sie sie, um zu ermitteln, ob das Problem auf dem Client, auf dem Server oder im Netzwerkpfad zwischen ihnen liegt.

Notiz

Bevor Sie mit der Problembehandlung beginnen, überprüfen Sie die Voraussetzungen , und durchlaufen Sie die Checkliste. Weitere Informationen finden Sie in den Self-Help-Artikeln.

Häufige Fehlermeldungen für zeitweilige SQL Server Konnektivitätsprobleme

Zeitweilig auftretende Probleme treten unregelmäßig auf, während regelmäßige Probleme in vorhersagbaren Intervallen auftreten. Die Identifizierung des Problemtyps ist der erste Schritt bei der Problembehandlung. Wenn zeitweilige oder periodische SQL Server Verbindungsprobleme auftreten, treten möglicherweise die folgenden Fehlermeldungen auf:

  • Kommunikationsverbindungsfehler: Dieser Fehler zeigt eine Unterbrechung der Kommunikation zwischen Netzwerkkomponenten an.
  • Zeitüberschreitung der Verbindung: Bei der Verbindung mit dem Server ist eine Zeitüberschreitung aufgetreten, was auf eine Verzögerung oder Nichtverfügbarkeit des Servers hindeutet.
  • Allgemeiner Netzwerkfehler: Eine allgemeine Netzwerkfehlermeldung weist häufig auf ein nicht angegebenes Problem mit dem Netzwerk hin.
  • Fehler auf Transportebene: Dieser Fehler tritt auf der Transportebene auf und schlägt Probleme mit der Datenübertragung vor.
  • Der angegebene Netzwerkname ist nicht mehr verfügbar: Diese Meldung impliziert, dass die angegebene Netzwerkressource nicht erreicht werden kann.
  • Semaphortimeout: Dieser Fehler verweist auf eine Timeoutbedingung im Zusammenhang mit der Verwendung von Semaphoren im Netzwerk.
  • Zeitüberschreitung des Wartevorgangs: Ein Wartevorgang hat die zulässige Zeit überschritten, in der Regel aufgrund von Netzwerkverzögerungen.
  • Schwerwiegender Fehler beim Lesen des Eingabedatenstroms aus dem Netzwerk: Diese Meldung schlägt beim Lesen von Daten aus dem Netzwerk einen kritischen Fehler vor.
  • Protokollfehler im TDS-Datenstrom: Tabular Data Stream (TDS) ist ein Protokoll, das von SQL Server verwendet wird. Dieser Fehler weist auf ein Problem mit dem Protokoll hin.
  • Der Server wurde nicht gefunden oder ist nicht erreichbar: Diese Fehlermeldung weist darauf hin, dass der Server, auf den Sie zugreifen möchten, nicht verfügbar ist oder nicht gefunden werden kann.
  • SQL Server ist nicht vorhanden oder zugriff verweigert: Dieser Fehler kann auf das Fehlen von SQL Server oder einen Authentifizierungsfehler hinweisen, wenn versucht wird, auf SQL Server zuzugreifen.

Häufige Ursachen für zeitweilige SQL Server Konnektivitätsprobleme

Die häufigsten Probleme sind Paketabbrüche, die durch Antivirensoftware, Netzwerkoptimierung, veraltete Netzwerktreiber, fehlerhafte Router oder Switches und nicht poolierte Verbindungen in der Anwendung verursacht werden.

Einige Ursachen, z. B. Antivirensoftware, können schwierig zu beweisen sein, sind aber immer noch üblich. Möglicherweise müssen Sie die Software deinstallieren und den Computer neu starten, um ihn zu beweisen, ohne eindeutige Beweise. Das Erstellen einer Ausnahme für SQL Server funktioniert möglicherweise auch. Das Deaktivieren des Antivirenprogramms funktioniert in der Regel jedoch nicht, da die Netzwerkfiltertreiber weiterhin geladen werden, auch wenn sie nicht überwacht werden.

Problembehandlungsprozess

Notiz

Dieser Prozess wurde für SQL Server-Client- und Serververbindungen entwickelt. Andere Kommunikationsvorgänge, wie etwa SQL Server-Spiegelung, Always On und der Service Broker-Synchronisierungsdatenverkehr über Port 5022, werden nicht berücksichtigt.

Im Allgemeinen sollte die Problembehandlung datengesteuert sein, was empirische Tests in einem stärker fokussierten Kontext ermöglichen kann. Wenn das Problem sehr intermittiert ist und Netzwerkspuren schwer zu erfassen sind, wenden Sie zuerst die empirischen Methoden an.

Sammeln eines Berichts mithilfe von SQLCHECK auf jedem Computer

Führen Sie SQLCHECK auf jedem Computer aus, um einen Bericht zu erstellen. Es ist hilfreich, zu ermitteln, warum eine Verbindung fehlschlägt.

Sammeln von Netzwerkablaufverfolgungen auf dem Client und Server

  • Sammeln Sie auf Windows-Computern Netzwerkablaufverfolgungen mithilfe von SQLTRACE.

    Führen Sie die folgenden Schritte aus, um die Ablaufverfolgung vorzubereiten und aufzuzeichnen. Die Schritte 2 und 3 müssen nur einmal ausgeführt werden.

    1. Laden Sie die neueste Version von SQLTRACE herunter, und entpacken Sie sie in einen Ordner, z . B. C:\MSDATA.

    2. Öffnen Sie die SQLTrace.ini Datei, und deaktivieren Sie die folgenden Einstellungen:

      BIDTrace=no, AuthTrace=no und EventViewer=no

    3. Speichern Sie die Datei .

    4. Öffnen Sie PowerShell als Administrator, und ändern Sie das Verzeichnis in den Ordner, der SQLTrace.ps1 enthält.

      CD C:\MSDATA

    5. Starten Sie die Ablaufverfolgungsauflistung.

      .\SQLTrace.ps1 -start

    6. Reproduzieren Sie das Problem, oder warten Sie, bis der Fehler auftritt.

    7. Beenden Sie die Ablaufverfolgung.

      .\SQLTrace.ps1 -stop

    Der Prozess erstellt einen Ausgabeordner im aktuellen Verzeichnis. Verwenden Sie diesen Ordner zur weiteren Analyse.

  • Verwenden Sie auf Nicht-Windows-Computern TCPDUMP oder WireShark, um eine Paketerfassung zu sammeln.

Ausführen der SQL Server-Netzwerkanalyse

SQL Network Analyzer UI (SQLNAUI) bietet eine grafische Benutzeroberfläche zum Auswählen von Trace-Dateien zur Analyse sowie zum Festlegen von Optionen. Laden Sie es von SQL Network Analyzer (SQLNA) herunter.

Verarbeiten sie Client- und Serverablaufverfolgungen separat. Wenn Sie miteinander verkettete Traces haben, verarbeiten Sie sie gemeinsam. Die Gesamtgröße dieser Dateien darf 80 % des Arbeitsspeichers Ihres Computers nicht überschreiten. Stellen Sie sicher, dass genügend Arbeitsspeicher vorhanden ist, um alle zugehörigen Ablaufverfolgungsdateien zu verarbeiten.

Dieses Tool generiert einen Bericht über verdächtige Probleme und eine CSV-Datei, die Sie in Excel für alternative Recherchen erkunden können.

Versuchen Sie, übereinstimmende Unterhaltungen in der Clientablaufverfolgung und der Serverablaufverfolgung zu finden. Im Allgemeinen stimmen die IP-Adressen und Portnummern überein. Wenn die Verbindungen jedoch irgendeine Form von Netzwerkadressübersetzung oder Portzuordnung durchlaufen, kann es schwieriger sein, und Sie müssen sie möglicherweise anhand von IPv4-Paket-IDs aufeinander abstimmen und die Nutzdaten vergleichen.

Muster, auf die bei der Analyse von Netzwerkablaufverfolgungen zu achten ist

Untersuchen Sie, wie die Unterhaltungen in NETMON oder WireShark enden. Überprüfen Sie, ob sich der Client und der Server mit demselben Punkt einverstanden erklären oder eine andere Geschichte erzählen.

Die Verbindung wurde während des SSL-Handshake geschlossen.

Wenn die verwendete Verschlüsselungssuite im ServerHello-Paket eine Diffie-Hellman-Suite ist und der Datenverkehr zwischen Windows 2012 oder früher und Windows 2016 oder höher erfolgt, ändert sich dieser Algorithmus ab Windows 2016-Sicherheitspatches. Sie sollten diese Gruppe von Cipher Suites deaktivieren. Weitere Informationen finden Sie unter Bei Anwendungen treten unter Windows beim Herstellen einer Verbindung mit SQL Servern Fehler aufgrund zwangsweise geschlossener TLS-Verbindungen auf.

Wenn die Verbindung nach dem ClientHello geschlossen wird, überprüfen Sie, ob zwischen Client und Server ein TLS 1.0- oder TLS 1.2-Konflikt besteht. Wenn sie identisch sind, überprüfen Sie die aktivierten Verschlüsselungssammlungen und aktivierten Hashes auf beiden Computern.

Weitere Informationen finden Sie unter Advanced Secure Sockets Layer Data Capture.

Verworfene Pakete

Zeigen Sie das Ende von übereinstimmenden Konversationen an. Wenn eine Seite viele erneut übertragene Pakete aufweist (oder 10 Keep-Alive-Pakete im Abstand von jeweils 1 Sekunde), gefolgt von einem ACK+RESET, und die andere nicht, oder wenn eine Seite eine rechtzeitige Antwort meldet und die andere sie verzögert sieht und die Verbindung schließt oder zurücksetzt, deutet dies auf ein Problem mit dem Netzwerkgerät hin und darauf, dass Pakete verworfen oder verzögert werden.

Möglicherweise wird auch der Clientbericht angezeigt, der angibt, dass der Server die Unterhaltung zurücksetzt, und der Serverbericht, der angibt, dass der Client die Unterhaltung zurücksetzt. Dies ist auf einen fehlerhaften Switch oder Router zurückzuführen, der die Verbindung mittendrin unterbricht und unter Umständen so konfiguriert ist, dass er dies tut, wenn er feststellt, dass die Verbindung eine Zeit lang inaktiv war – wobei Keep-Alive-Pakete oft ignoriert werden.

Weitere Informationen zu verworfenen Verbindungen finden Sie unter:

Sowohl die Serverablaufverfolgung als auch die Clientablaufverfolgung stimmen zu, dass das Problem auf dem Client liegt.

Wenn beide Ablaufverfolgungen eine Verzögerung oder keine Antwort auf dem Client anzeigen oder wenn der Client nach der Bestätigung einer Serverantwort ein ACK+RESET ausgibt oder anderweitig die Verbindung früh während der Anmeldesequenz schließt, müssen Sie eine BID-Ablaufverfolgung und eine NETSH-Ablaufverfolgung auf dem Client ausführen, um innerhalb des TCP/IP-Stapels zu suchen und was der Treiber denkt. Dies ist häufig der Fall, wenn die Antiviren- oder andere Netzwerkfiltertreiber den Empfang des Pakets oder das Senden der Antwort verzögern. Verbindungstimeouts können auch auf eine langsame DNS-Antwort oder eine langsame Sicherheits-API zurückzuführen sein, die aufgerufen wurde, bevor das anfängliche SYN-Paket über die Verbindung gesendet wurde.

Überprüfen Sie den Bericht zu den ephemeren Ports des SQL Network Analyzer, und stellen Sie sicher, dass dem Client die ausgehenden Ports nicht ausgehen.

Wenn der Client das SYN-Paket erst mit großer Verzögerung sendet, kann ein Muster zu sehen sein, das nur den TCP-3-Wege-Handshake beim Verbindungsaufbau zeigt, gefolgt unmittelbar danach oder manchmal erst nach dem Senden des PreLogin-Pakets von einem vom Client gesendeten ACK+FIN.

Sammeln Sie eine Netzwerkverfolgung und eine BID-Ablaufverfolgung zur Eingrenzung von Clientproblemen in Windows

  1. Öffnen Sie die SQLTrace.ini Datei, und aktivieren Sie die folgenden Einstellungen wieder:

    BIDTrace=Yes, AuthTrace=Yes und EventViewer=Yes

  2. Konfigurieren Sie die BIDProviderList in SQLTrace.ini so, dass sie dem verwendeten Treiber entspricht.

    .NET System.Data.SqlClient ist standardmäßig aktiviert. Wenn dies nicht der Treiber ist, den Sie verwenden, deaktivieren Sie BIDProviderList, indem Sie # an den Anfang der Zeile setzen, und entfernen Sie BIDProviderList vom Anfang der ODBC- oder OLEDB-Liste. Dadurch werden alle unterstützten Treiber dieses Typs erfasst. Weitere Informationen finden Sie unter INI-Konfiguration.

  3. Speichern Sie die Datei .

  4. Öffnen Sie PowerShell als Administrator, und ändern Sie das Verzeichnis in den Ordner, der SQLTrace.ps1 enthält.

    CD C:\MSDATA

  5. Initialisieren Sie die Registrierung für die BID-Ablaufverfolgung, falls BID-Ablaufverfolgungen gesammelt werden.

    Notiz

    DIE BID-Ablaufverfolgung ist standardmäßig aktiviert.

    .\SQLTrace.ps1 -setup

  6. Starten Sie den Dienst oder die Anwendung neu, den Sie nachverfolgen möchten.

    Bei einigen Anwendungen, z. B. SQL Server Integration Services (SSIS)-Paketen, wird beim Ausführen des Pakets eine neue Instanz von DTEXEC oder ISServerExec gestartet, sodass ein Neustart nicht sinnvoll ist.

  7. Starten Sie die Ablaufverfolgungsauflistung.

    .\SQLTrace.ps1 -start

  8. Reproduzieren Sie das Problem, oder warten Sie, bis der Fehler auftritt.

  9. Beenden Sie die Ablaufverfolgung.

    .\SQLTrace.ps1 -stop

Der Prozess erstellt einen Ausgabeordner im aktuellen Verzeichnis. Verwenden Sie diesen Ordner zur weiteren Analyse.

Informationen zum Nachverfolgen anderer Microsoft SQL Server-Treiber finden Sie in den folgenden Artikeln. Führen Sie dies mithilfe einer Netzwerkablaufverfolgung aus.

Informationen zum Nachverfolgen von Drittanbietertreibern finden Sie in der Herstellerdokumentation.

Sowohl die Serverablaufverfolgung als auch die Clientablaufverfolgung stimmen zu, dass sich das Problem auf dem Server befindet.

Wenn beide Ablaufverfolgungen eine Verzögerung oder keine Antwort auf dem Server anzeigen oder wenn der Server die Verbindung an einem unerwarteten Punkt in der Anmeldesequenz schließt, oder wenn der Server viele Verbindungen gleichzeitig schließt, weist dies darauf hin, dass auf dem Server einige Probleme auftreten.

Die wahrscheinlichsten Ursachen sind schlechte Serverleistung, hohe MAXDOP, große parallele Abfragen und Blockieren. Diese Bedingungen können zu Threadverhungern führen, wodurch eine Authentifizierungsanforderung nicht zeitnah bearbeitet werden kann, insbesondere wenn viele Verbindungstimeouts gleichzeitig enden und in der Spalte „LoginAck“ „Late“ angezeigt wird. Die SQL Server-ERRORLOG-Datei zeigt möglicherweise, dass E/A-Vorgänge länger als 15 Sekunden dauern, was ein weiterer Hinweis auf Leistungsprobleme ist. In der Netzwerkablaufverfolgung werden möglicherweise auch viele Verbindungen im Reset-Bericht mit sechs oder weniger Frames angezeigt, was darauf hindeutet, dass der TCP-3-Wege-Handshake möglicherweise nicht vollständig abgeschlossen wurde. Weitere Informationen finden Sie unter Ringpuffer für Konnektivität erfassen.

Führen Sie die RingBufferConnectivity Abfrage aus, und fügen Sie die Ergebnisse in Excel ein. Da diese Liste historisch ist, können Sie sie nach dem Auftreten des Problems ausführen. Aber für einen ausgelasteten Server kann es schnell enden. Bei einem langsamen Server gibt es möglicherweise Daten für ein paar Tage.

Wenn Ihre Anwendung mehrere aktive Resultsets (MARS) verwendet, endet sie im Rahmen der Abschlusssequenz mit einem RESET. Dies ist gut, wenn die SMP:FIN- und ACK+FIN-Pakete bereits vom Client gesendet wurden. Das SMP:FIN-Paket des Servers wird nach ACK+FIN vom Client eintreffen, und Windows gibt ein ACK+RESET und dann ein RESET für alle anderen Serverantworten als Teil der Verbindungsschließsequenz aus.

Verbindungspooling

Weitere Informationen finden Sie unter Verbindungspooling.

Wenn Sie verbindungspooling verwenden, sind Unterhaltungen in der Netzwerkablaufverfolgung in der Regel ziemlich lang. Sie können die VON SQL Server Network Analyzer generierte CSV-Datei verwenden, um nach Protokollen und Frames zu sortieren und zu filtern. Die Anfangs- oder Endframes werden wahrscheinlich nicht angezeigt, wenn die Netzwerkaufnahme weniger als eine halbe Stunde beträgt. Wenn viele Verbindungen vom SYN-Paket bis zum ACK+FIN-Paket kürzer als 30 Frames sind, weist dieser Zustand auf nicht gepoolte Verbindungen hin. Wenn diese nicht gepoolten Verbindungen mit einigen länger andauernden Verbindungen vermischt sind, liegt der Verdacht nahe, dass nicht gepoolte Hintergrundverbindungen dadurch verursacht werden, dass Befehle auf einer Nicht-MARS-Verbindung ausgeführt werden, während eine Ergebnismenge gelesen wird.

Der kurzlebige Portbericht zeigt die Anzahl der neuen Verbindungen über die Lebensdauer der Ablaufverfolgung an. Sie können die Verbindungsrate anhand der Anzahl der Verbindungen pro Sekunde beurteilen.

RESET vs. ACK+RESET

Typischerweise sieht man ACK+RESET, wenn die Anwendung oder Windows eine Verbindung abbricht. Diese Bedingung ist im Allgemeinen auf einen TCP-Fehler auf niedriger Ebene zurückzuführen. Das Paket informiert den anderen Computer, das Senden sofort zu beenden. Wenn sich der Server jedoch in der Mitte der Übertragung befindet, gelangen ein oder zwei Pakete möglicherweise nach dem Senden von ACK+RESET an den Client. Da der Port geschlossen ist, sendet das Betriebssystem ein RESET-Paket. Diese Bedingung tritt auch auf, wenn Pakete nach dem ACK+FIN-Paket eingehen, das nicht Teil des normalen schließende Handshake ist.

Einige Drittanbietertreiber senden auch ein ACK+RESET-Paket, um die Verbindung anstelle eines ACK+FIN zu schließen. Einige Sondenverbindungen können auch diese Aktion ausführen. Wenn dem ACK+RESET-Paket keine Keep-Alive-Pakete, erneut übertragenen Pakete oder Zero-Window-Pakete vorausgehen und es vom Client stammt, obwohl eigentlich ein regulärer Abschluss mit ACK+FIN zu erwarten wäre, könnte dies harmlos sein.

Verwenden von NETSTAT zum Analysieren von Netzwerkproblemen

NETSTAT wird automatisch erfasst, wenn Sie SQLTrace.ps1 für die Datensammlung ausführen.

Alternativ können Sie NETSTAT -abon > c:\ports.txt in der Eingabeaufforderung als Administrator ausführen, um Informationen im Zusammenhang mit Netzwerkproblemen zu sammeln.

Die Datei ports.txt enthält eine Liste aller ein- und ausgehenden Ports, Portnummern, Prozess-IDs und der Namen der Anwendungen, denen die Ports zugeordnet sind. Verwenden Sie diese Liste, um die schlimmsten Täter zu sehen und festzustellen, ob das Portlimit erreicht ist. Aktivieren Sie die Statusleiste in Notepad und deaktivieren Sie den Zeilenumbruch. Die Statusleiste gibt eine Zeilenanzahl an. Sie können durch zwei teilen, um eine ungefähre Portauslastung zu erhalten.

Anpassen von TcpTimedWaitDelay und MaxUserPort

Wenn eine Anwendung die ausgehenden Ports auf dem Hostcomputer auslastet und Sie keine sofortigen Änderungen an der Anwendung vornehmen können, können Sie TcpTimedWaitDelay von 240 auf bis zu 30 Sekunden verringern, sodass ausgehende Ports schneller wiederverwendet werden können.

Sie können auch den dynamischen Clientportbereich auf dem Hostcomputer erweitern, indem Sie den netsh int ipv4 set dynamicport tcp Befehl (oder ipv6) verwenden. Diese Aktion beseitigt nicht die Ineffizienzen nicht gepoolter Verbindungen oder nicht gepoolter Hintergrundverbindungen. Idealerweise sollte die Anwendung so geändert werden, dass Connection Pooling verwendet wird.

Aktuelle unterstützte Versionen von Windows verwenden bereits den IANA-kompatiblen dynamischen Clientportbereich von 49152 bis 65535, der ungefähr 16.384 ephemerale Ports bereitstellt.

Weitere Informationen finden Sie unter "Anpassen der Einstellungen "MaxUserPort" und "TcpTimedWaitDelay".

Fast alle Pakete, die vom Client an den Server oder vom Server an den Client gesendet werden, werden mit einem ACK-Paket beantwortet, das in die entgegengesetzte Richtung gesendet wird. Die TCP.SYS-Ebene generiert den ACK. Wenn ein Paket auf dem Client empfangen wird und die Client-Ablaufverfolgung zeigt, dass es dort eingeht, aber kein ACK an den Server zurückgesendet wird, ist dies ein guter Hinweis darauf, dass das Antivirenprogramm oder ein anderer Netzwerkfiltertreiber das Paket verloren, verworfen oder über längere Zeit zurückgehalten hat (über das Ende der Erfassung der Netzwerkablaufverfolgung hinaus). Ebenso weist es darauf hin, dass das Antivirenprogramm auf dem Server möglicherweise ein Problem hat, wenn die Serverablaufverfolgung zeigt, dass ein Paket von einem Client eingeht, aber kein ACK an den Client zurückgesendet wird.

Wenn Sie jedoch eine große Datenmenge hochladen oder herunterladen, können die ACK-Pakete nach einer Reihe von Datenpaketen kommen, um die Flusssteuerung zu unterstützen.

Es ist sehr schwierig zu beweisen, dass die Antiviren- und Filtertreiber die Täter sind. Sie müssen fast immer einen empirischen Test durchführen. Erstellen Sie eine Ausnahme für die Anwendung oder SQL Server im Antivirenprogramm, und überwachen Sie sie dann 48 Stunden, um festzustellen, ob das Verhalten verbessert wird. Wenn Sie keine Ausnahme festlegen können, deinstallieren Sie das Antivirenprogramm, und starten Sie es neu. Das Deaktivieren hilft in der Regel nicht, da der Antivirenfiltertreiber weiterhin geladen wird. Tun Sie dies nur als letzten Ausweg, wenn Ihr Randschutz eingerichtet ist.

Wenden Sie sich an Ihre Netzwerksicherheitsadministratoren. Wenn sich die Situation verbessert, müssen Sie möglicherweise mit dem Antivirenanbieter zusammenarbeiten, um das Problem zu beheben. Wenn das nicht der Fall ist, könnten andere Netzwerkfiltertreiber die Ursache sein.

Aktivieren der Windows-Firewallüberwachung

Um festzustellen, ob die Firewall Pakete abbricht, aktivieren Sie die Firewallüberwachung in Windows.

Bei SQL Server kann dieses Problem mit dem Client- oder Servercomputer zusammenhängen. Die Netzwerkablaufverfolgung zeigt an, dass der Computer ein Paket empfangen hat, aber nicht reagiert hat. Das Paket kann dann erneut übertragen werden, wieder keine Antwort erhalten, und schließlich wird die Verbindung zurückgesetzt.

Empirische und andere Aktionen

Kurzlebige Ports

Das Aufbrauchen ephemerer Ports ist eine relativ häufige Ursache für sporadische Verbindungszeitüberschreitungen, insbesondere wenn das SYN-Paket im Netzwerkverkehr nicht sichtbar ist.

Für eingehende Anforderungen auf dem Server können Ports wie 80 oder 1433 bis zu 64.000 eingehende Verbindungen pro Client-IP-Adresse verarbeiten und sind in der Regel für alle praktischen Zwecke unbegrenzt.

Bei ausgehenden Verbindungen ist die Anzahl der Ports begrenzt und für alle Serververbindungen freigegeben. Bei aktuellen unterstützten Versionen von Windows beträgt der standardmäßige dynamische Clientportbereich 49152 bis 65535, der ungefähr 16.384 ephemerale Ports bereitstellt.

Normalerweise hält das Betriebssystem Ports für vier Minuten (240 Sekunden) vor dem Recycling bereit und ermöglicht es Anwendungen, sie wiederzuverwenden. Diese Verzögerung verhindert das Portspoofing durch schadhafte Software oder versehentliche Umleitung einer neuen Verbindung zum vorherigen Inhaber dieses Ports. Aufgrund dieser Verzögerung kann eine Clientanwendung, die den standardmäßigen dynamischen Portbereich und die standardmäßige TcpTimedWaitDelay von 240 Sekunden verwendet, nur etwa 68 neue ausgehende Verbindungen pro Sekunde mit SQL Server öffnen, bevor die ungefähr 16.384 ephemeren Ports ausgeschöpft sind. Ein Verringern von TcpTimedWaitDelay oder ein Erweitern des dynamischen Portbereichs mithilfe von netsh int ipv4 set dynamicport tcp hebt diese Obergrenze an.

Für Anwendungen wie IIS verfügt jeder HTTP-Client möglicherweise über einen ausgehenden Port zu SQL Server. Bei einem ausgelasteten Webserver ist das Auslaufen ausgehender Ports eine echte Möglichkeit, wenn die Last hoch ist. Eine Webfarm kann diese Situation mindern.

Anpassen des maximalen Serverspeichers (MB)

Um Probleme im Zusammenhang mit geringem Kernelspeicher zu lösen, passen Sie den maximalen Serverspeicher (MB) an.

Offloading deaktivieren

Zu Testzwecken können Sie einige Auslagerungen über eine Administrator-Eingabeaufforderung deaktivieren:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled

Halten Sie diese Einstellungen nicht lange deaktiviert, es sei denn, sie lindern ein Problem. Sie sind standardmäßig für aktuelle unterstützte Versionen von Windows aktiviert.

Für andere Auslagerungen müssen Sie zu den Netzwerkadaptereigenschaften wechseln, um sie anzuzeigen und zu deaktivieren.

VMware-Netzwerkpufferprobleme

Der ESX-Host, der den virtuellen Computer (VM) enthält, verfügt über einen kleinen Netzwerkpuffer, der Zuverlässigkeitsprobleme verursachen kann, wenn ein Datenfluss auftritt. Im folgenden VMware-Artikel wird beschrieben, wie Sie die Puffergröße erhöhen. Es ist kein Neustart erforderlich. Dieser Vorgang muss auf dem ESX-Hostcomputer ausgeführt werden, nicht auf dem virtuellen Computer.

Großer Paketverlust im Gastbetriebssystem mit VMXNET3 in ESXi

Versuchen Sie außerdem, die virtuellen Computer auf einen anderen ESX-Hostserver zu verschieben oder den Client und den Server auf denselben ESX-Hostserver zu verschieben und festzustellen, ob das Problem nicht mehr besteht. Wenn dies der Fall ist, handelt es sich um ein Basisnetzwerkproblem.

VMware-Momentaufnahmen

Überprüfen Sie, ob VMware-Momentaufnahmen während des Fehlers auftreten, und deaktivieren Sie sie.

Receive Side Scaling (RSS) auf dem Hostcomputer deaktiviert

Wenn RSS deaktiviert ist, verwendet der SQL Server-Host nur eine einzelne CPU, um alle Netzwerkanforderungen zu verarbeiten. Dies könnte die CPU-Auslastung auf 100 % treiben und Probleme verursachen, selbst wenn die Auslastung der anderen CPUs (und die Gesamtauslastung der CPU) niedrig ist.

Weitere Informationen finden Sie in der Einführung in den Empfang von Side Scaling und Receive Side Scaling Version 2 (RSSv2).

Verwandte Inhalte

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

  • Last updated on