SQL Server Agent nie uruchamia się

Nieuruchamiający się SQL Server Agent wymaga sprawdzenia konta usługi i jego uprawnień.

SQL Server Agent nie uruchamia się – na czym polega problem

SQL Server Agent jest usługą systemu Windows odpowiedzialną za wykonywanie zadań zaplanowanych w środowisku Microsoft SQL Server. Może uruchamiać kopie zapasowe, konserwację baz danych, wysyłanie powiadomień, importy i eksporty danych, a także inne operacje wykonywane cyklicznie lub po wystąpieniu określonego zdarzenia. Gdy usługa SQL Server Agent nie uruchamia się, zadania zapisane w harmonogramie nie zostaną wykonane, nawet jeśli sama instancja SQL Server działa prawidłowo.

Usterka nie zawsze oznacza awarię bazy danych. Często dotyczy konfiguracji usługi, konta systemowego, sposobu logowania albo zależności pomiędzy składnikami. Warto rozdzielić kilka sytuacji: usługa może być zatrzymana, może kończyć pracę natychmiast po próbie startu, może być wyłączona w konfiguracji albo może działać, lecz nie wykonywać konkretnych zadań. Każdy z tych przypadków wymaga nieco innego sprawdzenia.

Na początku należy ustalić, czy problem dotyczy właściwej instancji. Na jednym komputerze może działać więcej niż jedna instancja SQL Server, a każda z nich ma własną usługę SQL Server Agent. Próba uruchomienia agenta przypisanego do innej instancji nie rozwiąże problemu i może prowadzić do błędnej oceny sytuacji. Istotne jest również sprawdzenie wersji oraz edycji SQL Server, ponieważ nie wszystkie wydania zawierają funkcję SQL Server Agent.

SQL Server Agent a konto usługi i uprawnienia systemowe

Jedną z najczęstszych przyczyn zatrzymania agenta jest nieprawidłowo skonfigurowane konto usługi. Usługa działa w określonym kontekście użytkownika, dlatego zmiana hasła, wygaśnięcie hasła, zablokowanie konta albo odebranie prawa do logowania jako usługa może uniemożliwić jej start. Taki problem często pojawia się po zmianie polityki bezpieczeństwa, odtworzeniu systemu z kopii lub modyfikacji kont używanych przez administratorów.

Właściwe ustawienia można sprawdzić w SQL Server Configuration Manager, a podstawowe informacje o stanie usługi także w konsoli Usługi systemu Windows. Należy zweryfikować nazwę konta, typ uruchamiania oraz sposób logowania. Jeżeli hasło zapisane dla usługi jest nieaktualne, trzeba zaktualizować je zgodnie z zasadami obowiązującymi w danym środowisku. Samo ustawienie automatycznego startu nie wystarczy, jeżeli konto nie ma wymaganych praw albo system odrzuca dane uwierzytelniające.

Nie powinno się przyznawać szerokich uprawnień bez potrzeby. Bezpieczniejsze jest ustalenie, jakie operacje mają być wykonywane przez agenta, a następnie nadanie wyłącznie praw koniecznych do ich realizacji. Zadania korzystające z udziałów sieciowych, katalogów roboczych lub zewnętrznych źródeł danych mogą wymagać osobnych uprawnień. Konto usługi może mieć dostęp do samego SQL Server, ale nie mieć praw do wskazanego folderu albo zasobu sieciowego.

Po zmianie konta usługi trzeba sprawdzić także poświadczenia używane przez zadania i mechanizmy proxy. Agent może uruchamiać zadania w innym kontekście niż ten, w którym sama usługa została uruchomiona. W rezultacie agent może się włączyć, ale określone zadanie nadal będzie kończyć się błędem. Rozdzielenie problemu startu usługi od problemu wykonania zadania ułatwia znalezienie właściwej przyczyny.

SQL Server Agent nie startuje po zmianie konfiguracji

