SQL Server Browser – konfiguracja

Konfiguracja SQL Server Browser wymaga otwarcia portu UDP 1434 oraz uruchomienia samej usługi.

SQL Server Browser – konfiguracja i rola usługi

SQL Server Browser to usługa systemu Windows, która pomaga aplikacjom odnaleźć właściwą instancję Microsoft SQL Server działającą na określonym komputerze. Ma to szczególne znaczenie wtedy, gdy na jednym urządzeniu funkcjonuje więcej niż jedna instancja albo gdy połączenie nie korzysta z jednej, z góry ustalonej wartości portu TCP. Program kliencki może wysłać zapytanie do usługi Browser, a następnie otrzymać informację, na jakim porcie i pod jaką nazwą dostępna jest wskazana instancja.

Sama instalacja SQL Server nie zawsze oznacza, że SQL Server Browser zostanie uruchomiony i będzie dostępny w sieci. Usługa może być wyłączona ze względów administracyjnych, zatrzymana po zmianie konfiguracji systemu albo zablokowana przez zaporę. W takiej sytuacji aplikacja może zgłaszać brak możliwości połączenia, mimo że silnik bazy danych działa poprawnie. Dlatego konfigurację należy analizować jako zestaw kilku elementów: stan usługi, sposób adresowania instancji, ustawienia sieciowe SQL Server oraz reguły zapory systemu Windows.

W praktyce najczęściej spotyka się instancję domyślną oraz instancję nazwaną. Instancja domyślna jest zwykle wskazywana samą nazwą hosta, natomiast instancja nazwana ma postać podobną do NAZWA-KOMPUTERA\NAZWA-INSTANCJI. Przy instancji nazwanej klient musi wiedzieć, z którym procesem powinien się połączyć. SQL Server Browser może pośredniczyć w ustaleniu portu, dzięki czemu nie trzeba wpisywać go ręcznie w każdym programie. Nie jest to jednak jedyna dostępna metoda.

SQL Server Browser – port UDP 1434 a port TCP silnika

W konfiguracji występują dwa różne rodzaje komunikacji, których nie należy utożsamiać. SQL Server Browser nasłuchuje na porcie UDP 1434. Jest to port wykorzystywany do odpowiadania na pytania o dostępne instancje i ich parametry sieciowe. Samo połączenie z bazą danych odbywa się natomiast przez port TCP przypisany do konkretnego silnika. Otwarcie UDP 1434 może więc pomóc w odnalezieniu instancji, lecz nie zastępuje reguły pozwalającej na właściwy ruch TCP.

W przypadku instancji nazwanych SQL Server może korzystać z portów dynamicznych. Oznacza to, że port TCP nie musi być identyczny po każdej zmianie lub ponownym uruchomieniu usługi. Takie ustawienie bywa wygodne podczas instalacji, ale komplikuje tworzenie reguł zapory i diagnozowanie połączeń. W środowisku, w którym ważna jest przewidywalność, można przypisać instancji stały port TCP, a następnie skonfigurować klientów tak, aby korzystali bezpośrednio z tego portu. Wtedy usługa Browser nie jest konieczna do samego odnalezienia silnika, choć może pozostać użyteczna dla zgodności z istniejącymi aplikacjami.

Warto rozróżnić zapis z nazwą instancji od zapisu z numerem portu. Połączenie do HOST\INSTANCJA może wymagać odpowiedzi SQL Server Browser. Połączenie do HOST,PORT wskazuje port bezpośrednio i może ominąć etap wyszukiwania instancji. Jeśli pierwsza forma nie działa, test drugiej może pomóc ustalić, czy problem dotyczy usługi Browser, czy właściwego połączenia TCP. Taki test powinien być wykonywany zgodnie z zasadami dostępu i uprawnieniami obowiązującymi w danej sieci.

SQL Server Browser – typowe problemy z konfiguracją

Jednym z częstych problemów jest zatrzymana usługa. W narzędziu Usługi systemu Windows należy odszukać pozycję SQL Server Browser, sprawdzić jej stan i przeanalizować typ uruchamiania. W zależności od przyjętej polityki usługa może być uruchamiana automatycznie, ręcznie albo tylko wtedy, gdy wymaga tego określony scenariusz. Zmiana ustawienia powinna wynikać z potrzeb środowiska, a nie z przypadkowego wyboru. Po modyfikacji warto sprawdzić dziennik zdarzeń oraz ponowić próbę połączenia z aplikacji.

Drugą przyczyną bywa zapora. Reguła dla UDP 1434 musi dotyczyć właściwego profilu sieciowego i właściwego interfejsu. Komputer może mieć jednocześnie kilka profili, na przykład prywatny i publiczny, a reguła aktywna tylko dla jednego z nich nie zapewni dostępu w pozostałych. Należy również zweryfikować, czy zapora nie ogranicza ruchu do wybranych adresów źródłowych. Szersze otwarcie portu bez sprawdzenia zakresu dostępu może zwiększyć powierzchnię narażenia, dlatego korzystniejsze jest ograniczenie reguły do zaufanych segmentów lub konkretnych urządzeń.

