Weryfikacja stanu usług

Weryfikacja stanu usług potwierdza, że komponenty SQL Server są uruchomione i odpowiadają na żądania.

Co sprawdza weryfikacja usług SQL Server

Weryfikacja stanu usług SQL Server obejmuje przede wszystkim sprawdzenie, czy usługa silnika bazy danych działa w systemie Windows i czy można nawiązać z nią poprawne połączenie. Dla instancji domyślnej nazwa usługi to zwykle MSSQLSERVER. Instancja nazwana jest reprezentowana przez usługę o nazwie MSSQL$NazwaInstancji. Sam wpis „Uruchomiono” w konsoli usług nie jest jeszcze pełnym potwierdzeniem sprawności, ponieważ proces może działać, ale silnik może nie przyjmować połączeń albo może kończyć fazę odzyskiwania po nieprawidłowym zamknięciu.

Osobno sprawdza się usługę SQL Server Agent, odpowiedzialną między innymi za wykonywanie zaplanowanych zadań, oraz SQL Server Browser, który pomaga klientom odnajdywać instancje nazwane. Usługa Agent dla instancji domyślnej występuje jako SQLSERVERAGENT, a dla instancji nazwanej jako SQLAgent$NazwaInstancji. SQL Server Browser korzysta z protokołu UDP na porcie 1434. Jego brak nie musi uniemożliwiać połączenia, jeśli klient używa bezpośrednio określonego portu TCP, ale może utrudnić automatyczne odnajdywanie instancji.

Sprawdzenie stanu w systemie Windows

Podstawową kontrolę można wykonać w narzędziu SQL Server Configuration Manager albo w standardowej konsoli usług. W PowerShellu dla instancji domyślnej przydatne jest polecenie Get-Service -Name MSSQLSERVER. Zwrócona wartość Status powinna wynosić Running. Analogiczne sprawdzenie usługi SQL Server Agent wymaga użycia nazwy SQLSERVERAGENT. Polecenie sc.exe query MSSQLSERVER pokazuje stan usługi oraz informacje o procesie usług systemowych. Dla instancji nazwanej trzeba podstawić rzeczywistą nazwę w formacie MSSQL$NazwaInstancji.

Wynik kontroli należy zestawić z konfiguracją uruchamiania usługi. Stan Stopped oznacza, że silnik nie działa, natomiast tryb uruchamiania „Ręczny” lub „Automatyczny” opisuje sposób startu, a nie bieżącą dostępność bazy. W SQL Server Configuration Manager można również sprawdzić konto używane przez usługę, skonfigurowane protokoły sieciowe oraz przypisane porty. Zmiana konta usługi poza tym narzędziem może doprowadzić do utraty wymaganych uprawnień do plików baz danych, kluczy szyfrowania lub katalogów systemowych.

Potwierdzenie działania silnika i połączeń

Po sprawdzeniu usługi trzeba wykonać rzeczywiste zapytanie do silnika. Dla lokalnej instancji domyślnej można użyć narzędzia sqlcmd z uwierzytelnianiem Windows: sqlcmd -S localhost -E -Q "SELECT @@SERVERNAME, SERVERPROPERTY('ProductVersion'), SERVERPROPERTY('Edition');". Poprawna odpowiedź potwierdza, że klient dotarł do SQL Server, uwierzytelnił się i otrzymał wynik zapytania. Dla instancji nazwanej parametr serwera powinien mieć postać localhost\NazwaInstancji, a przy połączeniu po konkretnym porcie można wskazać zapis tcp:localhost,Port.

Wewnątrz silnika można sprawdzić usługi widziane przez SQL Server za pomocą widoku dynamicznego sys.dm_server_services. Zapytanie SELECT servicename, status_desc, startup_type_desc, last_startup_time FROM sys.dm_server_services; pozwala rozróżnić usługę silnika, SQL Server Agent i inne składniki zarejestrowane dla danej instalacji. Wartość status_desc opisuje stan rozpoznany przez silnik, ale nie zastępuje testu połączenia aplikacyjnego. Aplikacja może nadal zgłaszać błąd, gdy używa innego serwera, portu, protokołu, konta lub nazwy instancji niż ta sprawdzona lokalnie.

Jeżeli usługa ma stan uruchomiony, lecz zapytanie nie odpowiada, należy sprawdzić dziennik błędów SQL Server oraz Podgląd zdarzeń systemu Windows. W dzienniku mogą wystąpić informacje o nieudanym otwarciu pliku bazy, braku dostępu do katalogu, zajętym porcie TCP, błędach inicjalizacji modułów albo oczekiwaniu na zakończenie odzyskiwania. Dla połączeń zdalnych trzeba dodatkowo potwierdzić, że protokół TCP/IP jest włączony w SQL Server Configuration Manager, instancja nasłuchuje na oczekiwanym porcie, a zapora systemowa nie odrzuca ruchu. Odrębnie należy interpretować błąd uwierzytelniania, timeout sieciowy i odmowę połączenia, ponieważ wskazują na różne przyczyny.

Diagnostyka po wykryciu nieprawidłowości

Jeżeli usługa zatrzymuje się natychmiast po uruchomieniu, nie należy ograniczać się do kolejnego polecenia startu. Najpierw trzeba odczytać komunikat z dziennika SQL Server i zdarzenia o identyfikatorach związanych z usługą w Podglądzie zdarzeń. Istotne są między innymi ścieżki do plików danych i dzienników transakcji, dostępność wolnego miejsca na woluminie oraz uprawnienia konta usługi do katalogów instalacyjnych. W przypadku instancji nazwanej należy zweryfikować właściwą nazwę usługi, ponieważ uruchomienie MSSQLSERVER nie uruchamia automatycznie instancji nazwanej.

Kontrola powinna kończyć się testem z tego samego środowiska, z którego korzysta aplikacja. Należy użyć identycznej nazwy hosta, nazwy instancji, portu i metody uwierzytelniania. Dopiero zgodność stanu usługi Windows, odpowiedzi na zapytanie SQL, konfiguracji protokołu TCP/IP i wpisów w dziennikach pozwala uznać weryfikację za zakończoną. W dokumentacji diagnostycznej warto zapisać czas sprawdzenia, nazwę instancji, wynik polecenia, kod błędu oraz źródło obserwacji. Dzięki temu można odróżnić chwilowy problem podczas startu od powtarzalnej awarii usługi lub błędnej konfiguracji klienta.