Procedura automatyczna (job)

Zadanie automatyczne to zaplanowana jednostka pracy SQL Server Agent wykonywana bez udziału administratora.

Job w SQL Server Agent: zaplanowana jednostka pracy

Procedura automatyczna, określana w SQL Server Agent jako job, jest obiektem opisującym czynności wykonywane według ustalonego harmonogramu albo uruchamiane przez zdarzenie. Job może zawierać jeden lub więcej kroków, a każdy krok ma własny typ działania, polecenie, bazę docelową, sposób obsługi sukcesu i sposób obsługi błędu. W środowisku Microsoft SQL Server takie zadanie może między innymi wykonywać instrukcje Transact-SQL, uruchamiać pakiet Integration Services, wywoływać polecenie systemu operacyjnego albo korzystać z innych podsystemów obsługiwanych przez SQL Server Agent.

Sam job nie jest pojedynczym zapytaniem zapisanym w bazie użytkownika. SQL Server Agent przechowuje jego definicję, kroki, harmonogramy, właściciela, ustawienia powiadomień i informacje o wykonaniach w bazie msdb. Usługa SQL Server Agent musi działać, aby zadania uruchamiane według harmonogramu były wykonywane. Jeżeli usługa jest zatrzymana, zaplanowany job nie rozpocznie się w tym czasie automatycznie; po ponownym uruchomieniu usługi należy sprawdzić historię i konfigurację, ponieważ zachowanie zaległego uruchomienia zależy od ustawień oraz wersji i sposobu skonfigurowania środowiska.

Kroki, harmonogram i przepływ wykonania

W typowym jobie pierwszy krok może sprawdzać warunki wstępne, drugi wykonywać właściwą operację, a następny zapisywać wynik lub wysyłać powiadomienie. Każdy krok ma numer oraz nazwę. Dla kroku można określić, co ma się wydarzyć po sukcesie: przejście do następnego kroku, zakończenie zadania jako zakończonego powodzeniem albo przejście do wskazanego numeru kroku. Analogicznie błąd może zakończyć job niepowodzeniem, przejść do kolejnego kroku albo skierować wykonanie do innego miejsca. Błędne ustawienie tych przejść może spowodować, że zadanie zostanie oznaczone jako zakończone mimo pominięcia istotnej operacji.

Harmonogram SQL Server Agent określa częstotliwość uruchamiania, na przykład jednorazowo, codziennie, co tydzień albo przy określonej częstotliwości w ciągu dnia. Harmonogram może być przypisany do jednego lub wielu jobów. Oprócz harmonogramu czasowego SQL Server Agent obsługuje uruchamianie w reakcji na alert oraz ręczne rozpoczęcie przez uprawnionego użytkownika. Przy analizie działania trzeba rozróżnić czas zaplanowanego startu od rzeczywistego startu, ponieważ job może czekać na zasoby, blokadę, zakończenie innego uruchomienia albo dostępność wątku wykonawczego.

Ważnym elementem jest także ograniczenie czasu pracy i liczby prób ponowienia kroku. Retry może pomóc przy przejściowym błędzie połączenia lub niedostępności zasobu, ale nie naprawia błędnego zapytania, braku uprawnień ani naruszenia ograniczenia integralności. Jeżeli krok ma kilka prób ponowienia, w historii należy sprawdzić wszystkie komunikaty, a nie tylko końcowy status joba. W przeciwnym razie można przeoczyć problemy występujące podczas wcześniejszych prób.

Historia, uprawnienia i kontrola skutków

Wyniki uruchomień jobów są dostępne w historii SQL Server Agent, a szczegółowe dane są zapisywane w msdb. Historia pozwala ustalić nazwę joba, krok, status, czas rozpoczęcia, czas zakończenia oraz komunikat zwrócony przez wykonanie. Przy długotrwałych operacjach warto porównywać czas trwania kolejnych uruchomień, ponieważ stały wzrost czasu może wskazywać na narastające dane, blokady, brak miejsca, zmianę planu wykonania albo problem z zasobami systemowymi. Sam status „Succeeded” oznacza powodzenie według reguł danego kroku; nie potwierdza automatycznie, że wszystkie oczekiwane dane zostały przetworzone.

Job ma właściciela i działa w kontekście uprawnień zależnych od użytego podsystemu. Krok Transact-SQL jest wykonywany przy zastosowaniu kontekstu określonego przez konfigurację SQL Server Agent oraz zabezpieczenia bazy, natomiast kroki wymagające dostępu do systemu operacyjnego mogą korzystać z konta proxy. Uprawnienia nadane interaktywnemu administratorowi nie muszą być dostępne dla konta używanego przez job. Dlatego diagnoza błędu „permission denied”, braku dostępu do pliku lub nieudanego połączenia powinna obejmować konto wykonawcze, bazę domyślną, poświadczenia i zakres uprawnień, a nie tylko treść polecenia.

Do kontroli skutków używa się powiadomień operatorów, alertów i jednoznacznych kodów zakończenia. Job wykonujący kopię zapasową, czyszczenie danych lub import powinien mieć jasno określone warunki sukcesu oraz komunikat błędu możliwy do odnalezienia w historii. Należy również pilnować retencji historii w msdb, ponieważ zbyt duża liczba wpisów może zwiększać rozmiar tej bazy, a zbyt krótka retencja utrudnia analizę awarii. Weryfikacja powinna obejmować także to, czy nie działają równolegle dwa uruchomienia tego samego zadania i czy kolejne kroki nie korzystają z częściowo zapisanych wyników.

Rozpoznawanie problemów z automatycznym jobem

Jeżeli procedura automatyczna nie wykonała operacji, pierwszym krokiem jest sprawdzenie, czy SQL Server Agent był uruchomiony oraz czy job był włączony w chwili planowanego startu. Następnie trzeba przeanalizować historię konkretnego uruchomienia i ustalić pierwszy krok, który zakończył się błędem. Warto porównać zapisane polecenie z bazą wskazaną w konfiguracji kroku, sprawdzić parametry, obiekty używane przez zapytanie oraz zależności od innych jobów. Komunikat „The step failed” jest informacją ogólną; przyczynę zawiera zwykle wcześniejszy lub bardziej szczegółowy wpis tego samego kroku.

Do częstych przyczyn należą blokady transakcji, przekroczenie limitu czasu, brak miejsca na dysku, niedostępna baza, nieprawidłowe poświadczenia, zmiana schematu tabeli oraz założenie, że bieżący katalog lub zmienna środowiskowa jest taka sama jak podczas ręcznego uruchomienia. Test naprawczy powinien odtwarzać kontekst joba: to samo konto, bazę, parametry i sposób uruchomienia. Po zmianie konfiguracji należy wykonać kontrolne uruchomienie, sprawdzić historię wszystkich kroków oraz potwierdzić rezultat w danych docelowych. Dla zadań cyklicznych trzeba dodatkowo zweryfikować następny termin wykonania, aby pojedyncza poprawka nie została unieważniona przez błędny harmonogram.

W przypadku diagnostyki na komputerze z zainstalowanym SQL Server Agent przydatne są SQL Server Management Studio, widok historii joba oraz zapytania do tabel i procedur systemowych bazy msdb. Analiza powinna rozdzielać problem definicji joba od problemu samego SQL Server, sieci, systemu plików lub zewnętrznego źródła danych. Dopiero po takim rozdzieleniu można bezpiecznie zdecydować, czy zmienić polecenie, harmonogram, uprawnienia, kolejność kroków czy konfigurację zasobu, z którego job korzysta.