SYS.DM_SERVER_SERVICES

sys.dm_server_services zwraca stan usług powiązanych z SQL Server, np. Agenta czy usług analitycznych.

Rola widoku sys.dm_server_services w SQL Server

sys.dm_server_services jest dynamicznym widokiem zarządzania dostępnym w Microsoft SQL Server. Zwraca informacje o usługach systemowych powiązanych z daną instalacją silnika, dzięki czemu administrator może sprawdzić ich bieżący stan bez otwierania przystawki Usługi systemu Windows. Widok może obejmować między innymi usługę głównego silnika SQL Server, SQL Server Agent, usługę SQL Server Browser oraz inne składniki zainstalowane razem z konkretną edycją i konfiguracją produktu. Zakres zwracanych wierszy zależy od obecności tych składników na komputerze.

Każdy wiersz opisuje jedną usługę. Widok nie służy do odczytu danych przechowywanych w tabelach i nie pokazuje sesji, zapytań ani blokad. Jego zadaniem jest przedstawienie informacji administracyjnych o procesie usługi, sposobie jej uruchamiania i powiązaniu z instalacją SQL Server. Jest to istotne podczas rozróżniania problemu z samym silnikiem bazy danych od problemu z usługą pomocniczą, która może być wymagana przez określoną funkcję SQL Server.

Kolumny opisujące usługę, proces i uruchamianie

Najczęściej wykorzystywane kolumny to servicename, startup_type_desc i status_desc. Pierwsza zawiera nazwę usługi, druga opisuje sposób jej uruchamiania, a trzecia przedstawia aktualny status raportowany przez system. W zależności od wersji i konfiguracji można spotkać wartości wskazujące na uruchamianie automatyczne, ręczne albo wyłączone oraz stany takie jak uruchomiona, zatrzymana lub nieokreślona. Wartości liczbowe startup_type i status są odpowiednikami technicznymi opisów tekstowych.

Kolumna process_id wskazuje identyfikator procesu systemu Windows przypisany usłudze. Może on pomóc połączyć wpis z narzędziami takimi jak Menedżer zadań, Monitor zasobów lub polecenia diagnostyczne systemu operacyjnego. last_startup_time informuje o ostatnim uruchomieniu usługi, natomiast service_account pokazuje konto, pod którym działa. filename wskazuje plik wykonywalny usługi. Przy instalacji klastrowej znaczenie mają również is_clustered oraz cluster_nodename, ponieważ pozwalają rozpoznać, czy usługa jest częścią konfiguracji klastrowej i z którym węzłem jest związana.

Przykładowe zapytanie może ograniczyć wynik do danych przydatnych podczas pierwszej kontroli:

SELECT servicename, startup_type_desc, status_desc, process_id, last_startup_time, service_account, is_clustered, cluster_nodename, filename FROM sys.dm_server_services;

Interpretacja wyników i ograniczenia diagnostyczne

Sam wpis w sys.dm_server_services nie jest dowodem, że dana funkcja aplikacyjna działa poprawnie. Status „uruchomiona” oznacza, że system Windows zgłasza aktywną usługę, ale nie potwierdza poprawnej komunikacji z silnikiem, dostępności portu, prawidłowych uprawnień ani sprawności konfiguracji. Analogicznie usługa zatrzymana może być błędem, jeżeli jest wymagana przez używaną funkcję, albo stanem prawidłowym, gdy administrator świadomie jej nie włączył.

Przy analizie należy porównywać wynik z rolą konkretnej usługi. Zatrzymany SQL Server Agent może uniemożliwić wykonywanie zaplanowanych zadań, alertów i harmonogramów, ale nie musi zatrzymywać samego silnika baz danych. Zatrzymany SQL Server Browser może wpływać na odnajdywanie nazwanych instancji przez klientów korzystających z mechanizmu SQL Server Browser, lecz nie oznacza automatycznie uszkodzenia instancji. Wnioski trzeba potwierdzić w dzienniku błędów SQL Server, Podglądzie zdarzeń Windows oraz konfiguracji sieciowej.

Dostęp do dynamicznych widoków zarządzania jest kontrolowany uprawnieniami serwera. W SQL Server 2019 i wcześniejszych wersjach odczyt informacji z wielu DMV wymaga uprawnienia VIEW SERVER STATE. W SQL Server 2022 część informacji diagnostycznych podlega uprawnieniu VIEW SERVER PERFORMANCE STATE. Rzeczywiste wymaganie należy sprawdzić dla używanej wersji produktu i konkretnego widoku. Brak uprawnienia może skutkować błędem dostępu, dlatego nie należy interpretować pustego lub niepełnego wyniku jako potwierdzenia, że usług nie ma.

Praktyczne użycie podczas kontroli instalacji SQL Server

Kontrolę warto rozpocząć od odczytu nazwy usługi, statusu, typu startu i czasu ostatniego uruchomienia. Jeżeli czas startu zmienił się niedawno, można zestawić go z chwilą restartu serwera, wdrożeniem aktualizacji albo wystąpieniem zgłoszonego problemu. Identyfikator procesu pomaga sprawdzić, czy obserwowany proces odpowiada usłudze wskazanej przez SQL Server. Konto usługi może natomiast wyjaśnić błędy związane z dostępem do zasobów systemowych, ale sam jego odczyt nie przesądza o poprawności konfiguracji.

W środowisku z wieloma instancjami trzeba pamiętać, że nazwy usług mogą zawierać oznaczenie konkretnej instancji, a wynik należy odczytywać w kontekście serwera, z którego wykonano zapytanie. Nie należy zakładać, że identyczny zestaw wierszy pojawi się na każdym komputerze. Edycja SQL Server, zainstalowane składniki, tryb pracy klastra i wybrane funkcje wpływają na to, jakie usługi są widoczne. Do automatycznego monitorowania można zapisywać wybrane kolumny w tabeli kontrolnej i porównywać kolejne odczyty, lecz taki mechanizm powinien uwzględniać planowane restarty oraz usługi celowo skonfigurowane jako ręczne.

Podczas serwisowej diagnostyki SQL Server wynik tego widoku powinien być traktowany jako jeden z elementów ścieżki analitycznej. Najpierw ustala się, która funkcja nie działa, następnie sprawdza odpowiadającą jej usługę, logi, zależności i konfigurację instancji. Dopiero zgodność tych informacji pozwala sformułować wiarygodną przyczynę, na przykład zatrzymanie wymaganej usługi po restarcie albo nieudane uruchomienie procesu wskazane przez status i czas ostatniego startu.