Beim Empfang der Ergebnisse vom Server ist ein Fehler auf Transportebene aufgetreten. [Geschlossen]

Ich erhalte einen SQL Server-Fehler:

Beim Empfang der Ergebnisse vom Server ist ein Fehler auf Transportebene aufgetreten. (Anbieter: Shared Memory Provider, Fehler: 0 - Das Handle ist ungültig.)

Ich verwende SQL Server 2008 SP1, Windows 2008 Standard 64 Bit.

Es ist eine .NET 4.0-Webanwendung. Dies geschieht, wenn eine Anforderung an den Server gesendet wird. Es ist zeitweise. Irgendeine Idee, wie ich es lösen kann?

Die Datenbankverbindung wird vom Datenbankserver geschlossen. Die Verbindung bleibt im Verbindungspool Ihrer App gültig. Wenn Sie die gemeinsam genutzte Verbindungszeichenfolge abrufen und versuchen, sie auszuführen, kann sie daher die Datenbank nicht erreichen. Wenn Sie Visual Studio entwickeln, schließen Sie einfach den temporären Webserver in Ihrer Taskleiste.

Wenn dies in der Produktion geschieht, sollte das Zurücksetzen Ihres Anwendungspools für Ihre Website den Verbindungspool wiederverwenden.

Versuchen Sie den folgenden Befehl an der Eingabeaufforderung:

netsh interface tcp set global autotuning=disabled

Dadurch werden die automatischen Skalierungsfunktionen des Netzwerkstapels deaktiviert

Ich hatte das gleiche Problem. Ich habe Visual Studio neu gestartet und das Problem wurde behoben

Für diejenigen, die IIS nicht verwenden, hatte ich dieses Problem beim Debuggen mit Visual Studio 2010. Ich habe alle Debugger-Prozesse beendet: WebDev.WebServer40.EXE, wodurch das Problem behoben wurde.

Fehler auf Transportebene hängen häufig damit zusammen, dass die Verbindung zum SQL Server unterbrochen wird ... normalerweise im Netzwerk.

Timeout Expired wird normalerweise ausgelöst, wenn die Ausführung einer SQL-Abfrage zu lange dauert.

So wenige Optionen können sein:

1. Überprüfen Sie die Verbindung in VPN (falls verwendet) oder einem anderen Tool
2. Starten Sie IIS neu
3. Starten Sie die Maschine neu
4. Optimieren Sie SQL-Abfragen.

Sie müssen lediglich den ASP.NET-Entwicklungsserver stoppen und das Projekt erneut ausführen

Wenn Sie über Microsoft SQL Server Management mit Ihrer Datenbank verbunden sind, schließen Sie alle Verbindungen und versuchen Sie es erneut. Hatte diesen Fehler beim Verbinden mit einer anderen Azure-Datenbank und funktionierte beim Schließen für mich. Ich weiß immer noch nicht warum ..

Erhielt dies immer nach ca. 5 Minuten Betrieb. Untersucht und festgestellt, dass eine Warnung von e1iexpress immer vor dem Fehler aufgetreten ist. Dies ist anscheinend ein Fehler, der mit bestimmten TCP / IP-Adaptern zu tun hat. Der Wechsel von WiFi zu fest verdrahtet hatte jedoch keinen Einfluss darauf.

Also habe ich Plan B ausprobiert und Visual Studio neu gestartet. Dann hat es gut funktioniert.

Bei näherer Betrachtung stellte ich fest, dass die Meldung The Thread '<No Name>' has exited with code 0bei korrekter Arbeit fast genau zu dem Zeitpunkt auftrat, als der Lauf bei früheren Versuchen abstürzte. Einige Googler zeigen, dass diese Meldung angezeigt wird, wenn (unter anderem) der Server den Thread-Pool verkleinert.

Vermutlich befand sich ein gefälschter Thread im Thread-Pool, und jedes Mal, wenn der Server versuchte, ihn zu "trimmen", wurde die App heruntergefahren.

Schauen Sie sich den MSDN-Blog an, in dem dieser Fehler beschrieben wird:

Verbindungen entfernen

Der Verbindungspooler entfernt eine Verbindung aus dem Pool, nachdem er längere Zeit inaktiv war oder wenn der Pooler feststellt, dass die Verbindung zum Server getrennt wurde.

