Wie gehen Sie mit Transport-Level-Fehlern in SqlConnection um?

Question

Hin und wieder in einer hohen .NET-Anwendung Volumen, können Sie diese Ausnahme sehen, wenn Sie versuchen, eine Abfrage auszuführen:

System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server.

Nach meinen Recherchen ist dies etwas, das nicht viel „passiert einfach“ kann getan werden, um es zu verhindern. Es tritt nicht als Ergebnis einer fehlerhaften Abfrage auf und kann im Allgemeinen nicht dupliziert werden. Es kommt nur vielleicht alle paar Tage in einem ausgelasteten OLTP-System vor, wenn die TCP-Verbindung zur Datenbank aus irgendeinem Grund schlecht wird.

Ich bin gezwungen, diesen Fehler zu erkennen, indem Sie die Ausnahmebedingungsnachricht analysieren und dann die gesamte Operation von Grund auf neu versuchen, um eine neue Verbindung einzuschließen. Nichts davon ist hübsch.

Hat jemand alternative Lösungen?

Answer 1

Sie sollten auch die Hardwareverbindung zur Datenbank prüfen.

Vielleicht wird dieses Thema hilfreich sein: http://channel9.msdn.com/forums/TechOff/234271-Conenction-forcibly-closed-SQL-2005/

Answer 2

Ich Zuverlässigkeit Schicht um meine DB-Befehle (wegabstrahiert im Repository interfaece) verwenden. Im Grunde ist das nur Code, der jede erwartete Ausnahme abfängt (DbException und InvalidOperationException, die Konnektivitätsprobleme verursacht), protokolliert sie, erfasst Statistiken und versucht alles erneut.

Mit dieser Zuverlässigkeitsschicht war der Service in der Lage, einen Stresstest zu bestehen (konstante Deadlocks, Netzwerkausfälle usw.). Die Produktion ist viel weniger feindselig.

PS: There is more on that here (zusammen mit einer einfachen Art und Weise Zuverlässigkeit mit dem Abfangen DSL zu definieren)

Answer 3

Ihre ursprüngliche Frage zu beantworten:

Eine elegantere Möglichkeit, diesen speziellen Fehler zu erfassen, ohne die Fehlermeldung Parsen , ist die Number Eigenschaft der SqlException zu überprüfen.

(Dies gibt tatsächlich die Fehlernummer aus dem ersten SqlError in der Errors Sammlung, aber in Ihrem Fall die Transportfehler sollte der einzige in der Sammlung.)

Answer 4

ich hatte das gleiche Problem. Ich fragte meine Netzwerk-Geek-Freunde, und alle sagten, was die Leute hier geantwortet haben: Es ist die Verbindung zwischen dem Computer und dem Datenbankserver. In meinem Fall war es mein Internet Service Provider, oder dort Router, war das Problem. Nach einem Router-Update ging das Problem weg. Aber haben Sie andere Aussetzer der Internetverbindung von Ihrem Computer oder Server? Ich hatte ...

Answer 5

Ich postete an answer on another question auf ein anderes Thema, das hier vielleicht etwas verwenden könnte. Diese Antwort beinhaltete SMB-Verbindungen, nicht SQL. Es war jedoch insofern identisch, als es einen Transportfehler auf niedrigem Niveau beinhaltete.

Was wir festgestellt, dass in einer schweren Belastung, es ziemlich einfach war für die Remote-Server-Verbindungen einfach auf der TCP-Schicht Zeit, weil der Server ausgelastet war. Ein Teil des Grundes war die Vorgabe, wie oft TCP Daten unter Windows erneut übertragen würde, die für unsere Situation nicht geeignet waren.

Werfen Sie einen Blick auf die registry settings for tuning TCP/IP unter Windows.Insbesondere möchten Sie TcpMaxDataRetransmissions und vielleicht TcpMaxConnectRetransmissions betrachten. Diese sind standardmäßig auf 5 und 2 eingestellt, versuchen Sie, sie ein wenig auf dem Client-System zu erhöhen und die Lastsituation zu duplizieren.

Nicht verrückt werden! TCP verdoppelt das Timeout bei jeder erneuten Übertragung, so dass das Timeout-Verhalten für schlechte Verbindungen exponentiell werden kann, wenn Sie diese zu sehr erhöhen. Wie ich mich erinnern kann TcpMaxDataRetransmissions zu 6 oder 7 löste unser Problem in der überwiegenden Mehrheit der Fälle.

Answer 6

Ich habe gesehen, dass dies in meiner eigenen Umgebung eine Anzahl von Zeiten passiert. Die Client-Anwendung ist in diesem Fall auf vielen Rechnern installiert. Einige dieser Maschinen sind Laptops. Die Leute haben die Anwendung geöffnet, die Verbindung getrennt und dann wieder eingesteckt und versucht, sie zu benutzen. Dies wird dann den von Ihnen erwähnten Fehler verursachen.

Mein erster Punkt wäre, das Netzwerk zu betrachten und sicherzustellen, dass Server nicht auf DHCP sind und IP-Adressen erneuern, die diesen Fehler verursachen. Wenn das nicht der Fall ist, müssen Sie Ihre Ereignisprotokolle durchsuchen, um nach anderen Netzwerkproblemen zu suchen.

