Błąd połączenia (Error 26)

Błąd połączenia (Error 26) sygnalizuje niemożność zlokalizowania serwera lub instancji SQL określonej w żądaniu połączenia.

Co oznacza komunikat SQL Server Error 26

Błąd połączenia oznaczony jako Error 26 pojawia się w aplikacjach korzystających z Microsoft SQL Server, gdy klient nie potrafi zlokalizować wskazanego serwera albo instancji SQL Server. Dotyczy to etapu ustalania miejsca docelowego połączenia, a nie samego uwierzytelniania użytkownika. Oznacza to, że poprawny login i hasło nie rozwiążą problemu, jeżeli klient nie może odnaleźć instancji, ustalić jej adresu lub uzyskać dostępu do właściwego portu sieciowego.

Typowym przykładem jest połączenie zapisane jako NAZWA-KOMPUTERA\NAZWA_INSTANCJI. W takim zapisie klient musi najpierw rozpoznać komputer, odszukać wskazaną instancję i ustalić port TCP, na którym instancja nasłuchuje. Podobny problem może wystąpić przy błędnej nazwie hosta, literówce w nazwie instancji, nieaktualnym aliasie SQL Server albo użyciu nazwy dostępnej tylko w innej sieci. Error 26 nie wskazuje więc jednej konkretnej przyczyny, lecz informuje o nieudanym odnalezieniu punktu końcowego SQL Server.

Nazwa instancji, SQL Server Browser i port TCP

W przypadku nazwanej instancji SQL Server ważną rolę może odgrywać usługa SQL Server Browser. Nasłuchuje ona standardowo na porcie UDP 1434 i odpowiada klientom na pytania dotyczące instancji uruchomionych na danym komputerze oraz portów używanych przez te instancje. Jeżeli usługa jest zatrzymana, port UDP 1434 jest filtrowany albo zapytanie nie dociera do właściwego hosta, klient może nie uzyskać informacji potrzebnych do połączenia z nazwanym wystąpieniem.

Instancja SQL Server może jednak działać na konkretnym, znanym porcie TCP, bez polegania na automatycznym wyszukiwaniu przez Browser. Wtedy punkt docelowy można określić w formie nazwy hosta i portu, na przykład serwer,51433, o ile taki port jest rzeczywiście skonfigurowany dla danej instancji. Numer portu nie jest uniwersalny dla każdej instalacji. Domyślna instancja SQL Server często korzysta z portu TCP 1433, ale administrator może ustawić inny port, a named instance zwykle otrzymuje port dynamiczny lub statyczny zależnie od konfiguracji. Samo otwarcie TCP 1433 nie naprawi zatem połączenia, jeżeli konkretna instancja nasłuchuje gdzie indziej.

Rozróżnienie błędu nazwy od blokady sieciowej

Diagnostykę zaczyna się od porównania danych wpisanych w aplikacji z konfiguracją SQL Server. Należy sprawdzić nazwę komputera, nazwę instancji, używany alias oraz sposób zapisu adresu. Dla połączenia do domyślnej instancji nazwa może występować bez części po ukośniku, natomiast dla instancji nazwanej musi odpowiadać dokładnemu identyfikatorowi skonfigurowanemu podczas instalacji. Warto także zweryfikować, czy nazwa hosta rozwiązuje się do właściwego adresu IP i czy komputer kliencki znajduje się w sieci, z której serwer jest osiągalny.

Kolejny etap polega na sprawdzeniu protokołów w SQL Server Configuration Manager. Dla połączeń sieciowych znaczenie ma przede wszystkim TCP/IP, który musi być włączony dla odpowiedniej instancji. Po zmianie ustawień protokołu konieczne może być ponowne uruchomienie usługi SQL Server. Należy też potwierdzić, na jakim porcie instancja faktycznie nasłuchuje, oraz skontrolować reguły zapory systemu Windows i urządzeń sieciowych. Zapora może blokować TCP używany przez instancję albo UDP 1434 potrzebny do odnajdywania nazwanej instancji. W takiej sytuacji serwer może działać poprawnie lokalnie, a mimo to pozostawać niewidoczny dla aplikacji uruchomionej na innym komputerze.

Postępowanie przy utrwalonym Error 26

Jeżeli nazwa hosta i instancji są prawidłowe, a usługi działają, należy ustalić, czy problem dotyczy wykrywania instancji, czy bezpośredniego dostępu do jej portu. Pomocne jest użycie jawnego adresu hosta i znanego portu TCP zamiast formatu z nazwą instancji. Jeżeli takie połączenie działa, przyczyną jest zwykle mechanizm lokalizowania named instance, usługa SQL Server Browser, filtracja UDP 1434 albo nieaktualna informacja o porcie. Jeżeli połączenie nadal nie działa, trzeba sprawdzić dostępność właściwego portu TCP, konfigurację TCP/IP oraz trasę między klientem i serwerem.

Skuteczna naprawa powinna zachować zgodność wszystkich elementów: konfiguracji instancji SQL Server, ustawień klienta, aliasów, nazw DNS lub NetBIOS oraz reguł zapory. Nie należy zmieniać portów ani nazw przypadkowo, ponieważ może to odłączyć inne aplikacje korzystające z tej samej instancji. Przy diagnostyce warto zapisać dokładny ciąg połączenia, nazwę instancji, adres serwera, wynik rozpoznawania nazwy oraz ustalony port TCP. Taki zestaw informacji pozwala odtworzyć błąd i zweryfikować, czy poprawa wynika ze zmiany konfiguracji, przywrócenia usługi Browser, odblokowania ruchu sieciowego czy skorygowania danych w aplikacji.