Beachten Sie, dass eine unterbrochene Verbindung erst erkannt werden kann, nachdem versucht wurde, mit dem Server zu kommunizieren. Wenn eine Verbindung gefunden wird, die nicht mehr mit dem Server verbunden ist, wird sie als ungültig markiert.

Ungültige Verbindungen werden nur dann aus dem Verbindungspool entfernt, wenn sie geschlossen oder zurückgefordert werden.

Wenn eine Verbindung zu einem verschwundenen Server besteht, kann diese Verbindung aus dem Pool gezogen werden, auch wenn der Verbindungspooler die getrennte Verbindung nicht erkannt und als ungültig markiert hat.

Dies ist der Fall, weil der Aufwand für die Überprüfung, ob die Verbindung noch gültig ist, die Vorteile eines Poolers eliminieren würde, da ein weiterer Roundtrip zum Server stattfinden würde.

In diesem Fall erkennt der erste Versuch, die Verbindung zu verwenden, dass die Verbindung getrennt wurde, und es wird eine Ausnahme ausgelöst.

Grundsätzlich sehen Sie diese Ausnahme im letzten Satz.

Eine Verbindung wird aus dem Verbindungspool entnommen. Die Anwendung weiß nicht, dass die physische Verbindung unterbrochen wurde. Der Versuch, sie zu verwenden, wird unter der Annahme durchgeführt, dass die physische Verbindung noch vorhanden ist.

Und du bekommst deine Ausnahme.

Dafür gibt es einige häufige Gründe.

1. Der Server wurde neu gestartet, wodurch die vorhandenen Verbindungen geschlossen werden.

In diesem Fall sehen Sie sich das SQL Server-Protokoll an, das normalerweise unter C: \ Programme \ Microsoft SQL Server \\ MSSQL \ LOG zu finden ist

Wenn der Zeitstempel für den Start sehr aktuell ist, können wir vermuten, dass dies den Fehler verursacht hat. Versuchen Sie, diesen Zeitstempel mit dem Zeitpunkt der Ausnahme zu korrelieren.

2009-04-16 11: 32: 15.62 Server Protokollierung von SQL Server-Nachrichten in der Datei 'C: \ Programme \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ LOG \ ERRORLOG'.

2. Jemand oder etwas hat die verwendete SPID getötet.

Schauen Sie sich noch einmal das SQL Server-Protokoll an. Wenn Sie einen Kill finden, versuchen Sie, diesen Zeitstempel mit dem Zeitpunkt der Ausnahme zu korrelieren.

2009-04-16 11: 34: 09.57 spidXX Die Prozess-ID XX wurde durch den Hostnamen xxxxx und die Host-Prozess-ID XXXX beendet.

3. Es gibt erneut ein Failover (z. B. in einem Spiegel-Setup). Sehen Sie sich das SQL Server-Protokoll an.

Wenn ein Failover vorliegt, versuchen Sie, diesen Zeitstempel mit dem Zeitpunkt der Ausnahme zu korrelieren.

2009-04-16 11: 35: 12.93 spidXX Die gespiegelte Datenbank "" ändert aufgrund eines Failovers die Rollen von "PRINCIPAL" in "MIRROR".

Sie erhalten diese Meldung, wenn Ihr Skript den SQL-Dienst aus bestimmten Gründen beendet. Wenn Sie den SQL-Dienst erneut starten, ist Ihr Problem möglicherweise behoben.

Ich weiß, dass dies möglicherweise nicht jedem hilft (wer weiß, vielleicht ja), aber ich hatte das gleiche Problem und nach einiger Zeit stellten wir fest, dass die Ursache etwas außerhalb des Codes selbst war.

Der Computer, der versucht, den Server zu erreichen, befand sich in einem anderen Netzwerk. Die Verbindung konnte hergestellt, aber dann getrennt werden.

Die Art und Weise, wie wir das Problem behoben haben, bestand darin, dem Computer eine statische Route hinzuzufügen, die den direkten Zugriff auf den Server ermöglicht, ohne die Firewall zu passieren.

route add –p YourServerNetwork mask NetworkMask Router 

Stichprobe:

route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2 

Ich hoffe, es hilft jemandem, es ist besser, dies zu haben, zumindest als Hinweis. Wenn Sie sich dem stellen, wissen Sie, wie Sie es lösen können.

Ich habe den gleichen Fehler in der Visual Studion 2012-Entwicklungsumgebung erhalten, IIS Express gestoppt und die Anwendung erneut ausgeführt. Sie hat funktioniert.