Leider ist es wie oben erwähnt ein Netzwerkfehler. Das Wichtigste, was Sie tun können, ist nur die Verbindungen mit einem Werkzeug wie Netmon zu überwachen und von dort aus zu arbeiten.

Viel Glück.

Answer 7

Diese blog post von Michael Aspengren erklärt die Fehlermeldung "Ein Transport-Level-Fehler ist beim Senden der Anfrage an den Server aufgetreten."

Answer 8

Ich hatte das gleiche Problem, obwohl es mit Serviceanforderungen an eine SQL DB war.

ist, was ich in meinem Dienst Fehlerprotokoll hatte:

---

System.Data.SqlClient.SqlException: Ein Übertragungsfehler aufgetreten ist, wenn die Anfrage an den Server sendet. (Anbieter: TCP-Anbieter, Fehler:. 0 - eine vorhandene Verbindung wurde von dem Remotehost geschlossen wurde)

---

Ich habe eine C# Test-Suite, die einen Dienst prüft. Der Dienst und die DB waren beide auf externen Servern, also dachte ich, das könnte das Problem sein. Daher habe ich den Dienst und die Datenbank lokal ohne Erfolg eingesetzt. Das Problem ging weiter. Die Testsuite ist überhaupt nicht wirklich ein Leistungstest, also hatte ich keine Ahnung, was passiert ist. Derselbe Test versagte jedes Mal, aber wenn ich diesen Test deaktivierte, würde ein anderer kontinuierlich fehlschlagen.

Ich habe versucht, andere Methoden im Internet vorgeschlagen, das auch nicht funktioniert:

• Erhöhen Sie die Registrierungswerte von TcpMaxDataRetransmissions und TcpMaxConnectRetransmissions.
• Deaktivieren Sie die Option "Shared Memory" im SQL Server-Konfigurations-Manager unter "Client-Protokolle" und sortieren Sie TCP/IP auf 1. in der Liste.
• Dies kann auftreten, wenn Sie die Skalierbarkeit mit einer großen Anzahl von Clientverbindungsversuchen testen. Verwenden Sie das Regedit.exe-Dienstprogramm, um dieses Problem zu beheben, um dem Registrierungsschlüssel HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters \ mit Wertdaten von 00000000 einen neuen DWORD-Wert mit Name SynAttackProtect hinzuzufügen.

Mein letzter Ausweg war, das hohe Alter zu benutzen, indem ich sage: "Versuche es noch einmal". Also habe ich try-catch-Anweisungen verschachtelt, um sicherzustellen, dass wenn die TCP/IP-Verbindung im unteren Kommunikationsprotokoll verloren geht, sie dort nicht einfach aufgibt, sondern es erneut versucht. Dies funktioniert jetzt für mich, aber es ist keine sehr elegante Lösung.

Answer 9

Verwendung von Enterprise Services mit Transaktionskomponenten

Answer 10

Soweit ich das beurteilen kann, Klasse 20 Transportebene.

Answer 11

Ich erfuhr den Transportfehler heute Morgen in SSMS während mit SQL 2008 R2 Express verbunden.

Ich habe versucht, eine CSV mit \ r \ n zu importieren. Ich habe meinen Zeilenabschluss für 0x0d0x0a codiert. Als ich es zu 0x0a änderte, wurde der Fehler beendet. Ich kann es hin und her ändern und beobachten, wie es passiert/nicht passiert.

BULK INSERT #t1 FROM 'C:\123\Import123.csv' WITH 
     (FIRSTROW = 1, FIELDTERMINATOR = ',', ROWTERMINATOR = '0x0d0x0a') 

Ich vermute, ich meine Zeile schreibe Terminator korrekt, da SQL ein Zeichen in einer Zeit analysiert rechts, während ich versuche, zwei Zeichen zu bestehen.

Wie auch immer, dieser Fehler ist jetzt 4 Jahre alt, aber es kann ein wenig Information für den nächsten Benutzer liefern.

Answer 12

Ich wollte hier nur einen Fix veröffentlichen, der für unsere Firma auf neuer Software funktioniert, die wir installiert haben. Wir erhielten den folgenden Fehler seit Tag 1 in der Clientprotokolldatei: Der Server konnte die Anforderung nicht verarbeiten. ---> Beim Empfang von Ergebnissen vom Server ist ein Transport-Level-Fehler aufgetreten. (Anbieter: TCP-Provider, Fehler: 0 - Die Semaphor-Timeout-Zeit ist abgelaufen.) ---> Die Semaphor-Timeout-Zeit ist abgelaufen.

Das Problem wurde vollständig behoben, indem ein Link-Aggregat (LAG) auf unserem Switch eingerichtet wurde. Unser Dell FX1-Server verfügt über redundante Glasfaserleitungen, die aus der Rückseite kommen. Wir haben nicht erkannt, dass der Switch, an den sie angeschlossen sind, eine LAG für diese beiden Ports konfiguriert haben muss. Details siehe hier: