Freigeben über

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

  • Artikel

Notiz

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

Die Netzwerkstabilität ist für den reibungslosen Betrieb verschiedener Dienste und Anwendungen unerlässlich. Es gibt jedoch Zeiten, in denen Netzwerkprobleme diese Stabilität stören. Dieser Artikel hilft Ihnen, intermittierende oder regelmäßige Netzwerkprobleme und deren typische Fehlermeldungen zu verstehen und zu beheben. Diese Probleme können frustrierend sein, aber Sie können sie effektiver mit einem besseren Verständnis und ordnungsgemäßen Problembehandlungstechniken beheben.

Die häufigsten Fehlermeldungen

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 regelmäßige Netzwerkprobleme auftreten, treten möglicherweise die folgenden Fehlermeldungen auf:

  • Kommunikationsverbindungsfehler: Dieser Fehler zeigt eine Unterbrechung der Kommunikation zwischen Netzwerkkomponenten an.
  • Verbindungstimeout abgelaufen: Die Verbindung mit dem Server timeout, was eine Verzögerung oder Nichtverfügbarkeit des Servers vorschlägt.
  • 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.
  • Timeout des Wartevorgangs: Ein Wartevorgang hat seine 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.
  • Auf den Server wurde nicht zugegriffen oder nicht zugegriffen: Diese Fehlermeldung schlägt vor, 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.

Ursache

Die häufigsten Probleme sind mit Paketabbrüchen aufgrund von Antivirus, Netzwerkoptimierung, älteren Netzwerktreibern, fehlerhaften Routern oder Switches und nicht poolierten Verbindungen in der Anwendung verbunden.

Einige Ursachen, z. B. Antivirus, können schwierig zu beweisen sein, sind aber immer noch üblich. Möglicherweise müssen Sie den Computer deinstallieren und 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 Kommunikationen wie SQL Server Mirroring, Always-On und Service Broker-Synchronisierungsdatenverkehr über Port 5022 werden nicht behoben.

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

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 bestimmen, 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 auszuführen. 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

    Ein Ausgabeordner wird im aktuellen Verzeichnis generiert und kann zur weiteren Analyse verwendet werden.

  • 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 Schnittstelle zum Auswählen von Ablaufverfolgungsdateien für die Analyse und Einstellungsoptionen. Laden Sie es von SQL Network Analyzer (SQLNA) herunter.

Verarbeiten sie Client- und Serverablaufverfolgungen separat. Wenn Sie Ablaufverfolgungen verkettet haben, verarbeiten Sie sie gleichzeitig. 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 eine Art Netzwerkadressenübersetzung oder Portzuordnung durchlaufen, ist es möglicherweise schwieriger, und Sie müssen möglicherweise IPV4-Paket-IDs verwenden und die Nutzlasten vergleichen.

Muster für die Suche in der Netzwerkablaufverfolgungsanalyse

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 Chiffresammlungen deaktivieren. Weitere Informationen finden Sie unter Bei der Verbindung mit SQL-Servern unter Windows treten Fehler beim zwangsweisen Schließen von 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 der abgeglichenen Unterhaltungen an. Wenn ein Paket viele neu übertragene Pakete (oder 10 Keep-Alive-Pakete, 1 Sekunden auseinander) gefolgt von einem ACK+RESET und dem anderen nicht, oder eine meldet eine rechtzeitige Antwort, und die andere sieht sie verzögert und schließt oder setzt die Unterhaltung zurück, was bedeutet, dass ein Problem mit dem Netzwerkgerät und Paketen verworfen oder verzögert wird.

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 schlechten Switch oder Router zurückzuführen, der die Verbindung von der Mitte schließt, und sie können manchmal so konfiguriert werden, wenn sie feststellen, dass die Verbindung eine Weile im Leerlauf war - oft ignoriert Keep-Alive-Pakete.

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 über kurzlebige Ports der SQL-Netzwerkanalyse, und stellen Sie sicher, dass der Client nicht über ausgehende Ports verfügt.

Wenn der Client eine lange Verzögerung vor dem Senden des SYN-Pakets hat, wird möglicherweise ein Muster angezeigt, das nur den TCP-3-Wege-Öffnungs-Handshake anzeigt, unmittelbar gefolgt oder manchmal nach dem Senden des PreLogin-Pakets von einem ACK+FIN vom Client stammt.

