Wystąpił błąd na poziomie transportu podczas odbierania wyników z serwera [zamknięte]

Otrzymuję błąd programu SQL Server:

Podczas odbierania wyników z serwera wystąpił błąd na poziomie transportu. (dostawca: dostawca pamięci współużytkowanej, błąd: 0 - dojście jest nieprawidłowe).

Używam Sql Server 2008 SP1, Windows 2008 Standard 64 bit.

Jest to aplikacja internetowa .Net 4.0. Dzieje się tak, gdy wysyłane jest żądanie do serwera. To jest przerywane. Masz jakiś pomysł, jak mogę to rozwiązać?

Połączenie z bazą danych jest zamykane przez serwer bazy danych. Połączenie pozostaje ważne w puli połączeń Twojej aplikacji; w rezultacie, po odebraniu udostępnionych parametrów połączenia i próbie wykonania, nie można uzyskać dostępu do bazy danych. Jeśli tworzysz program Visual Studio, po prostu zamknij tymczasowy serwer sieci Web na pasku zadań.

Jeśli dzieje się to w środowisku produkcyjnym, zresetowanie puli aplikacji dla witryny sieci Web powinno spowodować ponowne uruchomienie puli połączeń.

Wypróbuj następujące polecenie w wierszu polecenia:

netsh interface tcp set global autotuning=disabled

Spowoduje to wyłączenie możliwości automatycznego skalowania stosu sieciowego

Miałem ten sam problem. Zrestartowałem Visual Studio i to rozwiązało problem

Dla tych, którzy nie używają IIS, miałem ten problem podczas debugowania w Visual Studio 2010. Zakończyłem wszystkie procesy debuggera: WebDev.WebServer40.EXE, który rozwiązał problem.

Błędy na poziomie transportu są często związane z zerwaniem połączenia z serwerem sql ... zwykle z siecią.

Timeout Expired jest zwykle generowany, gdy wykonanie zapytania sql trwa zbyt długo.

Tak więc kilka opcji może być:

1. Sprawdź połączenie w VPN (jeśli jest używane) lub innym narzędziu
2. Uruchom ponownie usługi IIS
3. Uruchom ponownie komputer
4. Zoptymalizuj zapytania SQL.

Wszystko, czego potrzebujesz, to zatrzymać serwer deweloperski ASP.NET i ponownie uruchomić projekt

Jeśli masz połączenie z bazą danych za pośrednictwem programu Microsoft SQL Server Management, zamknij wszystkie połączenia i spróbuj ponownie. Wystąpił ten błąd podczas połączenia z inną bazą danych Azure i działał u mnie po zamknięciu. Nadal nie wiem dlaczego ...

Dostawałem to, zawsze po około 5 minutach operacji. Zbadano i stwierdzono, że ostrzeżenie z e1iexpress zawsze pojawiało się przed awarią. Najwyraźniej jest to błąd związany z niektórymi adapterami TCP / IP. Ale zmiana z Wi-Fi na przewodowe nie wpłynęła na to.

Wypróbowałem więc Plan B i ponownie uruchomiłem Visual Studio. Wtedy zadziałało dobrze.

Przy bliższej analizie zauważyłem, że przy prawidłowym działaniu komunikat The Thread '<No Name>' has exited with code 0pojawił się prawie dokładnie w momencie, w którym przebieg zawiesił się we wcześniejszych próbach. Niektóre Googling ujawniają, że ta wiadomość pojawia się, gdy (między innymi) serwer przycina pulę wątków.

Prawdopodobnie w puli wątków znajdował się fałszywy wątek i za każdym razem, gdy serwer próbował „przyciąć”, powodował wyłączenie aplikacji.

Spójrz na blog MSDN, który szczegółowo opisuje ten błąd:

Usuwanie połączeń

Program puli połączeń usuwa połączenie z puli po długim okresie bezczynności lub po wykryciu przez niego, że połączenie z serwerem zostało zerwane.

