Rejestracja portów w rejestrze

Rejestracja portów w rejestrze systemowym pozwala usłudze SQL Server Browser odnaleźć aktywne instancje.

Rola rejestru w odnajdywaniu instancji SQL Server

Rejestracja portów w rejestrze systemowym jest elementem konfiguracji instancji Microsoft SQL Server, zwłaszcza wtedy, gdy na jednym komputerze działa więcej niż jedna instancja albo gdy klient łączy się z instancją nazwaną. SQL Server Browser wykorzystuje informacje zapisane w konfiguracji SQL Server, aby ustalić, które instancje są dostępne oraz na jakich portach TCP oczekują na połączenia. Dzięki temu klient może podać nazwę serwera i instancji, na przykład SERWER\KSIĘGOWOŚĆ, zamiast znać wcześniej konkretny numer portu.

SQL Server Browser nasłuchuje na porcie UDP 1434. Klient wysyła do tej usługi zapytanie zawierające nazwę instancji. Browser odczytuje dane konfiguracyjne i zwraca informacje potrzebne do nawiązania właściwego połączenia, w tym port TCP przypisany do danej instancji. Sam port UDP 1434 nie jest portem, na którym standardowo odbywa się komunikacja z bazą danych. Jest używany przez mechanizm wykrywania instancji, natomiast właściwa sesja klienta z silnikiem SQL Server przebiega przez port TCP instancji.

Wartości TcpPort i TcpDynamicPorts

Ustawienia protokołu TCP dla instancji SQL Server są przechowywane w gałęzi rejestru związanej z konfiguracją tej instancji. Typowa ścieżka zawiera elementy HKLM\SOFTWARE\Microsoft\Microsoft SQL Server, identyfikator instancji oraz podklucz MSSQLServer\SuperSocketNetLib\Tcp. W praktyce dokładna nazwa części identyfikującej instancję zależy od instalacji, dlatego administracja powinna posługiwać się SQL Server Configuration Manager albo odczytem konfiguracji konkretnego komputera, a nie zakładać jedną identyczną ścieżkę dla wszystkich instalacji.

W podkluczu IPAll znajdują się między innymi wartości TcpPort i TcpDynamicPorts. TcpPort określa statyczny port TCP, na którym instancja ma nasłuchiwać. Jeżeli używane jest przypisywanie dynamiczne, numer portu może być zapisany w TcpDynamicPorts, a przy kolejnym uruchomieniu usługi może zostać wybrany inny dostępny port. Wpisanie wartości do rejestru nie zmienia aktywnego nasłuchu natychmiast. Po zmianie ustawień protokołu TCP konieczne jest ponowne uruchomienie usługi danej instancji SQL Server, aby silnik zastosował nową konfigurację. Po zmianie ustawień usługi SQL Server Browser trzeba również zrestartować Browser, jeżeli zmiana dotyczy danych, które ma on odczytywać lub publikować.

Przepływ połączenia do instancji nazwanej

Połączenie do instancji nazwanej można przedstawić jako dwa następujące po sobie etapy. Najpierw klient kontaktuje się z SQL Server Browser przez UDP 1434 i pyta o port instancji. Następnie klient otwiera połączenie TCP do zwróconego portu, na przykład do portu statycznego skonfigurowanego dla konkretnej instancji. Jeżeli Browser jest zatrzymany, port UDP 1434 jest filtrowany albo instancja nie publikuje poprawnych informacji, klient może nie odnaleźć instancji po nazwie, nawet gdy sam silnik SQL Server działa.

Zapora sieciowa musi uwzględniać oba elementy tego przepływu. Dla wykrywania instancji potrzebne jest zezwolenie na ruch UDP do portu 1434, a dla właściwego połączenia należy dopuścić ruch TCP do portu przypisanego do instancji. Przy portach dynamicznych reguła zapory musi odpowiadać aktualnie używanemu numerowi, co utrudnia stabilną konfigurację. Z tego powodu w środowiskach wymagających przewidywalnej komunikacji często konfiguruje się instancję nazwaną na stałym porcie TCP, a połączenia kieruje bezpośrednio na ten port. W takim wariancie klient może użyć składni serwer,port, bez uzależniania połączenia od odpowiedzi SQL Server Browser.

Problemy z rejestracją portu należy rozdzielać od problemów z uwierzytelnianiem, uprawnieniami i samą bazą danych. Jeżeli test połączenia kończy się błędem przekroczenia czasu oczekiwania, pierwsze sprawdzenie powinno obejmować stan usługi SQL Server, ustawiony port TCP, działanie SQL Server Browser oraz reguły zapory. Do potwierdzenia aktywnego nasłuchu można użyć narzędzia systemowego netstat -ano albo polecenia PowerShell Test-NetConnection z właściwym portem TCP. Wynik takiego testu pokazuje dostępność transportu, ale nie potwierdza jeszcze poprawności logowania do SQL Server.

Kontrola konfiguracji i bezpieczna zmiana portu

Konfigurację portów najlepiej sprawdzać w SQL Server Configuration Manager, w ustawieniach SQL Server Network Configuration dla właściwej instancji i protokołu TCP/IP. Należy zweryfikować, czy protokół TCP/IP jest włączony, czy instancja ma port statyczny lub dynamiczny oraz czy wpis dotyczy odpowiedniej sekcji adresów IP. Warto także sprawdzić dziennik SQL Server, w którym podczas uruchamiania silnik zapisuje informację o rozpoczęciu nasłuchu na określonym porcie TCP. Taki wpis pozwala porównać deklarowaną konfigurację z rzeczywistym stanem procesu.

Ręczna edycja rejestru jest obarczona ryzykiem pomylenia instancji, podklucza lub typu wartości. Błędny numer portu może spowodować, że klienci nadal będą kierowani na poprzedni port, a usługa SQL Server nie będzie dostępna przez oczekiwany adres. Przed zmianą należy ustalić nazwę instancji, zapisać aktualną konfigurację, zastosować jedną spójną metodę konfiguracji i ponownie uruchomić odpowiednią usługę. Po restarcie trzeba sprawdzić nasłuch TCP, odpowiedź Browsera oraz połączenie z klienta znajdującego się w tej samej sieci. Diagnostyka naprawcza powinna obejmować również analizę wpisów rejestru, usług systemowych i reguł zapory, ponieważ poprawna wartość portu w rejestrze nie wystarcza, jeśli usługa nie została zrestartowana albo ruch sieciowy jest blokowany.