Sammeln einer Netzwerkablaufverfolgung und BID-Ablaufverfolgung zum Isolieren von Clientproblemen unter 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 den Anfang der ODBC- oder OLEDB-Liste hinzufügen, indem Sie ihn an der Vorderseite der Linie hinzufügen # und ihn vom Anfang der ODBC- oder OLEDB-Liste entfernen. 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 BID-Ablaufverfolgungsregistrierung, wenn BID-Ablaufverfolgungen erfasst 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

Ein Ausgabeordner wird im aktuellen Verzeichnis generiert und kann zur weiteren Analyse verwendet werden.

Informationen zum Nachverfolgen anderer Microsoft SQL Server-Treiber finden Sie in den folgenden Artikeln. Führen Sie eine 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 und große parallele Abfragen und Blockierung. Dies kann dazu führen, dass threadverhungen, eine Anmeldeanforderung nicht umgehend verarbeitet wird, insbesondere, wenn viele Verbindungstimeouts gleichzeitig enden und in der Spalte "LoginAck" "Late" angezeigt wird. Die SQL Server ERRORLOG-Datei kann E/A-Vorgänge anzeigen, die länger als 15 Sekunden dauern, was ein weiterer Indikator für Leistungsprobleme ist. In der Netzwerkablaufverfolgung werden möglicherweise auch viele Unterhaltungen im Bericht "Zurücksetzen" mit sechs Frames oder weniger angezeigt, was angibt, dass der TCP-Handshake möglicherweise nicht abgeschlossen wurde. Weitere Informationen finden Sie unter Sammeln des Verbindungsringpuffers.

Führen Sie die RingBufferConnectivity Abfrage aus, und fügen Sie die Ergebnisse in Excel ein. Da es sich um eine historische Liste handelt, kann sie nach dem Auftreten des Problems ausgeführt werden. 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 verbindungspooling verwendet wird, 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. Wahrscheinlich werden die Anfangs- oder Endframes nicht angezeigt, wenn die Netzwerkaufnahme weniger als eine halbe Stunde beträgt. Wenn viele Unterhaltungen kürzer als 30 Frames vom SYN-Paket zum ACK+FIN-Paket sind, gibt dies nicht poolierte Verbindungen an. Wenn diese mit einigen längeren Unterhaltungen gemischt werden, vermuten Sie, dass hintergrundfremde Verbindungen, die durch ausführen von Befehlen in einer Nicht-MARS-Verbindung verursacht werden, während sie ein Resultset lesen.

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

ACK+RESET wird in der Regel angezeigt, wenn die Anwendung oder Windows eine Verbindung abbricht. Dies liegt in der Regel an einem TCP-Fehler auf niedriger Ebene. Das Paket informiert den anderen Computer, das Senden sofort zu beenden. Wenn sich der Server jedoch in der Mitte der Übertragung befindet, können ein oder zwei Pakete nach dem Senden von ACK+RESET am Client ankommen. Da der Port geschlossen ist, sendet das Betriebssystem ein RESET-Paket. Dies geschieht auch, wenn Pakete nach dem ACK+FIN-Paket ankommen, 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 Probeverbindungen können dies auch tun. Wenn das ACK+RESET-Paket nicht vor Keep-Alive-Paketen, neu übertragenen Paketen oder Zero Windows-Paketen steht und es vom Client stammt, wenn ein normales Schließen von ACK+FIN erwartet wird, kann es gut sein.

Verwenden von NETSTAT zum Analysieren von Netzwerkproblemen

NETSTAT wird automatisch erfasst, wenn SQLTrace.ps1 für die Datensammlung ausgeführt wird.

Sie können auch in der Eingabeaufforderung als Administrator ausgeführt NETSTAT -abon > c:\ports.txt werden, um Informationen zu Netzwerkproblemen zu sammeln.

Die ports.txt Datei enthält eine Liste aller eingehenden und ausgehenden Ports, Portnummern, Prozess-IDs und Namen von Anwendungen, die die Ports besitzen. Sie können dies verwenden, um die schlimmsten Täter zu sehen und ob das Portlimit erreicht wurde. Aktivieren Sie die Statusleiste im Editor, und deaktivieren Sie den Word-Umbruch. Die Statusleiste gibt eine Zeilenanzahl an. Sie können durch zwei Dividieren dividieren, um eine ungefähre Portnutzung zu erhalten.

Anpassen von TcpTimedWaitDelay und MaxUserPort