Jeśli SQL Server Browser odpowiada, ale aplikacja nadal nie może się połączyć, problem może leżeć po stronie portu TCP silnika. W SQL Server Configuration Manager należy sprawdzić, czy protokół TCP/IP jest włączony dla właściwej instancji oraz jaki port został przypisany. Po zmianie parametrów sieciowych często potrzebne jest ponowne uruchomienie usługi silnika. Należy też upewnić się, że reguła zapory obejmuje ten właśnie port, a nie tylko UDP 1434.

Nie należy pomijać nazewnictwa. Błąd może wynikać z wpisania niepoprawnej nazwy hosta, literówki w nazwie instancji, użycia starego aliasu albo rozwiązywania nazwy na niewłaściwy adres. Przydatne jest porównanie połączenia po nazwie komputera, po adresie IP oraz po jawnym numerze portu, o ile taki test jest dozwolony. Różnica w wynikach pomaga oddzielić problem usługi od problemu DNS, routingu lub lokalnej konfiguracji klienta.

SQL Server Browser – praktyczne wskazówki diagnostyczne

Diagnozę najlepiej rozpocząć od ustalenia, jaki typ instancji jest używany i w jaki sposób aplikacja próbuje się z nią łączyć. Warto zebrać dokładny komunikat błędu, nazwę hosta, nazwę instancji oraz informację, czy problem występuje lokalnie, czy tylko z innego komputera. Inaczej interpretuje się sytuację, w której połączenie działa na tym samym urządzeniu, a nie działa z sieci, a inaczej tę, w której nie działa nawet lokalnie.

Następnie można przejść przez uporządkowaną kontrolę:

• sprawdzenie, czy usługa SQL Server Browser istnieje i jest uruchomiona,
• potwierdzenie, że właściwa instancja silnika działa,
• weryfikacja włączenia protokołu TCP/IP dla tej instancji,
• ustalenie portu TCP używanego przez silnik,
• sprawdzenie reguł zapory dla UDP 1434 i właściwego portu TCP,
• porównanie połączenia z nazwą instancji oraz z jawnym portem,
• analiza komunikatów w Podglądzie zdarzeń i dziennikach SQL Server.

Przy testach warto zmieniać jeden element naraz. Jednoczesne uruchomienie kilku usług, modyfikacja zapory i zmiana parametrów klienta utrudnia ustalenie, która czynność usunęła problem. Dobrą praktyką jest zapisanie ustawień początkowych oraz odnotowanie każdej zmiany. Po zakończeniu testów należy sprawdzić, czy reguły dostępu nie są szersze niż wymagane i czy po restarcie komputera konfiguracja nadal zachowuje się tak samo.

Jeżeli środowisko wymaga wysokiej przewidywalności, warto rozważyć stały port TCP i jawne wskazywanie go w konfiguracji aplikacji. W takim wariancie liczba zależności jest mniejsza, a reguły zapory mogą być prostsze do opisania. SQL Server Browser można pozostawić aktywny tylko wtedy, gdy korzystają z niego istniejące programy lub użytkownicy. Decyzja powinna uwzględniać kompatybilność aplikacji, zasady bezpieczeństwa i sposób zarządzania dostępem w konkretnej sieci.

SQL Server Browser – kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy problem z połączeniem pojawia się po instalacji, aktualizacji, zmianie routera, wymianie komputera albo modyfikacji zapory i nie można jednoznacznie ustalić przyczyny. Pomoc może być potrzebna również wtedy, gdy kilka aplikacji korzysta z różnych instancji, występują cykliczne przerwy w dostępie albo konfiguracja była zmieniana przez wiele osób bez zachowania dokumentacji. Przed przekazaniem zgłoszenia dobrze przygotować nazwę programu, treść komunikatu, informację o tym, czy połączenie działa lokalnie, oraz opis ostatniej zmiany.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się wsparciem przy problemach ze sprzętem komputerowym i konfiguracją środowiska pracy. Przy zgłoszeniu można opisać objawy własnymi słowami, bez samodzielnego otwierania obudowy ani zmieniania przypadkowych reguł dostępu. W przypadku konfiguracji SQL Server Browser szczególnie przydatne są informacje o nazwie instancji, sposobie łączenia aplikacji oraz o tym, czy dostęp ma działać wyłącznie lokalnie, czy również z innych urządzeń.

Jeżeli połączenie działa tylko po wpisaniu numeru portu, a nie działa przy użyciu nazwy instancji, wskazuje to na obszar związany z usługą Browser, rozpoznawaniem nazwy albo regułą UDP 1434. Jeżeli nie działa także połączenie z jawnym portem, większego znaczenia nabierają ustawienia TCP/IP, stan silnika, zapora i routing. Takie rozróżnienie przyspiesza dalsze czynności i ogranicza ryzyko przypadkowych zmian w konfiguracji.