Systemowe zależności usług

Systemowe zależności usług określają kolejność uruchamiania komponentów powiązanych z SQL Server przy starcie systemu.

Rola zależności usług w uruchamianiu SQL Server

Systemowe zależności usług w środowisku Microsoft SQL Server są mechanizmem systemu Windows, który określa, czy wskazana usługa może zostać uruchomiona przed innymi usługami wymaganymi do jej działania. Informacja o zależności jest obsługiwana przez Service Control Manager, czyli Menedżera kontroli usług systemu Windows. Nie jest to ustawienie znajdujące się w samej bazie danych ani reguła definiująca kolejność wykonywania zapytań.

W typowej instalacji występuje kilka odrębnych usług SQL Server. Usługa aparatu baz danych dla instancji domyślnej ma nazwę systemową MSSQLSERVER, natomiast dla instancji nazwanej używany jest schemat MSSQL$NazwaInstancji. SQL Server Agent działa jako osobna usługa, odpowiednio SQLSERVERAGENT albo SQLAgent$NazwaInstancji. Zależność może dotyczyć konkretnej usługi, dlatego ustawienie dotyczące aparatu baz danych nie musi automatycznie obejmować agenta, SQL Server Browser ani innych składników instalacji.

Jak Windows interpretuje kolejność startu

Jeżeli usługa SQL Server ma zdefiniowaną zależność, Menedżer kontroli usług próbuje najpierw uruchomić wskazany składnik. Gdy usługa zależna nie wystartuje, zostanie zatrzymana albo nie osiągnie stanu umożliwiającego dalszą pracę, uruchomienie SQL Server może zostać odrzucone. Sama obecność usługi na liście systemowej nie oznacza jednak, że jej proces działa poprawnie. O wyniku decyduje stan usługi oraz rezultat inicjalizacji jej procesu.

Kolejność uruchamiania nie jest równoznaczna z gotowością bazy danych do przyjmowania połączeń. Usługa może znajdować się w stanie uruchamiania, podczas gdy aparat wykonuje odzyskiwanie baz po nieprawidłowym zamknięciu lub odtwarza pliki dziennika transakcji. W tym czasie klient może otrzymać błąd połączenia, mimo że Windows raportuje już rozpoczęcie pracy usługi. Z tego powodu zależności systemowe rozwiązują tylko część problemu i nie zastępują sprawdzania dziennika SQL Server oraz stanu konkretnej bazy.

Warto odróżnić zależność twardą od ustawień typu uruchomienia. Automatyczny start określa, czy system ma próbować uruchomić usługę podczas rozruchu. Start opóźniony przesuwa tę próbę na późniejszy etap. Uruchamianie wyzwalane przez zdarzenie pozwala aktywować usługę dopiero po wystąpieniu określonego warunku. Żadne z tych ustawień samo w sobie nie tworzy zależności pomiędzy usługami.

Odczyt i weryfikacja konfiguracji usługi

Konfigurację zależności można odczytać z poziomu systemu Windows, korzystając z narzędzia sc.exe. Dla instancji domyślnej polecenie sc.exe qc MSSQLSERVER pokazuje między innymi typ startu, konto usługi, ścieżkę programu oraz wartość oznaczającą zależności. Dla instancji nazwanej należy podać właściwą nazwę, na przykład sc.exe qc MSSQL$KSIĘGOWOŚĆ, przy czym w powłoce PowerShell znak dolara może wymagać odpowiedniego ujęcia w cudzysłów, aby nie został potraktowany jako odwołanie do zmiennej.

Informacje o bieżącym stanie można sprawdzić poleceniem sc.exe query MSSQLSERVER albo w konsoli Usługi pod nazwą wyświetlaną dla danej instancji. Przy analizie problemu należy porównać nazwę usługi, konto używane do jej uruchamiania, typ uruchomienia i listę zależności. Pomocne są również zdarzenia z dziennika System w Podglądzie zdarzeń oraz wpisy z dziennika ERRORLOG SQL Server. Komunikat o niemożności uruchomienia usługi zależnej wskazuje na warstwę Windows, natomiast błędy inicjalizacji bazy, plików lub uprawnień mogą pojawić się dopiero w logach samego SQL Server.

Zmiana zależności wymaga uprawnień administracyjnych i powinna być wykonywana z pełną świadomością skutków. Nieprawidłowo dodana zależność może stworzyć cykl albo uzależnić aparat baz danych od składnika, który nie jest niezbędny. W efekcie każda próba startu SQL Server będzie oczekiwała na usługę niepowiązaną funkcjonalnie z bazą. Przed modyfikacją należy zapisać aktualną konfigurację, ustalić rzeczywistą relację między usługami i sprawdzić zachowanie po kontrolowanym restarcie systemu.

Granice mechanizmu i diagnostyka awarii startu

SQL Server Browser nie jest ogólnym warunkiem uruchomienia aparatu baz danych. Browser pomaga klientom odnajdywać informacje o instancjach nazwanych, ale sam aparat może działać niezależnie od tej usługi, gdy połączenie korzysta z poprawnie określonego adresu, nazwy instancji lub portu. Podobnie SQL Server Agent nie jest wymagany do wykonywania podstawowych operacji aparatu baz danych. Jest potrzebny do funkcji realizowanych przez agenta, takich jak zaplanowane zadania, lecz jego start nie powinien być automatycznie traktowany jako warunek działania samej bazy.

Gdy usługa SQL Server nie uruchamia się po starcie Windows, diagnostykę należy rozpocząć od ustalenia dokładnej nazwy instancji i kodu błędu zwróconego przez system. Następnie sprawdza się, czy wymienione zależności istnieją, mają właściwy typ uruchomienia i przechodzą do stanu uruchomionego. Kolejny etap obejmuje analizę ERRORLOG, weryfikację ścieżek do plików baz danych, dostępności woluminów oraz uprawnień konta usługi. Sama zmiana kolejności startu nie naprawi brakującego pliku, niedostępnego dysku ani błędnej konfiguracji konta.

W zastosowaniach serwerowych modyfikacje tego rodzaju powinny być testowane w kontrolowanym oknie administracyjnym, ponieważ zmiana zależności może wpłynąć na dostępność aplikacji korzystających z bazy. Szczególnej uwagi wymaga odróżnienie problemu z usługą Windows od problemu z gotowością instancji SQL Server. Dopiero zestawienie stanu usług, zdarzeń systemowych, logu SQL Server i rzeczywistej próby połączenia pozwala określić, czy przyczyną jest zależność, opóźniony start, błąd procesu czy awaria zasobu używanego przez aparat baz danych.