Połączenie z SQL Server czasami działa

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?

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.

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!

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

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.

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.

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.

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

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

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

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

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

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ń.

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.

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.

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”).

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ę.

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.

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

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.

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

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.

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

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.