Awaria SQL Server Agent

Awaria SQL Server Agent to zdarzenie uniemożliwiające prawidłowe wykonywanie zaplanowanych zadań przez tę usługę.

Rola SQL Server Agent w wykonywaniu zadań

SQL Server Agent jest składnikiem Microsoft SQL Server odpowiedzialnym za automatyczne uruchamianie zadań administracyjnych i operacyjnych. Zadanie, czyli SQL Server Agent Job, składa się z jednego lub wielu kroków. Krok może wykonywać instrukcję Transact-SQL, procedurę składowaną, polecenie systemu operacyjnego, skrypt PowerShell albo operację właściwą dla jednego z obsługiwanych podsystemów. Uruchomienie może następować według harmonogramu, na żądanie, po wystąpieniu alertu lub w wyniku określonego zdarzenia.

Awaria SQL Server Agent nie musi oznaczać uszkodzenia samego silnika Database Engine. Usługa SQL Server Agent działa jako oddzielny składnik systemu Windows i korzysta między innymi z bazy systemowej msdb, w której przechowywane są definicje zadań, harmonogramy, historia wykonań, informacje o operatorach oraz konfiguracja alertów. Gdy usługa jest zatrzymana, wyłączona albo nie może prawidłowo połączyć się z instancją SQL Server, zaplanowane zadania nie zostaną uruchomione, nawet jeśli ręczne zapytania do silnika bazy danych działają poprawnie.

Objawy zatrzymania lub nieprawidłowej pracy usługi

Podstawowym objawem jest brak nowych wpisów w historii zadań mimo nadejścia terminu określonego w harmonogramie. W widoku SQL Server Agent w SQL Server Management Studio usługa może być oznaczona jako zatrzymana, a zadania mogą pozostawać w stanie oczekiwania. Jeżeli Agent działa, ale konkretny job kończy się błędem, w historii wykonania widoczny jest numer kroku, komunikat oraz czas rozpoczęcia i zakończenia. Należy odróżnić brak uruchomienia zadania od nieudanego wykonania jego kroku, ponieważ każda z tych sytuacji wskazuje na inną część konfiguracji.

Przyczyna może znajdować się na poziomie systemu Windows, połączenia z instancją, uprawnień albo samego zadania. Typowe przypadki obejmują zatrzymaną usługę SQL Server Agent, nieprawidłowe konto usługi, wygasłe lub zmienione dane uwierzytelniające, brak dostępu do bazy msdb, wyłączony harmonogram, niepoprawnie ustawioną datę rozpoczęcia harmonogramu oraz ograniczenie wynikające z warunku wykonania. Błąd może również wystąpić wtedy, gdy krok wymaga dostępu do systemu operacyjnego lub innego zasobu, a konto wykonawcze nie ma wymaganych uprawnień.

Sprawdzanie historii, harmonogramów i komunikatów błędów

Diagnostykę rozpoczyna się od ustalenia, czy problem dotyczy całej usługi, czy tylko wybranego zadania. W SQL Server Management Studio można sprawdzić stan SQL Server Agent, właściwości joba, przypisane harmonogramy, kolejność kroków, warunki przejścia między krokami oraz ustawienie reakcji po zakończeniu. W historii zadania trzeba porównać czas planowanego uruchomienia z rzeczywistym wpisem. Brak wpisu w oczekiwanym czasie sugeruje problem z usługą, harmonogramem albo warunkiem uruchomienia, natomiast wpis z komunikatem błędu wskazuje na problem w konkretnym kroku.

Przydatne informacje znajdują się także w dzienniku SQL Server Agent oraz w Podglądzie zdarzeń systemu Windows. Dziennik Agenta może wskazać nieudaną próbę połączenia z instancją, problem z inicjalizacją podsystemu, błąd odczytu konfiguracji lub odrzucenie operacji przez system. W bazie msdb informacje o zadaniach i ich historii udostępniają między innymi widoki dbo.sysjobs, dbo.sysjobsteps, dbo.sysjobschedules, dbo.sysjobhistory oraz dbo.sysjobactivity. Do odczytu należy używać konta posiadającego odpowiednie uprawnienia, ponieważ zakres widocznej historii zależy od członkostwa w rolach bazy msdb, takich jak SQLAgentReaderRole lub role o szerszym zakresie.

Przywrócenie wykonywania zadań po awarii

Usunięcie problemu wymaga najpierw potwierdzenia przyczyny, a dopiero potem zmiany konfiguracji. Jeżeli usługa nie działa, sprawdza się jej stan, sposób uruchamiania, konto usługi oraz komunikaty zapisane podczas startu. Nazwa usługi zależy od rodzaju instancji: dla instancji domyślnej jest to zwykle SQLSERVERAGENT, a dla instancji nazwanej stosowana jest forma SQLAgent$NazwaInstancji. Po uruchomieniu usługi należy potwierdzić, że Agent łączy się z właściwą instancją i że nowe wykonania pojawiają się w historii.

Jeżeli problem dotyczy joba, należy sprawdzić właściciela zadania, konto proxy używane przez dany podsystem, uprawnienia do baz i katalogów, zależności między krokami oraz ustawienia harmonogramu. Nie powinno się usuwać historii ani tworzyć kopii zadania przed zabezpieczeniem informacji o błędzie, ponieważ takie działania mogą utrudnić odtworzenie kolejności zdarzeń. Po zmianie konfiguracji wykonuje się kontrolne uruchomienie zadania i sprawdza wynik każdego kroku, wpis w historii, dziennik SQL Server Agent oraz ewentualny alert. Dopiero zgodność tych informacji potwierdza, że awaria została usunięta, a nie tylko ukryta przez ręczne wykonanie pojedynczego polecenia.