Jeżeli SQL Server Agent nie uruchamia się po aktualizacji systemu, zmianie nazwy komputera lub modyfikacji konfiguracji SQL Server, należy przeanalizować kolejność zdarzeń. Najbardziej pomocne są komunikaty zapisane w dzienniku SQL Server Agent, dzienniku błędów SQL Server oraz Podglądzie zdarzeń Windows. Wpisy z dokładną godziną próby uruchomienia pozwalają powiązać awarię z konkretną zmianą.

W komunikatach mogą pojawić się informacje o błędnym haśle, braku prawa do logowania, niedostępności instancji, braku połączenia z bazą systemową msdb albo problemie z plikiem konfiguracyjnym. Nie należy ograniczać się do samego kodu błędu. Znaczenie ma również tekst towarzyszący, nazwa usługi, identyfikator instancji oraz moment wystąpienia problemu.

Trzeba sprawdzić, czy podstawowa usługa SQL Server działa i przyjmuje połączenia. Agent korzysta z niej podczas inicjalizacji, dlatego zatrzymana lub uszkodzona instancja może uniemożliwić poprawny start. Warto zweryfikować także zależności usługi, wolne miejsce na dysku, dostęp do katalogów z plikami dziennika oraz możliwość zapisu w lokalizacjach wskazanych w konfiguracji. Brak miejsca lub odmowa zapisu może powodować natychmiastowe zakończenie procesu.

W niektórych przypadkach przyczyną bywa niezgodność ustawień po przeniesieniu baz systemowych albo odtworzeniu ich z kopii. SQL Server Agent przechowuje wiele informacji o zadaniach, harmonogramach, operatorach i alertach w bazie msdb. Jeżeli baza jest niedostępna, ma nieprawidłowy stan lub jej struktura nie odpowiada wersji silnika, agent może nie zakończyć procesu inicjalizacji. Wtedy potrzebne jest porównanie komunikatów z dziennika, stanu bazy oraz wersji zainstalowanych składników.

Różnicę między usługą wyłączoną a usługą niesprawną można ustalić już na etapie ustawień startowych. Wyłączony typ uruchamiania oznacza celową blokadę startu przez system. Z kolei błąd pojawiający się przy ręcznym uruchomieniu wskazuje na problem konfiguracyjny, uprawnienia, zależność lub komunikację z instancją.

SQL Server Agent i porównanie z innymi mechanizmami harmonogramu

SQL Server Agent nie jest jedynym sposobem uruchamiania operacji cyklicznych. W prostych zastosowaniach można spotkać Harmonogram zadań Windows, skrypty uruchamiane ręcznie albo narzędzia dostarczane przez system kopii zapasowych. Różnica polega na tym, że SQL Server Agent jest bezpośrednio powiązany z SQL Server i przechowuje zadania, harmonogramy, historię wykonań oraz informacje o alertach w środowisku bazodanowym.

Harmonogram Windows może uruchomić polecenie lub skrypt, lecz nie zapewnia takiego samego modelu kontroli nad krokami zadania, historią oraz reakcją na błędy związane z SQL Server. Z drugiej strony jest mniej zależny od stanu samego agenta. Jeżeli awaria dotyczy wyłącznie SQL Server Agent, zadanie skonfigurowane w Harmonogramie Windows może nadal działać, choć nie zawsze będzie dobrym zamiennikiem. Takie obejście powinno być traktowane jako rozwiązanie tymczasowe, ponieważ może utrudnić centralne zarządzanie i ocenę wyników.

Ważne jest także odróżnienie problemu z uruchomieniem usługi od problemu z harmonogramem. Agent może pracować, ale zadanie może być wyłączone, przypisane do nieaktywnego harmonogramu, ustawione dla niewłaściwej instancji albo zatrzymywane przez błąd jednego z kroków. W historii zadania należy sprawdzić status, czas rozpoczęcia, czas zakończenia, komunikat zwrotny oraz konto użyte do wykonania. Dopiero taki przegląd pozwala stwierdzić, czy naprawy wymaga usługa, konfiguracja zadania, czy dostęp do zasobu wykorzystywanego przez zadanie.

