Logi wykonania zadań

Logi wykonania zadań to historia uruchomień zadań SQL Server Agent wraz z ich statusem i komunikatami błędów.

Co zawiera historia uruchomień SQL Server Agent

Logi wykonania zadań w SQL Server Agent są przede wszystkim zapisami historii przechowywanymi w bazie systemowej msdb. Każdy wpis może opisywać całe zadanie albo konkretny krok jego wykonania. W historii znajdują się między innymi nazwa zadania, identyfikator kroku, data i godzina rozpoczęcia, czas trwania, kod statusu oraz komunikat wygenerowany przez SQL Server Agent lub wykonywany krok. Nie jest to jeden uniwersalny plik tekstowy, lecz zestaw danych utrzymywanych przez komponent agenta.

W tabeli msdb.dbo.sysjobhistory wpis z wartością step_id = 0 reprezentuje wynik całego zadania, natomiast wartości większe od zera odnoszą się do poszczególnych kroków. Kolumna run_status określa stan wykonania: 0 oznacza niepowodzenie, 1 powodzenie, 2 ponowienie kroku, 3 anulowanie, a 4 stan trwającego wykonania. Data i czas są przechowywane w polach liczbowych run_date i run_time, a długość wykonania w run_duration, dlatego przy analizie trzeba je poprawnie przekształcić do czytelnego formatu.

Rozróżnienie wyniku zadania od błędu pojedynczego kroku

SQL Server Agent wykonuje zadanie według zdefiniowanej kolejności kroków. Pojedynczy krok może uruchamiać instrukcję Transact-SQL, pakiet usług SSIS, polecenie systemowe albo inny typ akcji dostępny w konfiguracji agenta. Historia kroku pokazuje, czy właśnie ta operacja zakończyła się powodzeniem, ale wynik całego zadania jest zapisywany osobno. Dzięki temu można odróżnić sytuację, w której pierwszy krok wykonał się poprawnie, od późniejszego kroku zakończonego błędem.

W praktyce sam status zadania nie zawsze wskazuje dokładną przyczynę problemu. Istotna jest kolumna message, ponieważ może zawierać treść błędu zwróconą przez silnik SQL Server, informację o liczbie przetworzonych wierszy, komunikat o ponowieniu lub opis anulowania. Należy także sprawdzić kolumnę retries_attempted oraz ustawienia przejścia do następnego kroku. Jeżeli krok ma skonfigurowane ponowienia, końcowy wpis zadania może pojawić się dopiero po kilku próbach, a wcześniejsze rekordy ze statusem ponowienia wyjaśniają opóźnienie i rzeczywistą sekwencję zdarzeń.

Zapytania i widoki przydatne podczas analizy

Do odczytu historii można wykorzystać procedurę systemową msdb.dbo.sp_help_jobhistory, która zwraca informacje o wykonaniach zadań, albo bezpośrednio odczytać odpowiednie rekordy z msdb.dbo.sysjobhistory. Nazwę zadania łączy się z tabelą msdb.dbo.sysjobs przez kolumnę job_id. Takie połączenie pozwala filtrować historię po nazwie zadania, a nie tylko po technicznym identyfikatorze. W raportach warto sortować dane według daty i czasu wykonania oraz ograniczać zakres do okresu, w którym wystąpił problem.

Historia zakończonych wykonań nie pokazuje pełnego stanu zadania uruchomionego w tej chwili. Do obserwowania bieżącej aktywności służy tabela msdb.dbo.sysjobactivity. Zawiera ona między innymi czas żądania uruchomienia, czas rozpoczęcia oraz czas zakończenia wykonania. Jeżeli zadanie nie ma jeszcze wpisu końcowego w sysjobhistory, zestawienie tych danych pomaga rozpoznać, czy zadanie nadal działa, czeka na zasób, zostało przerwane, czy agent nie zarejestrował prawidłowego zakończenia. Przy analizie trzeba uwzględnić identyfikator sesji SQL Server Agent, ponieważ tabela aktywności może przechowywać informacje z więcej niż jednej sesji.

Retencja historii i wykorzystanie logów w serwisowaniu

Liczba przechowywanych wpisów historii SQL Server Agent jest ograniczana przez konfigurację historii zadań. SQL Server Agent może usuwać starsze rekordy globalnie albo według limitu przypisanego do pojedynczego zadania. Z tego powodu brak dawnego wpisu nie musi oznaczać, że zadanie nigdy się nie uruchomiło. Przed wyciągnięciem wniosków należy sprawdzić zakres dat, ustawienia retencji oraz to, czy historia nie została ręcznie wyczyszczona. Osobno należy rozpatrywać dziennik SQL Server Agent, który może zawierać komunikaty dotyczące pracy samej usługi agenta, na przykład problemów z uruchomieniem lub komunikacją.

Podczas diagnostyki komputera pełniącego rolę hosta SQL Server warto zabezpieczyć kopię odpowiednich rekordów wraz z nazwą zadania, numerem kroku, znacznikiem czasu i pełnym komunikatem. Następnie można porównać nieudane wykonanie z ostatnim poprawnym przebiegiem, sprawdzić zmianę czasu trwania oraz ustalić, czy problem dotyczył konkretnego kroku, harmonogramu, uprawnień konta uruchamiającego czy niedostępnego zasobu. Taka analiza logów pozwala powiązać objaw z konkretnym zdarzeniem w systemie i ułatwia naprawę komputera, konfiguracji SQL Server lub zależnego podzespołu bez opierania diagnozy wyłącznie na ogólnym komunikacie o niepowodzeniu.