Porty dla SQL Server Agent

Porty dla SQL Server Agent nie są odrębne — usługa korzysta z tego samego portu co silnik bazodanowy.

Jak SQL Server Agent korzysta z portu silnika

SQL Server Agent nie posiada własnego, odrębnego portu TCP przeznaczonego wyłącznie dla tej usługi. Gdy Agent wykonuje zadanie wymagające połączenia z instancją SQL Server, komunikuje się z aparatem Database Engine tej instancji. Połączenie jest więc kierowane na port skonfigurowany dla silnika bazodanowego, a nie na specjalny port przypisany nazwie „SQL Server Agent”. Dotyczy to między innymi uruchamiania poleceń Transact-SQL, odczytywania informacji o zadaniach oraz zapisywania historii ich wykonania.

W praktyce trzeba odróżnić usługę SQL Server Agent od samego silnika SQL Server. Agent może działać jako osobna usługa systemu Windows, ale jego obecność nie powoduje automatycznego otwarcia kolejnego portu nasłuchującego dla klientów. Jeżeli zapora sieciowa blokuje port Database Engine, Agent może nie być w stanie połączyć się z lokalną lub zdalną instancją, mimo że sama usługa SQL Server Agent jest uruchomiona.

Instancja domyślna i instancja nazwana

Dla domyślnej instancji SQL Server typowym portem TCP silnika jest 1433, ale administrator może zmienić tę wartość. Numer 1433 nie jest zatem stałym portem usługi SQL Server Agent ani gwarantowanym portem każdej instalacji SQL Server. Rzeczywiste ustawienie należy sprawdzić w konfiguracji protokołu TCP/IP instancji, w sekcji dotyczącej adresów IP, zwłaszcza w polach „TCP Port” i „TCP Dynamic Ports”. Po zmianie portu usługa Database Engine musi zostać ponownie uruchomiona, aby rozpoczęła nasłuchiwanie zgodnie z nową konfiguracją.

Instancje nazwane często korzystają z portów dynamicznych. W takim wariancie numer portu może zostać przydzielony podczas uruchamiania usługi, dlatego reguła zapory ograniczona do portu 1433 może nie wystarczyć. SQL Server Agent musi wtedy korzystać z aktualnego portu danej instancji. Jeżeli klient lub komponent systemu odwołuje się do nazwy instancji zamiast do jawnie podanego numeru portu, pomocniczą rolę może pełnić SQL Server Browser, który używa UDP 1434 do informowania klientów o portach instancji. UDP 1434 nie jest jednak portem SQL Server Agent i nie zastępuje portu TCP Database Engine.

Reguły zapory i diagnostyka połączenia

Konfigurując zaporę, należy dopuścić ruch do rzeczywistego portu TCP instancji SQL Server, z której korzysta Agent. Zakres reguły powinien odpowiadać topologii środowiska: dla lokalnej instancji istotne są lokalne zasady zapory i konfiguracja połączenia, natomiast dla instancji na innym komputerze trzeba uwzględnić ruch między hostem usługi Agent a serwerem Database Engine. Samo otwarcie portu usługi SQL Server Agent nie rozwiąże problemu, ponieważ taki niezależny port nie jest używany do podstawowej komunikacji z silnikiem.

Diagnostykę warto rozpocząć od ustalenia nazwy serwera, nazwy instancji i faktycznego numeru portu. Następnie można sprawdzić, czy host uruchamiający zadanie dociera do tego portu, na przykład za pomocą polecenia Test-NetConnection w Windows PowerShell, podając nazwę hosta oraz parametr -Port. Wynik testu potwierdza jedynie możliwość nawiązania połączenia TCP; nie potwierdza poprawnego uwierzytelnienia ani uprawnień zadania. Jeżeli używana jest nazwa instancji i port dynamiczny, trzeba dodatkowo zweryfikować działanie SQL Server Browser albo skonfigurować połączenie z jawnym numerem portu.

Port nie zastępuje konfiguracji zadania

Prawidłowo dostępny port Database Engine nie gwarantuje jeszcze wykonania każdego zadania SQL Server Agent. Połączenie może zostać odrzucone z powodu niepoprawnej nazwy instancji, wyłączonego protokołu TCP/IP, błędnych danych logowania, braku uprawnień konta usługi albo błędu samego polecenia uruchamianego przez job. W przypadku zadań korzystających z innych komponentów, takich jak zewnętrzne serwisy, udziały sieciowe lub dodatkowe źródła danych, mogą być potrzebne także inne połączenia sieciowe. Nie są to jednak osobne porty przypisane usłudze SQL Server Agent.

Przy analizie problemu należy sprawdzić log historii zadania, log SQL Server Agent oraz log Database Engine, a następnie porównać czas błędu z próbą połączenia na właściwy port. Taki podział pozwala rozróżnić awarię sieciową od błędu konfiguracji instancji lub uprawnień. Najważniejsza zasada pozostaje prosta: port należy przypisać do usługi SQL Server Database Engine, a SQL Server Agent traktować jako klienta korzystającego z tego połączenia. Numer portu powinien wynikać z rzeczywistej konfiguracji konkretnej instancji, a nie z samej nazwy usługi.