Test połączenia przez PowerShell

Test połączenia przez PowerShell pozwala sprawdzić dostępność instancji SQL Server ze skryptu bez interfejsu graficznego.

Na czym polega test połączenia przez PowerShell

Test połączenia przez PowerShell służy do sprawdzenia, czy komputer może komunikować się z określonym wystąpieniem Microsoft SQL Server bez korzystania z graficznych narzędzi administracyjnych. W praktyce analizuje się kilka niezależnych elementów: rozpoznanie nazwy hosta, dostępność adresu IP, możliwość zestawienia połączenia TCP z portem SQL Server oraz poprawność próby logowania do konkretnej bazy danych. Sam fakt, że komputer odpowiada na polecenie ping, nie potwierdza dostępności usługi SQL Server, ponieważ zapora może blokować protokół ICMP, a port TCP używany przez silnik może pozostawać niedostępny.

W PowerShell można użyć polecenia Test-NetConnection, na przykład Test-NetConnection -ComputerName sql01 -Port 1433. Parametr -ComputerName wskazuje nazwę hosta albo adres IP, natomiast -Port określa port TCP, z którym ma zostać wykonana próba połączenia. Wynik zawiera między innymi wartość TcpTestSucceeded. Wartość True oznacza, że z danego komputera udało się nawiązać połączenie TCP z podanym adresem i portem. Nie oznacza jeszcze, że zaakceptowane zostaną dane uwierzytelniające ani że wybrana instancja SQL Server będzie poprawnie obsługiwała zapytania.

Port, instancja i rozwiązywanie nazwy serwera

Domyślna instancja SQL Server często korzysta z portu TCP 1433, ale nie jest to reguła obowiązująca dla każdej konfiguracji. Instancja nazwana może używać portu dynamicznego, a administrator może również ustawić niestandardowy port statyczny. Z tego powodu test należy wykonać dla rzeczywistego portu przypisanego do danej instancji, a nie automatycznie dla portu 1433. Jeżeli aplikacja łączy się z nazwą w formacie HOST\INSTANCJA, samo polecenie Test-NetConnection -ComputerName HOST -Port 1433 może badać niewłaściwy port.

Przy analizie instancji nazwanej znaczenie może mieć usługa SQL Server Browser, która pomaga klientom odnaleźć port przypisany do instancji. Test portu powinien jednak opierać się na konkretnym numerze portu ustalonym dla silnika. Najpierw można sprawdzić rozpoznawanie nazwy poleceniem Resolve-DnsName sql01 albo użyć Test-NetConnection -ComputerName sql01 -InformationLevel Detailed. Jeżeli nazwa nie jest rozpoznawana, problem dotyczy DNS, pliku hosts lub konfiguracji sieciowej, a nie samego uwierzytelniania SQL Server. Jeżeli nazwa rozwiązuje się poprawnie, lecz TcpTestSucceeded ma wartość False, należy przeanalizować nasłuchiwanie silnika, zaporę oraz trasę sieciową.

Od testu TCP do rzeczywistej sesji SQL Server

Po potwierdzeniu dostępności portu warto wykonać próbę na poziomie protokołu SQL Server. Do tego celu może służyć moduł SqlServer i polecenie Invoke-Sqlcmd. Przykładowa forma to Invoke-Sqlcmd -ServerInstance "sql01,1433" -Database "master" -Query "SELECT @@SERVERNAME AS ServerName, @@VERSION AS Version;". Zapis sql01,1433 wskazuje konkretny port TCP. Wynik takiego polecenia potwierdza więcej niż test portu: klient nawiązał sesję z silnikiem, przeprowadził negocjację protokołu, przeszedł uwierzytelnianie i wykonał zapytanie w bazie master.

Błąd zwrócony przez Invoke-Sqlcmd należy interpretować zgodnie z jego warstwą. Nieprawidłowa nazwa serwera lub niedostępny port może prowadzić do błędu sieciowego albo przekroczenia limitu czasu. Odrzucenie loginu wskazuje na problem z kontem, hasłem, trybem uwierzytelniania lub uprawnieniami. Udane połączenie z master nie dowodzi jeszcze dostępu do docelowej bazy aplikacyjnej, ponieważ uprawnienia mogą być nadawane osobno dla każdej bazy. W środowisku Windows można użyć -Credential dla poświadczeń SQL albo -TrustedConnection dla uwierzytelniania zintegrowanego, zależnie od konfiguracji serwera i klienta.

Wyniki testu dobrze zapisywać razem z nazwą komputera wykonującego polecenie, rozwiązaną nazwą hosta, adresem IP, numerem portu, czasem wykonania oraz pełnym komunikatem błędu. Pozwala to odróżnić problem lokalny od problemu występującego na wielu stacjach. Należy również pamiętać, że test wykonany z serwera może zakończyć się powodzeniem, podczas gdy ten sam test z sieci biurowej będzie blokowany przez reguły zapory. Kierunek połączenia, profil sieciowy i zakres reguły zapory mają bezpośredni wpływ na wynik.

Wykorzystanie wyników przy diagnostyce komputera

Diagnostyka powinna przebiegać od najniższej warstwy do najwyższej: najpierw sprawdza się konfigurację adresu i rozwiązywanie nazwy, potem dostępność właściwego portu TCP, następnie negocjację połączenia SQL Server, uwierzytelnianie i dostęp do wymaganej bazy. Taka kolejność ogranicza błędne wnioski. Przykładowo, instalowanie sterownika lub zmiana hasła nie rozwiąże problemu, jeżeli Test-NetConnection nie może dotrzeć do portu. Z kolei otwarcie portu nie naprawi błędu wynikającego z niepoprawnego loginu albo braku uprawnień do bazy.

W przypadku problemów z działaniem aplikacji korzystającej z SQL Server można porównać wynik testu wykonanego w PowerShell z ustawieniami używanymi przez aplikację: nazwą serwera, nazwą instancji, numerem portu, metodą uwierzytelniania i nazwą bazy. Rozbieżność w jednym z tych parametrów może powodować, że ręczny test sprawdza inne wystąpienie niż program. Przydatne jest także sprawdzenie, czy aplikacja korzysta z aliasu SQL Server, protokołu TCP/IP oraz aktualnego sterownika. Test przez PowerShell jest więc narzędziem weryfikacyjnym, a nie samodzielną naprawą usługi; jego wartość polega na precyzyjnym wskazaniu warstwy, na której pojawia się problem.