Widok sysjobhistory

sysjobhistory zawiera historię wykonań zadań SQL Server Agent wraz z ich statusem.

Dziennik wykonań zadań agenta

Tabela mieści się w bazie msdb i zapisuje wynik każdego uruchomienia zadania SQL Server Agenta wraz z rozbiciem na kroki. Kluczowe kolumny to job_id wskazujące zadanie, step_id i step_name identyfikujące krok, run_status z wynikiem, oraz run_date, run_time i run_duration opisujące moment i czas trwania. Kolumna message przechowuje pełny komunikat zwrócony przez krok, łącznie z treścią błędu silnika. Wiersz o numerze kroku równym zero podsumowuje całe zadanie - bez tego rozróżnienia raport z historii pokazuje każde uruchomienie kilkukrotnie.

Nietypowy zapis czasu i statusów

Data i godzina nie są zapisane w typie daty, tylko jako liczby całkowite: data w postaci rok, miesiąc i dzień sklejone w osiem cyfr, godzina jako sześć cyfr bez wiodącego zera. Czas trwania ma tę samą formę, więc wykonanie trwające godzinę i dwie minuty widnieje jako liczba, którą trzeba rozłożyć na części, żeby otrzymać sekundy - proste sortowanie po tej kolumnie daje wynik pozornie sensowny, ale mylący. Do przeliczenia służy funkcja systemowa msdb.dbo.agent_datetime, łącząca datę z godziną w jedną wartość. Status kodowany jest liczbą: zero to niepowodzenie, jedynka sukces, dwójka ponowienie, trójka anulowanie przez operatora. Historię czyta się razem z tabelą sysjobs, żeby zamiast identyfikatorów zobaczyć nazwy zadań, oraz z sysjobsteps dla definicji kroków.

Znikająca historia i pułapki w raportach

Agent ogranicza rozmiar dziennika dwoma ustawieniami - maksymalną liczbą wierszy w całej tabeli i maksymalną liczbą wierszy przypadającą na jedno zadanie. Po przekroczeniu progu najstarsze wpisy są usuwane bez ostrzeżenia, więc zadanie uruchamiane co pięć minut potrafi wyprzeć z historii ślad po nocnej kopii bezpieczeństwa sprzed tygodnia. Do porządkowania służy procedura sp_purge_jobhistory, a przy odtwarzaniu bazy msdb historia znika w całości. Kolumna message ma ograniczoną długość, więc obszerne komunikaty błędów bywają przycięte w najciekawszym miejscu - pełną treść trzeba wtedy szukać w dzienniku błędów instancji albo w pliku wyjściowym kroku. Zadanie zakończone sukcesem nie oznacza też, że zrobiło to, co miało: krok wykonujący pakiet zewnętrzny zwraca sukces, jeśli sam pakiet nie zgłosił błędu, nawet gdy przetworzył zero rekordów.

Kontrola kopii zapasowych, o której nikt nie pamięta

W firmach handlowych najczęstszy scenariusz wygląda tak samo: zadanie kopii bezpieczeństwa przestało działać kilka miesięcy temu, nikt tego nie zauważył, a odkrycie następuje w dniu awarii dysku. Przeglądamy historię zadań, ustawiamy powiadomienia o niepowodzeniu na adres administratora i weryfikujemy, czy pliki kopii faktycznie powstają i dają się odtworzyć. Przy bazach systemów sprzedażowych sprawdzamy również rozmiar dziennika transakcji i harmonogram jego obcinania - to druga najczęstsza przyczyna nocnych telefonów o zatrzymanej sprzedaży.