Należy pamiętać, że zerwane połączenie można wykryć dopiero po próbie nawiązania komunikacji z serwerem. Jeśli zostanie znalezione połączenie, które nie jest już połączone z serwerem, jest oznaczane jako nieprawidłowe.

Nieprawidłowe połączenia są usuwane z puli połączeń tylko wtedy, gdy są zamknięte lub odzyskane.

Jeśli istnieje połączenie z serwerem, który zniknął, można je pobrać z puli, nawet jeśli pula połączeń nie wykryła zerwanego połączenia i oznaczyła je jako nieprawidłowe.

Dzieje się tak, ponieważ obciążenie związane ze sprawdzaniem, czy połączenie jest nadal prawidłowe, wyeliminowałoby korzyści wynikające z posiadania poolera, powodując kolejną podróż w obie strony do serwera.

W takim przypadku pierwsza próba użycia połączenia wykryje, że połączenie zostało zerwane, i zostanie zgłoszony wyjątek.

Zasadniczo to, co widzisz, to wyjątek w ostatnim zdaniu.

Połączenie jest pobierane z puli połączeń, aplikacja nie wie, że połączenie fizyczne zniknęło, próba jego użycia odbywa się przy założeniu, że połączenie fizyczne nadal istnieje.

I masz wyjątek.

Istnieje kilka typowych przyczyn takiego stanu rzeczy.

1. Serwer został zrestartowany, spowoduje to zamknięcie istniejących połączeń.

W takim przypadku spójrz na dziennik SQL Server, zwykle znajdujący się w: C: \ Program Files \ Microsoft SQL Server \\ MSSQL \ LOG

Jeśli sygnatura czasowa uruchomienia jest bardzo aktualna, możemy podejrzewać, że to właśnie spowodowało błąd. Spróbuj skorelować ten znacznik czasu z czasem wyjątku.

2009-04-16 11: 32: 15.62 Server Logowanie komunikatów SQL Server w pliku „C: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ LOG \ ERRORLOG”.

2. Ktoś lub coś zabiło używany identyfikator SPID.

Ponownie spójrz na dziennik programu SQL Server. Jeśli znajdziesz zabójstwo, spróbuj skorelować ten znacznik czasu z czasem wyjątku.

2009-04-16 11: 34: 09.57 spidXX Identyfikator procesu XX został zabity przez nazwę hosta xxxxx, identyfikator procesu hosta XXXX.

3. Ponownie występuje przełączanie awaryjne (na przykład w konfiguracji lustrzanej), spójrz na dziennik SQL Server.

Jeśli występuje przełączanie awaryjne, spróbuj skorelować ten znacznik czasu z czasem wyjątku.

2009-04-16 11: 35: 12.93 spidXX W lustrzanej bazie danych „” zmienia się role z „PRINCIPAL” na „MIRROR” z powodu pracy awaryjnej.

Ten komunikat pojawia się, gdy skrypt powoduje zatrzymanie usługi SQL z jakiegoś powodu. więc jeśli ponownie uruchomisz usługę SQL, być może problem zostanie rozwiązany.

Wiem, że może to nie pomóc każdemu (kto wie, może tak), ale miałem ten sam problem i po jakimś czasie zdaliśmy sobie sprawę, że przyczyną jest coś z samego kodu.

Komputer próbujący połączyć się z serwerem znajdował się w innej sieci, połączenie mogło zostać nawiązane, ale zostało przerwane.

Sposób, w jaki to naprawialiśmy, polegał na dodaniu statycznej trasy do komputera, umożliwiającej bezpośredni dostęp do serwera bez przechodzenia przez zaporę.

route add –p YourServerNetwork mask NetworkMask Router 

Próba:

route add –p 172.16.12.0 mask 255.255.255.0 192.168.11.2 

Mam nadzieję, że to komuś pomoże, lepiej mieć to, przynajmniej jako wskazówkę, więc jeśli się z tym zmierzysz, wiesz, jak to rozwiązać.

Otrzymałem ten sam błąd w środowisku programistycznym Visual Studion 2012, zatrzymałem IIS Express i ponownie uruchomiłem aplikację, zaczęła działać.

W moim przypadku usługa serwera „SQL Server” została zatrzymana. Po ponownym uruchomieniu usługi, która umożliwiła mi uruchomienie zapytania i wyeliminowanie błędu.

Dobrym pomysłem jest również zbadanie zapytania, aby dowiedzieć się, dlaczego zapytanie spowodowało zatrzymanie tej usługi

Miałem ten sam problem. Rozwiązałem to, skracając dziennik SQL Server. Sprawdź to, a następnie powiedz nam, czy to rozwiązanie Ci pomogło.

Dla mnie odpowiedzią jest aktualizacja systemu operacyjnego z 2008R2 do 2012R2, rozwiązanie iisreset lub restart apppool nie działało dla mnie. Próbowałem również wyłączyć ustawienie TCP Chimney Offload, ale nie zrestartowałem serwera, ponieważ jest to serwer produkcyjny, który również nie działał.

Dla mnie rozwiązanie było zupełnie inne.

W moim przypadku miałem objectource, który wymagał parametru datetimestamp. Mimo że ten parametr ODS ConvertEmptyStringToNull miał wartość true 1/1/0001 był przekazywany do SelectMethod. To z kolei spowodowało wyjątek przepełnienia daty i godziny sql, gdy ta data i godzina została przekazana do serwera sql.

Dodano dodatkowe sprawdzenie datetime.year! = 0001 i to rozwiązało problem.

Dziwne, że spowodowałoby to błąd poziomu transportu, a nie błąd przepełnienia daty i godziny. Tak czy inaczej…

Niedawno napotkaliśmy ten błąd między naszym serwerem biznesowym a naszym serwerem bazy danych. Rozwiązaniem dla nas było wyłączenie „IP Offloading” na interfejsach sieciowych. Wtedy błąd zniknął.

Jednym z powodów tego błędu jest „ Rozmiar pakietu = xxxxx ” w parametrach połączenia. jeśli wartość xxxx jest zbyt duża, zobaczymy ten błąd. Usuń tę wartość i pozwól serwerowi SQL obsłużyć ją lub utrzymuj ją na niskim poziomie, w zależności od możliwości sieci.

Zdarzyło mi się to, gdy próbowałem przywrócić bazę danych SQL i zaznaczyłem następujące pole wyboru w Optionszakładce,

Ponieważ jest to samodzielny serwer bazy danych, po prostu zamknął program SSMS i ponownie go otworzył, rozwiązał problem.

Dzieje się tak, gdy baza danych zostanie usunięta i ponownie utworzona, niektóre udostępnione zasoby nadal rozważają, że baza danych nadal istnieje, więc po ponownym uruchomieniu zapytania w celu utworzenia tabel w bazie danych po jej ponownym utworzeniu błąd nie pojawi się ponownie i Command(s) completed successfully.komunikat wyświetli się zamiast komunikatu o błędzie 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.).

Po prostu zignoruj ​​ten błąd podczas upuszczania i odtwarzania baz danych i bez obaw ponownie wykonuj zapytania DDL.

Niedawno spotkałem się z tym samym problemem, ale nie udało mi się uzyskać odpowiedzi w Google. Pomyśl więc o udostępnieniu go tutaj, aby mógł komuś pomóc w przyszłości.

Błąd:

Podczas wykonywania zapytania zapytanie dostarczy niewiele danych wyjściowych, a następnie wyświetli poniższy błąd.

„Wystąpił błąd poziomu transportu podczas odbierania danych wyjściowych z serwera (TCP: dostawca, błąd: 0- określona nazwa sieci nie jest już dostępna”)

Rozwiązanie:

1. Sprawdź dostawcę tego połączonego serwera
2. We właściwościach tego dostawcy Włącz opcję „Zezwalaj na inprocess” dla tego konkretnego dostawcy, aby rozwiązać problem.