Historia wykonania zadania to zestawienie wcześniejszych uruchomień danego zadania SQL Server Agent wraz z ich wynikiem.
Jak SQL Server Agent zapisuje historię wykonania zadania
Historia wykonania zadania w SQL Server Agent jest rejestrem wcześniejszych uruchomień joba, czyli obiektu definiującego zaplanowane czynności administracyjne lub przetwarzające dane. Informacje są przechowywane w bazie systemowej msdb, przede wszystkim w tabeli dbo.sysjobhistory. Każdy rekord opisuje zakończenie zadania albo wykonanie jednego z jego kroków. Dzięki temu można ustalić, czy job zakończył się powodzeniem, kiedy został uruchomiony, ile trwał oraz jaki komunikat zwrócił SQL Server Agent.
W tabeli dbo.sysjobhistory kolumna job_id identyfikuje zadanie, a step_id wskazuje konkretny krok. Wartość step_id = 0 oznacza rekord podsumowania całego uruchomienia joba, natomiast wartości dodatnie odnoszą się do poszczególnych kroków zdefiniowanych w dbo.sysjobsteps. Nazwę zadania można powiązać z tabelą dbo.sysjobs. Takie rozdzielenie pozwala odróżnić awarię całego przebiegu od problemu występującego tylko w jednym poleceniu, procedurze lub kroku systemu operacyjnego.
Interpretacja wyniku, czasu i komunikatu
Najważniejszą informacją w historii jest wartość run_status. W SQL Server Agent wartość 1 oznacza sukces, 0 błąd, 2 ponowienie kroku, 3 anulowanie, a 4 trwające wykonanie. W praktyce do oceny zakończonych uruchomień najczęściej analizuje się rekordy z step_id = 0 oraz statusami sukcesu lub błędu. Sam status podsumowania nie zawsze wskazuje przyczynę problemu, dlatego po wykryciu niepowodzenia należy sprawdzić również rekordy kroków tego samego joba.
Kolumny run_date, run_time i run_duration są przechowywane jako liczby. Data ma format YYYYMMDD, a czas rozpoczęcia i czas trwania mają format HHMMSS. Przykładowo wartość 20260826 oznacza 26 sierpnia 2026 roku, a 013045 w kolumnie czasu oznacza godzinę 01:30:45. Czas trwania nie jest typem time; przy długich zadaniach trzeba poprawnie obsłużyć również wartości przekraczające 24 godziny. Kolumna message może zawierać komunikat SQL Server Agent, wynik polecenia albo opis błędu zapisany podczas działania kroku.
Zapytanie do analizy ostatnich uruchomień
Podstawową analizę można wykonać bezpośrednio w bazie msdb, łącząc historię z nazwą joba. Przykładowe zapytanie zwracające ostatnie podsumowania uruchomień wygląda następująco:
USE msdb;
SELECT TOP (50)
j.name AS job_name,
h.run_status,
h.run_date,
h.run_time,
h.run_duration,
h.message
FROM dbo.sysjobhistory AS h
INNER JOIN dbo.sysjobs AS j ON j.job_id = h.job_id
WHERE h.step_id = 0
ORDER BY h.instance_id DESC; Taki wynik pokazuje kolejność zapisanych instancji, ale wartości liczbowe dotyczące daty, czasu i długości trwania mogą wymagać dodatkowego formatowania przed prezentacją w raporcie. Do sprawdzania historii konkretnego joba można również użyć procedury systemowej msdb.dbo.sp_help_jobhistory, podając nazwę lub identyfikator zadania.
Historia pozwala wykrywać powtarzalne wzorce, takie jak regularne błędy połączenia, przekroczenie czasu działania, zatrzymanie zadania po nieudanym kroku albo zwiększanie się czasu trwania kolejnych uruchomień. Jeżeli job ma skonfigurowane ponawianie kroku, wpis z run_status = 2 należy interpretować razem z ustawieniami retry w dbo.sysjobsteps. Ważne jest także sprawdzenie, czy historia nie została wcześniej ograniczona przez konfigurację przechowywania logów. Brak starszych rekordów nie dowodzi więc, że zadanie nie było uruchamiane.
Historia jako materiał do diagnostyki działania joba
Analiza historii wykonania zadania powinna obejmować zarówno wynik końcowy, jak i kolejność kroków. Job może zakończyć się błędem dlatego, że wcześniejszy krok zwrócił niepowodzenie, przekazał nieoczekiwany kod wyjścia albo skierował przepływ do innego kroku. Warto porównać step_id, komunikaty oraz czasy uruchomienia z definicją w dbo.sysjobsteps i harmonogramem zapisanym w obiektach SQL Server Agent. Pozwala to rozdzielić błąd samego polecenia od problemu z konfiguracją przepływu joba.
Przy diagnostyce trzeba pamiętać, że historia SQL Server Agent nie jest pełnym dziennikiem wszystkich zdarzeń silnika SQL Server. Nie zastępuje error logu SQL Server, dziennika SQL Server Agent ani logów tworzonych przez aplikację lub skrypt uruchamiany w ramach zadania. Jeżeli w historii znajduje się tylko ogólny komunikat, dalsze ustalenia wymagają sprawdzenia uprawnień właściciela joba, konta proxy, zależności między krokami, dostępności plików lub zasobów oraz rzeczywistego logu użytego przez dane polecenie. Prawidłowo odczytana historia jest więc punktem odniesienia do odtworzenia przebiegu zadania, a nie jedynym źródłem diagnozy.
