sys.dm_tcp_listener_states zwraca listę portów i adresów, na których instancja SQL Server nasłuchuje połączeń TCP.
Rola widoku sys.dm_tcp_listener_states w SQL Server
sys.dm_tcp_listener_states jest dynamicznym widokiem zarządzania (DMV, Dynamic Management View) dostępnym w silniku Microsoft SQL Server. Zwraca informacje o punktach nasłuchu TCP utworzonych przez uruchomioną instancję SQL Server. Każdy rekord opisuje adres IP, port, rodzinę adresów oraz stan konkretnego nasłuchującego endpointu. Widok dotyczy rzeczywistego stanu procesu serwera, dlatego może pomóc ustalić, czy instancja ma aktywny listener TCP na porcie oczekiwanym przez klienta.
Podstawowe zapytanie diagnostyczne ma postać SELECT * FROM sys.dm_tcp_listener_states;. W wyniku znajdują się między innymi kolumny listener_id, ip_address, is_ipv4, port, type, type_desc, state oraz state_desc. Kolumna ip_address wskazuje adres związany z nasłuchem, natomiast port pokazuje numer portu TCP. Pole is_ipv4 pozwala odróżnić wpis dotyczący IPv4 od wpisu dotyczącego IPv6, a pola opisujące typ i stan ułatwiają interpretację rekordu bez konieczności posługiwania się samymi wartościami liczbowymi.
Adres IP, port i typ listenera
Interpretacja adresu z DMV wymaga uwzględnienia sposobu skonfigurowania protokołu TCP/IP w SQL Server Configuration Manager. Wpis odpowiadający adresowi ogólnemu, takiemu jak 0.0.0.0, oznacza nasłuchiwanie na wszystkich lokalnych adresach IPv4, jeżeli konfiguracja i system operacyjny dopuszczają takie zachowanie. Analogicznie adres :: oznacza ogólny punkt nasłuchu dla IPv6. Rekord z konkretnym adresem, na przykład adresem przypisanym do jednej karty sieciowej, ogranicza interpretację do tego adresu. Samo pojawienie się adresu w DMV nie oznacza jednak, że połączenie będzie możliwe z każdej sieci.
Kolumna type_desc pozwala rozpoznać przeznaczenie listenera. Wpis typu TSQL odnosi się do połączeń klienta z silnikiem SQL Server przy użyciu protokołu TDS przenoszonego przez TCP. Inne typy mogą dotyczyć funkcji silnika korzystających z endpointów TCP, takich jak Database Mirroring, Service Broker lub mechanizmy wysokiej dostępności. Nie należy więc traktować każdego rekordu jako portu przeznaczonego do zwykłego logowania aplikacji. Przy analizie problemu z aplikacją warto odfiltrować wpisy zgodne z typem używanym przez dane połączenie i osobno sprawdzić port oraz adres.
Odczyt stanu i korelacja z konfiguracją
Najbardziej użyteczne jest zestawienie wartości DMV z konfiguracją instancji oraz z parametrami połączenia. Przykładowe zapytanie może ograniczyć wynik do listenerów typu T-SQL:
SELECT listener_id, ip_address, is_ipv4, port, type_desc, state_desc FROM sys.dm_tcp_listener_states WHERE type_desc = 'TSQL';
Jeżeli klient próbuje połączyć się z nazwą hosta i portem 1433, a widok pokazuje listener T-SQL na innym porcie, przyczyną może być używanie portu dynamicznego albo niezgodność konfiguracji klienta. Dla nazwanych instancji SQL Server port nie musi być stały, dlatego do analizy trzeba uwzględnić konfigurację TCP/IP, usługę SQL Server Browser oraz sposób zapisania parametrów połączenia. SQL Server Browser korzysta z UDP 1434 i nie jest tym samym mechanizmem co TCP listener widoczny w sys.dm_tcp_listener_states.
Stan opisany w state_desc należy czytać razem z pozostałymi kolumnami. Wpis w stanie aktywnym wskazuje, że proces SQL Server zarejestrował listener, natomiast stan problemowy lub przejściowy może oznaczać, że endpoint nie jest gotowy do normalnej obsługi połączeń. DMV nie zastępuje jednak kontroli zapory sieciowej, routingu, reguł bezpieczeństwa ani testu połączenia z komputera klienckiego. Lokalny listener może działać poprawnie, a połączenie zdalne nadal może być blokowane przez Windows Firewall, urządzenie sieciowe albo błędny adres DNS.
Znaczenie widoku przy analizie niedostępności SQL Server
Widok jest przydatny przede wszystkim wtedy, gdy trzeba rozdzielić problem procesu SQL Server od problemu sieciowego. Jeżeli nie ma oczekiwanego wpisu typu T-SQL, należy sprawdzić, czy protokół TCP/IP jest włączony, czy instancja została ponownie uruchomiona po zmianie portu oraz czy wybrany adres IP jest aktywny w systemie. Jeżeli listener istnieje, ale ma inny port niż używany przez aplikację, korekty wymaga konfiguracja klienta albo konfiguracja endpointu. Gdy adres i port są prawidłowe, dalsza diagnostyka powinna objąć możliwość lokalnego połączenia, reguły zapory i dostępność portu z sieci, z której korzysta klient.
Wynik sys.dm_tcp_listener_states nie pokazuje haseł, treści zapytań ani jakości danych w bazie. Nie służy także do sprawdzania, czy użytkownik ma poprawne uprawnienia do konkretnej bazy. Jego zakres jest węższy: opisuje stan punktów nasłuchu TCP związanych z instancją SQL Server. Przy pracy diagnostycznej warto zapisać wynik wraz z nazwą instancji, czasem wykonania zapytania i informacją o używanym porcie. Taki zestaw pozwala porównać stan przed i po restarcie usługi lub zmianie konfiguracji oraz odróżnić brak listenera od błędu uwierzytelniania, niedostępności bazy albo blokady sieciowej.