Porównanie tych mechanizmów jest przydatne również przy planowaniu kopii zapasowych. Sama obecność harmonogramu nie daje pewności, że kopia została wykonana poprawnie. Należy kontrolować wynik operacji, możliwość odczytu utworzonych plików oraz dostępne miejsce. Po przywróceniu działania agenta warto przejrzeć historię zadań i potwierdzić wykonanie kilku cykli, zamiast uznawać problem za rozwiązany wyłącznie na podstawie zmiany statusu usługi.

SQL Server Agent – typowe objawy i praktyczne wskazówki

• Jeżeli przy ręcznym uruchomieniu pojawia się odmowa logowania, należy sprawdzić konto usługi, hasło, blokadę konta oraz prawo do logowania jako usługa.
• Jeżeli agent zatrzymuje się zaraz po starcie, trzeba przejrzeć dziennik agenta, dziennik SQL Server i Podgląd zdarzeń Windows z tego samego przedziału czasu.
• Jeżeli usługa działa, ale zadania się nie wykonują, należy skontrolować aktywność harmonogramu, kroki zadania, poświadczenia, proxy i historię wykonania.
• Jeżeli problem pojawił się po aktualizacji, warto sprawdzić zgodność wersji składników, stan bazy msdb oraz komunikaty zapisane podczas pierwszego uruchomienia po aktualizacji.
• Jeżeli zadanie korzysta z plików lub udziałów sieciowych, trzeba zweryfikować prawa konta do odczytu i zapisu w konkretnych lokalizacjach.
• Jeżeli występuje brak miejsca, należy sprawdzić dysk z plikami danych, logami i katalogami roboczymi, ponieważ agent może nie zapisać dziennika albo wyniku zadania.

Przed zmianą ustawień warto zapisać aktualną konfigurację i zanotować dokładny komunikat błędu. Pochopna zmiana konta albo usunięcie zadania może utrudnić późniejszą analizę. Dobrą praktyką jest wykonywanie zmian pojedynczo, a następnie ponowienie próby startu i sprawdzenie dzienników. Dzięki temu można ustalić, która modyfikacja przyniosła skutek.

Nie zaleca się kasowania plików dziennika ani resetowania całej konfiguracji bez ustalenia przyczyny. Historia błędów może być potrzebna do wykrycia powtarzalnego problemu, szczególnie gdy agent uruchamia się tylko okresowo albo zatrzymuje się po restarcie komputera. Warto również sprawdzić, czy problem występuje po każdym ponownym uruchomieniu systemu, czy tylko po ręcznej zmianie stanu usługi.

SQL Server Agent nie uruchamia się – kiedy zgłosić problem

Do sprawdzenia przez specjalistę warto zgłosić problem wtedy, gdy podstawowe odczytanie statusu usługi i dzienników nie wskazuje jednoznacznej przyczyny, gdy błąd powraca po restarcie albo gdy agent jest potrzebny do kopii zapasowych i innych zadań wykonywanych bez nadzoru. Szczególnej ostrożności wymagają sytuacje, w których zmiana konta usługi może wpłynąć na dostęp do baz, plików lub innych zasobów.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się diagnozowaniem problemów z komputerami i oprogramowaniem, a naprawy z reguły realizowane są do 3 dni roboczych. Przed rozpoczęciem prac można przygotować nazwę instancji, wersję SQL Server, godzinę wystąpienia problemu, treść komunikatu oraz informację o ostatnich zmianach w systemie. Takie dane ułatwiają odtworzenie sytuacji i ograniczają ryzyko przypadkowej modyfikacji działających ustawień.

Po usunięciu przyczyny należy wykonać kontrolę końcową: uruchomić usługę, sprawdzić jej stan po ponownym uruchomieniu systemu, wykonać testowe zadanie i przejrzeć historię wykonania. Jeżeli agent odpowiada za kopie zapasowe, dodatkowo trzeba potwierdzić istnienie poprawnego pliku oraz możliwość jego odczytu. Dopiero pozytywny wynik tych czynności daje podstawę do uznania, że problem został usunięty, a nie tylko chwilowo ukryty.