In meinem Fall wurde der Serverdienst "SQL Server" gestoppt. Beim Neustart des Dienstes konnte ich die Abfrage ausführen und den Fehler beseitigen.

Es ist auch eine gute Idee, Ihre Abfrage zu untersuchen, um herauszufinden, warum die Abfrage diesen Dienst beendet hat

Ich hatte das gleiche Problem. Ich habe es gelöst und das SQL Server-LOG abgeschnitten. Überprüfen Sie dies und teilen Sie uns mit, ob diese Lösung Ihnen geholfen hat.

Für mich ist die Antwort, das Betriebssystem von 2008R2 auf 2012R2 zu aktualisieren. Die Lösung von iisreset oder restart apppool hat bei mir nicht funktioniert. Ich habe auch versucht, die Einstellung TCP Chimney Offload zu deaktivieren, aber ich habe den Server nicht neu gestartet, da es sich um einen Produktionsserver handelt, der auch nicht funktioniert hat.

Für mich war die Lösung völlig anders.

In meinem Fall hatte ich eine Objektquelle, für die ein Datenzeitstempelparameter erforderlich war. Obwohl dieser ODS-Parameter ConvertEmptyStringToNull wahr war, wurde 1/1/0001 an SelectMethod übergeben. Dies wiederum verursachte eine SQL-Datetime-Überlaufausnahme, als diese Datetime an den SQL-Server übergeben wurde.

Ein zusätzlicher Check für datetime.year! = 0001 wurde hinzugefügt und das hat es für mich gelöst.

Seltsam, dass es einen Transport-Level-Fehler und keinen Datetime-Überlauffehler auslösen würde. Sowieso..

Dieser Fehler ist kürzlich zwischen unserem Business-Server und unserem Datenbankserver aufgetreten. Die Lösung für uns bestand darin, "IP Offloading" auf den Netzwerkschnittstellen zu deaktivieren. Dann ging der Fehler weg.

Einer der Gründe, warum ich diesen Fehler gefunden habe, ist ' Packet Size = xxxxx ' in der Verbindungszeichenfolge. Wenn der Wert von xxxx zu groß ist, wird dieser Fehler angezeigt. Entfernen Sie diesen Wert und lassen Sie ihn von SQL Server verarbeiten oder halten Sie ihn niedrig, abhängig von den Netzwerkfunktionen.

Es ist mir passiert, als ich versucht habe, eine SQL-Datenbank wiederherzustellen, und das folgende Kontrollkästchen auf der OptionsRegisterkarte aktiviert hat:

Da es sich um einen eigenständigen Datenbankserver handelt, wurde das Problem für mich gelöst, indem SSMS nur geschlossen und erneut geöffnet wurde.

Dies tritt auf, wenn die Datenbank gelöscht und neu erstellt wird. Einige gemeinsam genutzte Ressourcen berücksichtigen immer noch, dass die Datenbank noch vorhanden ist. Wenn Sie also die Ausführungsabfrage erneut ausführen, um Tabellen in der Datenbank zu erstellen, nachdem sie neu erstellt wurde, wird der Fehler nicht erneut Command(s) completed successfully.angezeigt und es wird eine Meldung angezeigt wird anstelle der Fehlermeldung angezeigt Msg 233, Level 20, State 0, Line 0 A transport-level error has occurred when sending the request to the server. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.).

Ignorieren Sie diesen Fehler einfach, wenn Sie Datenbanken löschen und neu erstellen und Ihre DDL-Abfragen ohne Sorgen erneut ausführen.

Ich hatte kürzlich das gleiche Problem, konnte aber in Google keine Antwort erhalten. Denken Sie also daran, es hier zu teilen, damit es in Zukunft jemandem helfen kann.

Error:

Während der Ausführung der Abfrage liefert die Abfrage nur wenige Ausgaben, dann wird der folgende Fehler ausgegeben.

"Beim Empfang der Ausgabe vom Server ist ein Fehler auf Transportebene aufgetreten (TCP: Anbieter, Fehler: 0 - Der angegebene Netzwerkname ist nicht mehr verfügbar."

Lösung:

1. Überprüfen Sie den Anbieter dieses Verbindungsservers
2. Aktivieren Sie in diesen Anbietereigenschaften die Option "Inprozess zulassen" für diesen bestimmten Anbieter, um das Problem zu beheben.