Ping serwera SQL

Ping serwera SQL sprawdza jedynie dostępność hosta w sieci — nie potwierdza, że instancja przyjmuje połączenia.

Co właściwie sprawdza ping serwera SQL

Ping serwera SQL jest podstawowym testem łączności sieciowej. W typowym użyciu polecenie ping wysyła do wskazanego hosta komunikaty ICMP Echo Request, a następnie oczekuje na komunikaty ICMP Echo Reply. Jeżeli odpowiedź wraca, można potwierdzić, że host jest osiągalny z danego komputera przez skonfigurowaną trasę sieciową. Wynik pokazuje również czas przejścia pakietu oraz ewentualne straty pakietów.

Ten test nie otwiera połączenia z silnikiem Microsoft SQL Server i nie wykonuje logowania do bazy danych. Odpowiedź na ICMP nie oznacza więc, że usługa SQL Server działa, instancja nasłuchuje na właściwym adresie ani że użytkownik ma uprawnienia do połączenia. Serwer może odpowiadać na ping mimo zatrzymanej usługi bazodanowej. Możliwa jest także sytuacja odwrotna: SQL Server działa prawidłowo, lecz zapora sieciowa blokuje komunikaty ICMP, dlatego ping kończy się komunikatem o przekroczeniu limitu czasu.

Adres hosta, DNS i trasa pakietów

Przed oceną wyniku trzeba ustalić, czy nazwa serwera SQL została przetłumaczona na właściwy adres IP. W środowisku korzystającym z DNS polecenie ping może rozwiązać nazwę hosta, ale nie musi potwierdzić poprawności konfiguracji używanej przez klienta SQL Server. Warto porównać nazwę z adresem zwróconym przez system oraz sprawdzić, czy klient i serwer znajdują się w sieciach, między którymi istnieje prawidłowa trasa.

Przykładowe polecenie ping nazwa-serwera pozwala sprawdzić odpowiedzi dla nazwy hosta, natomiast ping 192.0.2.10 testuje wskazany adres IPv4. Sam czas odpowiedzi nie jest miarą wydajności zapytań SQL Server. Niski czas ICMP nie dowodzi, że instancja szybko obsługuje zapytania, ponieważ komunikaty ping omijają negocjowanie sesji TDS, uwierzytelnianie i wykonywanie instrukcji SQL. Podobnie pojedyncza utracona odpowiedź nie musi oznaczać awarii bazy, jeżeli urządzenie filtruje lub ogranicza odpowiedzi ICMP.

Sprawdzenie portu i właściwej instancji SQL Server

Po potwierdzeniu osiągalności hosta należy sprawdzić kanał używany przez Microsoft SQL Server. Dla instancji domyślnej często wykorzystywany jest port TCP 1433, ale numer portu może zostać zmieniony w konfiguracji SQL Server. Instancje nazwane mogą korzystać z portów dynamicznych, dlatego sama nazwa serwera nie wystarcza do ustalenia miejsca nasłuchu. Jeżeli klient odwołuje się do instancji nazwanej, znaczenie może mieć także usługa SQL Server Browser, która pomaga ustalić port tej instancji za pośrednictwem protokołu UDP 1434.

Test portu TCP odpowiada na inne pytanie niż ping. W systemie Windows można użyć polecenia Test-NetConnection nazwa-serwera -Port 1433, aby sprawdzić, czy z danego komputera da się nawiązać połączenie TCP z konkretnym portem. Udany test potwierdza dostępność punktu TCP, ale nadal nie potwierdza poprawnego uwierzytelnienia ani dostępności określonej bazy. Do sprawdzenia rzeczywistego połączenia z SQL Server można użyć narzędzia sqlcmd, podając właściwy serwer, instancję, port oraz sposób uwierzytelniania. Dopiero odpowiedź silnika na próbę logowania i wykonania zapytania pozwala ocenić warstwę bazodanową.

Interpretacja wyników podczas diagnostyki

Brak odpowiedzi na ping należy rozdzielić od braku połączenia z SQL Server. Przyczyną może być nieprawidłowa nazwa DNS, błędny adres IP, niedostępna trasa, awaria hosta, filtr ICMP albo reguła zapory. Następnie trzeba sprawdzić port TCP przypisany do instancji oraz stan usługi SQL Server. Jeżeli ping działa, lecz port jest zamknięty, problem dotyczy najczęściej usługi, konfiguracji nasłuchu, zapory albo użycia niewłaściwego numeru portu.

Jeżeli port jest dostępny, a logowanie nadal się nie udaje, dalszej analizy wymagają dane uwierzytelniające, tryb autoryzacji, nazwa instancji, uprawnienia loginu, dostępność konkretnej bazy oraz treść komunikatu klienta. W przypadku połączeń szyfrowanych znaczenie może mieć również konfiguracja TLS i certyfikatu, ale tych elementów nie da się ocenić poleceniem ping. Prawidłowa kolejność testów powinna więc obejmować rozwiązywanie nazwy, trasę, ICMP jako test pomocniczy, port TCP, wykrycie właściwej instancji i dopiero na końcu próbę logowania do SQL Server. Taka interpretacja zapobiega uznaniu dostępności hosta za dowód działania całej usługi bazodanowej.