Wenn eine Anwendung die ausgehenden Ports auf dem Hostcomputer auslastt und Sie keine sofortigen Änderungen an der Anwendung vornehmen können, können Sie von 240 auf so niedrig wie 30 Sekunden sinken TcpTimedWaitDelay , sodass ausgehende Ports schneller wiederverwendet werden können.

Für Windows 2003 und höher können Sie auch die MaxUserPort. Für Windows Vista und höher legen Sie dies über den NETSH Befehl fest. Dieser Vorgang beseitigt nicht die Ineffizienz von nicht poolierten Verbindungen oder nicht poolierten Hintergrundverbindungen, und der Entwickler sollte dringend ermutigt werden, ihre Anwendungen so zu ändern, dass verbindungspooling verwendet wird.

Für Windows 2008 und höher wurde der Bereich standardmäßig von etwa 4.000 ephemeren Ports auf 16.000 Ports erhöht.

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

Fast alle Pakete, die vom Client an den Server oder den Server an den Client gesendet werden, werden mit einem ACK-Paket in entgegengesetzter Richtung geantwortet. Die TCP.SYS-Ebene generiert den ACK. Wenn ein Paket auf dem Client empfangen wird und die Clientablaufverfolgung anzeigt, dass es eingeht, aber kein ACK an den Server zurückgegeben wird, ist dies ein guter Hinweis darauf, dass das Antivirenprogramm oder ein anderer Netzwerkfiltertreiber das Paket verloren oder abgelegt hat oder lange darauf gespeichert wurde (über das Ende der Netzwerkablaufverfolgungssammlung). Wenn die Serverablaufverfolgung ein Paket anzeigt, das von einem Client stammt, aber kein ACK an den Client gesendet wird, weist dies darauf hin, dass das Server-Antivirenprogramm auf dem Server möglicherweise ein Problem hat.

Wenn Sie jedoch eine große Datenmenge hochladen oder herunterladen, können die ACK-Pakete nach einer Reihe von Datenpaketen zur Unterstützung der Flusssteuerung kommen.

Die Antiviren- und Filtertreiber sind sehr schwer zu beweisen als Täter. Ein empirischer Test ist fast immer erforderlich. 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 eine Ausnahme nicht festgelegt werden kann, deinstallieren Sie das Antivirenprogramm, und starten Sie es neu. Das Deaktivieren hilft in der Regel nicht, da der Antivirenfiltertreiber weiterhin geladen wird. Führen Sie dies nur als letztes Mittel aus, wenn Ihr Edgeschutz vorhanden 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 dies nicht der Dereinst ist, sind möglicherweise andere Netzwerkfiltertreiber der Täter.

Aktivieren der Windows-Firewallüberwachung

Um festzustellen, ob die Firewall Pakete verworfen hat, 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 Ausführen von kurzlebigen Ports ist eine relativ häufige Ursache für intermittierende Verbindungstimeouts, insbesondere, wenn das SYN-Paket nicht auf dem Draht angezeigt wird.

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

Bei ausgehenden Verbindungen ist die Anzahl der Ports dagegen begrenzt und für alle Serververbindungen freigegeben. Für Windows Vista, Windows 2008 und höher liegt der Standardbereich zwischen Port 49152 und 65535 (2^16 = 16.384 Ports).

In der Regel werden Die Ports für vier Minuten (240 Sekunden) vom Betriebssystem gehalten, bevor sie wiederverwendet und von Anwendungen wiederverwendet werden können. Dies ist die Verhinderung von Portspoofing durch Schadsoftware oder versehentliche Umleitung einer neuen Verbindung zum vorherigen Inhaber dieses Ports. Aufgrund dieser Verzögerung kann eine Clientanwendung unter Windows 2003 nur 17 Verbindungen pro Sekunde zu SQL Server herstellen, und der ausgehende Portbereich ist in weniger als vier Minuten erschöpft. Für Windows Vista steigt diese Zahl auf 68 Verbindungen pro Sekunde.

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 beheben, 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 sollten unter Windows 2008 und höher standardmäßig aktiviert sein.

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) disabled on the host machine

Wenn RSS deaktiviert ist, verwendet der SQL Server-Host nur eine einzelne CPU, um alle Netzwerkanforderungen zu verarbeiten. Dies könnte die CPU auf 100 % erhöhen und Probleme verursachen, auch wenn die anderen CPUs (und die allgemeinen CPU-Ebenen) niedrig sind.

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

Weitere Informationen

Zeitweilige oder regelmäßige Authentifizierungsprobleme in SQL Server

Sammeln einer Netzwerkablaufverfolgung

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.