Dlaczego job SQL Server Agent zakończył się błędem? Diagnostyka krok po kroku
Komunikat „The job failed” nie jest diagnozą.
Prawdziwa diagnostyka zaczyna się od ustalenia, który krok zawiódł jako pierwszy, w jakim kontekście bezpieczeństwa działał i co zmieniło się od ostatniego poprawnego wykonania.
Krok 1. Ustal pierwszy błędny krok
| |
Krok 2. Sprawdź konfigurację kroku
| |
Krok 3. Ustal kontekst bezpieczeństwa
| |
Popularny przypadek brzmi:
Skrypt działa ręcznie, ale nie działa jako job.
Najczęściej oznacza to różnicę w koncie, profilu PowerShell, ścieżkach, zmiennych środowiskowych albo dostępie do udziału sieciowego.
Krok 4. Sprawdź właściciela i harmonogram
| |
Właścicielem joba nie powinno być przypadkowe konto pracownika.
Krok 5. Sprawdź logi właściwego subsystemu
Dla T-SQL analizuj historię joba, SQL Server Error Log i Extended Events.
Dla PowerShell zapisuj pełny wyjątek, kod wyjścia i plik logu.
Dla SSIS korzystaj z raportów SSISDB.
Dla CmdExec sprawdzaj stdout, stderr, kod zakończenia oraz konto wykonawcze.
Krok 6. Porównaj z ostatnim sukcesem
Sprawdź:
- wdrożenia,
- zmianę hasła,
- patching,
- failover,
- zmianę DNS,
- zmianę ścieżki,
- brak miejsca,
- zmianę uprawnień,
- zmianę parametrów.
Podsumowanie
Błąd joba należy analizować warstwowo: wykonanie, krok, subsystem, bezpieczeństwo, harmonogram i zależności.
Spokojny DBA nie zatrzymuje się na komunikacie „job failed”.
Dociera do pierwszej technicznej przyczyny i zamienia incydent w poprawę procesu.