Połączenie z SQL Server czasami działa

101

Aplikacja ADO.Net tylko czasami jest w stanie połączyć się z innym serwerem w sieci lokalnej. Wydaje się losowe, czy dana próba połączenia się powiedzie, czy nie. Połączenie używa ciągu połączenia w postaci:

Server = THESERVER \ TheInstance; Database = TheDatabase; ID użytkownika = TheUser; Hasło = ThePassword;

zwrócony błąd to:

Upłynął limit czasu połączenia. Limit czasu upłynął podczas próby wykorzystania potwierdzenia uzgadniania przed logowaniem.
Może to być spowodowane niepowodzeniem uzgadniania przed logowaniem lub brakiem możliwości odpowiedzi serwera na czas.
Czas spędzony podczas próby połączenia się z tym serwerem wyniósł - inicjalizacja [przed logowaniem] = 42030; handshake = 0;

Aplikacja .NET to mała aplikacja testowa, która wykonuje następujący kod:

using (SqlConnection conn = new SqlConnection(cs))
using (SqlCommand cmd = new SqlCommand("SELECT COUNT(*) FROM TheTable", conn))
{
    conn.Open();
    int rowCount = (int)cmd.ExecuteScalar();
}

Stół jest mały, ma tylko 78 rzędów.

Jednak na tym samym komputerze, na którym aplikacja .NET odbiera ten błąd, mogę połączyć się z serwerem THESERVER za pomocą programu SSMS i identyfikatora użytkownika / hasła podanego w parametrach połączenia.

Dlaczego połączenie może się nie powieść z aplikacji ADO.Net, ale może się powieść z identycznymi poświadczeniami z SSMS?

Eric J.
źródło
1
być może trafiasz na
pardeepk

Odpowiedzi:

93

Okazało się, że protokół TCP / IP był włączony dla adresu IPv4, ale nie dla adresu IPv6 THESERVER.

Najwyraźniej niektóre próby połączenia kończyły się przy użyciu protokołu IPv4, a inne korzystały z protokołu IPv6.

Włączenie protokołu TCP / IP dla obu wersji protokołu IP rozwiązało problem.

Fakt, że SSMS zadziałał, okazał się przypadkowy (kilka pierwszych prób prawdopodobnie wykorzystywało IPv4). Niektóre późniejsze próby nawiązania połączenia za pośrednictwem programu SSMS zakończyły się tym samym komunikatem o błędzie.

Aby włączyć protokół TCP / IP dla dodatkowych adresów IP:

  • Uruchom Menedżera konfiguracji serwera Sql
  • Otwórz węzeł Konfiguracja sieci SQL Server
  • Kliknij lewym przyciskiem myszy Protokoły dla MYSQLINSTANCE
  • W prawym panelu kliknij prawym przyciskiem myszy TCP / IP
  • Kliknij Właściwości
  • Wybierz kartę Adresy IP
  • Dla każdego wymienionego adresu IP upewnij się, że aktywne i włączone są tak.
Eric J.
źródło
Dzięki, to rozwiązało problem. Co ciekawe, wszystkie adresy IP zostały ustawione jako wyłączone (wcześniej nie były). Byłoby dobrze wiedzieć, co może spowodować, że zostaną wyłączone, ponieważ nie sądzę, aby konfiguracja została zmieniona ręcznie w moim przypadku ...
Matt
Nigdy też nie wyłączałem ręcznie moich adresów IPv6. Zastanawiam się też, w jaki sposób zostali niepełnosprawni.
Eric J.,
Z jakiegoś powodu nie mogę włączyć protokołu IPv6. Mówi, że usługa musi zostać ponownie uruchomiona, aby zmiany zaczęły obowiązywać, ale nigdy nie zachowuje jej jako „Tak”. Wszelkie wskazówki, jak to zrobić
Salman
5
Nie jestem pewien, czy wyłączane poszczególne wpisy stanowią problem, ponieważ karta Protokół ma nadpisanie „nasłuchuj wszystkiego”, które nakazuje SQL nasłuchiwać na wszystkich adresach IP. Zobacz poniższy link do dokumentacji. msdn.microsoft.com/en-us/library/dd981060.aspx
ShaneH,
2
Myślę, że widzę tego typu rzeczy na Azure
tofutim
31

Właśnie pojawił się ten sam błąd, który podejrzanie dopasował się do ostatniej rundy aktualizacji firmy Microsoft (02.09.2016). Okazało się, że SSMS połączył się bez problemu, podczas gdy moja aplikacja ASP.NET zwróciła błąd „Upłynął limit czasu podczas próby wykorzystania potwierdzenia uzgadniania przed logowaniem”

Rozwiązaniem dla mnie było dodanie limitu czasu połączenia wynoszącego 30 sekund do parametrów połączenia, np .:

ConnectionString="Data Source=xyz;Initial Catalog=xyz;Integrated Security=True;Connection Timeout=30;"

W mojej sytuacji jedynym dotkniętym połączeniem było to, które korzystało ze zintegrowanych zabezpieczeń i podszywałem się pod użytkownika przed połączeniem, inne połączenia z tym samym serwerem przy użyciu uwierzytelniania SQL działały dobrze!

2 systemy testowe (oddzielni klienci i serwery Sql) zostały dotknięte w tym samym czasie, co doprowadziło mnie do podejrzeń o aktualizację firmy Microsoft!

Shaun Keon
źródło
Miałem ten sam problem, dzięki za rozwiązanie. Łączyłem się za pomocą zintegrowanych zabezpieczeń przez VPN i zwiększenie domyślnego limitu czasu połączenia z domyślnego 15 do 30 sekund rozwiązało problem.
Mark G
1
Miałem ten problem z SQL 2014 LocalDB po tym, jak setup.exe zainstalował nową aplikację i podczas uruchamiania próbowano utworzyć nową bazę danych. Ta poprawka uchroniła mnie przed pluciem manekina - dzięki Shaun!
Scott
1
To rozwiązało również problem dla mnie. W moim przypadku łączyłem się przez VPN i dodawałem wpis w pliku hosts. Problem występował tylko podczas używania nazwy hosta w aplikacjach SSMS i .NET. Podczas korzystania z adresu IP problem nie wystąpił.
Dan
DZIĘKUJEMY ZA ODPOWIEDŹ!
Konrad
17

Rozwiązałem problem jak Eric, ale z kilkoma innymi zmianami:

  • Uruchom Menedżera konfiguracji serwera Sql
  • Otwórz węzeł Konfiguracja sieci SQL Server
  • Kliknij lewym przyciskiem myszy Protokoły dla MYSQLINSTANCE
  • W prawym panelu kliknij prawym przyciskiem myszy TCP / IP
  • Kliknij Właściwości
  • Wybierz kartę Adresy IP
  • Dla każdego wymienionego adresu IP upewnij się, że aktywne i włączone są tak.

I

  • Dla każdego wymienionego adresu IP upewnij się, że porty dynamiczne TCP są puste, a port TCP = 1433 (lub inny port)
  • Otwórz zaporę systemu Windows i sprawdź, czy port jest otwarty w połączeniach przychodzących
Renzo Ciot
źródło
Rozwiązanie nie działa dla mnie. Mam serwer, który zawiera stronę internetową i bazę danych i ten problem nigdy na nim nie występuje, ale znalazłem ten problem, gdy serwer WWW jest oddzielony od serwera bazy danych
Ibrahim Amer
11

Miałem ten sam problem, próbując połączyć się z serwerem w sieci lokalnej (przez VPN) z programu Visual Studio, podczas konfigurowania Entity Data Model.
Udało się rozwiązać tylko przez ustawienie TransparentNetworkIPResolution=falseparametrów połączenia. W Kreatorze dodawania połączenia VS można go znaleźć na karcie Zaawansowane.

maozx
źródło
3
Ustawienie to TransparentNetworkIPResolution = False. Jest to nowa funkcja od .NET 4.6.1 i jest domyślnie włączona. Ustawienie wartości false usunie limit czasu 500 ms, który tworzy ta funkcja. Więcej informacji: blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/ ...
Jorriss
Dziękuję Ci. Godziny badań nad tym problemem. Muszę polubić tę odpowiedź. Komentarz @Jorriss był bardzo pomocny w zrozumieniu, dlaczego. Możesz jednak zaktualizować swoją odpowiedź, aby zawierała prawidłowe słowo kluczowe. Jorriss ma poprawne odniesienie.
TravisWhidden,
5

Miałem ten sam problem z uzgadnianiem podczas łączenia się z serwerem hostowanym.

Otworzyłem moje Centrum sieci i udostępniania i włączyłem IPv6 w moim bezprzewodowym połączeniu sieciowym.

wprowadź opis obrazu tutaj

Pomster
źródło
3

Mój plik wykonywalny, który został zbudowany przy użyciu .NET Framework 3.5, zaczął zgłaszać te problemy z połączeniem w około połowie przypadków po niedawnej instalacji niektórych aktualizacji systemu Windows (tydzień z 7 sierpnia 2017 r.).

Awarie połączenia były spowodowane przez .NET Framework 4.7, który został zainstalowany na komputerze docelowym (włączona była automatyczna instalacja Aktualizacji Windows) - https://support.microsoft.com/?kbid=3186539

Odinstalowanie .NET Framework 4.7 rozwiązało problemy z połączeniem.

Najwyraźniej nastąpiła przełomowa zmiana w .Net Framework 4.6.1 - TransparentNetworkIPResolution Aktualizacja parametrów połączenia zgodnie z artykułem rozwiązała również problem bez konieczności wycofywania wersji frameworka.

user270576
źródło
2

Naprawiłem ten błąd w Windows Server 2012 i SQL Server 2012, włączając IPv6 i odblokowując przychodzący port 1433.

smwikipedia
źródło
1
Myślę, że to nie może być poprawna odpowiedź, ponieważ pytanie zawiera „tylko czasami”. Zablokowany port nie odpowie na pytanie dotyczące tego.
Magier
2

W naszym przypadku wystąpił problem z powodu konfiguracji klastra dostępności. Aby rozwiązać ten problem, musieliśmy ustawić wartość MultiSubnetFailoverTrue w parametrach połączenia.

Więcej szczegółów na temat MSDN

Uriil
źródło
1

Miałem ten sam problem, udało mi się go rozwiązać, otwierając / włączając port 1433 i tcp / ip w SQL Server Configuration Manager, a następnie ponownie uruchomiłem serwer

wprowadź opis obrazu tutaj

Myk Agustin
źródło
1

W moim przypadku ponad wszystkie opcje już tam były.

Rozwiązano to, zwiększając limit czasu połączenia = 30.SQL Server Management Studio

Jignesh
źródło
1

Zanim stracisz więcej czasu na rozwiązywanie problemu, tak jak ja, spróbuj ponownie uruchomić komputer z systemem Windows . U mnie zadziałało po zastosowaniu wszystkich innych rozwiązań.

schody łańcuchowe
źródło
0

Miałem ten problem podczas migracji SharePoint 2010 do 2013. Podejrzewałem, że ponieważ serwer bazy danych znajduje się po drugiej stronie firewalla, który nie kieruje IP6, wówczas próbował użyć IP6 i nie udało mu się połączyć z bazą danych.

Myślę, że problem został już rozwiązany. Wydaje się, że błędy ustały. Po prostu wyłączyłem IP6 (odznaczając go) dla karty sieciowej na serwerach SharePoint.

Chuck Herrington
źródło
0

Miałem ten sam problem, ale łączyłem się ze zdalną bazą danych przy użyciu statycznego adresu IP. Więc żadne z powyższych rozwiązań nie rozwiązało mojego problemu.

Nie udało mi się dodać odpowiedniego mapowania użytkowników dla logowania bezpieczeństwa, którego używałem, więc rozwiązaniem dla mnie było po prostu upewnienie się, że ustawienie mapowania użytkowników jest ustawione na dostęp do mojej bazy danych.

John Livermore
źródło
0

Rozwiązano ten problem poprzez blokowanie / czarną listę adresów IP, które próbowały brutalnie wymusić konta użytkowników. Sprawdź dzienniki dostępu SQL pod kątem dużej liczby nieudanych prób logowania (zwykle w przypadku konta „sa”).

user3424480
źródło
0

U mnie okazuje się, że firewall w serwerze Windows blokował port 1433, który jest domyślnym portem serwera sql. Więc dodanie reguły przychodzącej, która akceptowała te połączenia, zrobiło dla mnie sztuczkę.

Josué Zatarain Espinosa
źródło
0

W moim przypadku Persist Security Info=trueproblem powoduje parametr z użytkownikiem i hasłem w ciągu połączenia. Usunięcie parametru lub ustawienie falserozwiązania problemu.

Ricardo Fontana
źródło
0

Wypróbuj najpierw prosty restart SQL Server, zanim zrobisz coś drastycznego. Może to naprawić. Zrobiło to dla mnie

Robert Benyi
źródło
0

Niestety miałem problem z lokalnym serwerem SQL zainstalowanym w Visual Studio i tutaj wiele rozwiązań mi nie wyszło. Wszystko, co muszę zrobić, to zresetować program Visual Studio, przechodząc do:

Panel sterowania> Programy i funkcje> Program uruchamiający instalatora programu Visual Studio

i kliknij przycisk Więcej i wybierz Napraw

Potem mogłem uzyskać dostęp do mojego lokalnego serwera SQL i pracować z lokalnymi bazami danych SQL.

muhammad tayyab
źródło
0

Miałem ten sam problem, który automatycznie rozwiązał się po ostatniej aktualizacji systemu Microsoft Windows. Czy ktoś doświadcza tego samego?

Syed Wahhab
źródło
0

Miałem dokładny problem, wypróbowałem kilka soultion, które nie działały, ostatnio ponownie uruchomiłem system, działało dobrze.

saran
źródło
0

Aby prześledzić błąd „Upłynął limit czasu połączenia” , upewnij się, że:

  • Wystąpienie aparatu bazy danych programu SQL Server jest gotowe i działa.
  • Usługa przeglądarki SQL Server jest uruchomiona.
  • Protokół TCP / IP jest włączony.
  • Nazwa serwera została wpisana poprawnie.
  • Nie ma problemów z siecią, jak wspomniano w Jak sprawdzić łączność wystąpienia SQL Server z serwera aplikacji do serwera bazy danych
  • Port TCP / IP dla wystąpienia aparatu bazy danych nie jest blokowany przez zaporę.
  • Klient i serwer są skonfigurowani do używania tego samego protokołu sieciowego.

Aby uzyskać więcej informacji, sprawdź, czy upłynął limit czasu połączenia. Limit czasu upłynął podczas próby wykorzystania potwierdzenia uzgadniania przed logowaniem

Mohamed
źródło
Który z tych przypadków dotyczy sporadycznych błędów?
RonJohn,
Edytuj, aby ujawnić przynależność, jest to wymagane . Dzięki.
Maximillian Laumeister
0

Dodanie tutaj odpowiedzi pomimo wcześniej zaakceptowanej odpowiedzi. Ponieważ mój scenariusz został potwierdzony jako DNS. Mówiąc dokładniej, przekroczono limit czasu DNS podczas uzgadniania przed logowaniem. Zmieniając nazwę DNS na adres IP (lub używając wpisu w pliku Hosts), omijasz problem. Jednak kosztem utraty automatycznej rozdzielczości IP.

Na przykład nawet jeśli wartość limitu czasu Ciąg połączenia jest ustawiona na 60 przez pełną minutę, nadal może się to zdarzyć w ciągu kilku sekund od próby. Co prowadzi do pytania, dlaczego upłynąłby limit czasu przed określonym limitem czasu? DNS.

Barry
źródło