SQL Server Agent zależny od Database Engine

SQL Server Agent jest zależny od uruchomionego Database Engine — bez niego nie wykona żadnego zadania.

Na czym polega zależność SQL Server Agent od Database Engine

SQL Server Agent jest usługą systemu SQL Server przeznaczoną do automatycznego wykonywania zadań administracyjnych i operacyjnych. Nie działa jako niezależny harmonogram, który może wykonywać zadania związane z bazami bez udziału silnika Database Engine. Agent obsługuje konkretną instancję SQL Server i korzysta z jej usług oraz metadanych przechowywanych w bazie systemowej msdb. Jeżeli Database Engine nie działa, Agent nie ma dostępu do wymaganej instancji ani do konfiguracji zadań.

Zależność obejmuje zarówno uruchamianie zadań typu Transact-SQL, jak i wiele czynności kontrolnych. SQL Server Agent odczytuje definicje jobów, harmonogramów, operatorów, alertów oraz historii wykonań z msdb. Do wykonywania kroków T-SQL nawiązuje połączenie z Database Engine, dlatego zatrzymanie silnika powoduje brak możliwości wykonania takich kroków. Sam fakt, że usługa SQL Server Agent może być widoczna w systemie Windows, nie oznacza, że zadania będą działały bez dostępnego Database Engine.

Co dzieje się po zatrzymaniu silnika bazy danych

Gdy usługa Database Engine zostanie zatrzymana, SQL Server Agent traci połączenie z instancją, dla której został skonfigurowany. Zaplanowane zadanie może zostać wywołane przez mechanizm harmonogramu, ale jego krok wymagający połączenia z SQL Server zakończy się błędem albo zadanie nie zostanie poprawnie zainicjowane. Dotyczy to między innymi poleceń T-SQL, procedur wykonywanych w bazach użytkownika oraz operacji korzystających z obiektów zapisanych w msdb.

W czasie niedostępności Database Engine Agent nie może również prawidłowo zapisywać historii uruchomień, statusów jobów i komunikatów dotyczących zadań. Po ponownym uruchomieniu silnika działanie zależy od harmonogramu i konfiguracji konkretnego zadania. Zadanie zaplanowane na określoną godzinę nie musi zostać automatycznie wykonane tylko dlatego, że serwer wrócił do pracy. Dla zadań wymagających ciągłości administrator powinien sprawdzić ustawienia harmonogramu, opcję reakcji na nieudane wykonanie oraz historię joba w msdb.

Przykłady zadań i prawidłowa kolejność uruchamiania

Typowy job SQL Server Agent może wykonywać instrukcje Transact-SQL, uruchamiać polecenia systemu operacyjnego przez podsystem CmdExec, wykonywać skrypty PowerShell albo realizować zadania związane z innymi składnikami SQL Server, jeśli są zainstalowane i skonfigurowane. Nawet gdy konkretny krok nie wysyła zapytania do bazy użytkownika, sam job, jego harmonogram i wynik wykonania są zarządzane przez SQL Server Agent w powiązaniu z instancją Database Engine oraz bazą msdb.

Podczas startu komputera lub serwera prawidłowa kolejność ma znaczenie: najpierw powinien być dostępny Database Engine, a następnie SQL Server Agent. W konfiguracji usług Windows zależność może być odzwierciedlona przez zależność usługi Agenta od usługi instancji SQL Server. Przy nazwanej instancji trzeba analizować nazwę właściwej usługi, na przykład MSSQL$NAZWA_INSTANCJI, a nie zakładać, że każda instalacja korzysta z usługi MSSQLSERVER. Po awarii warto sprawdzić stan obu usług, dziennik SQL Server Agent oraz dziennik błędów Database Engine, ponieważ przyczyną może być niedostępność silnika, problem z logowaniem Agenta albo błąd samego zadania.

Znaczenie zależności w diagnostyce SQL Server

Diagnostykę należy rozpocząć od potwierdzenia, że działa właściwa instancja Database Engine i że można nawiązać z nią połączenie. Następnie trzeba sprawdzić usługę SQL Server Agent, dostępność bazy msdb, uprawnienia konta usługi oraz stan konkretnego joba. W SSMS informacje o zadaniach znajdują się w SQL Server Agent, a ich historia jest zapisywana w msdb. Przy analizie błędu należy odróżnić problem z uruchomieniem usługi od problemu z pojedynczym krokiem, ponieważ komunikat „job failed” może wynikać zarówno z błędnego zapytania, jak i z braku połączenia z Database Engine.

Istotne jest także rozróżnienie wersji i edycji produktu. SQL Server Express nie zawiera SQL Server Agent, więc brak tej usługi w takiej instalacji nie oznacza awarii zależności, lecz ograniczenie edycji. W edycjach wyposażonych w SQL Server Agent jego działanie nadal pozostaje powiązane z konkretną instancją Database Engine. Jeżeli połączenie z silnikiem jest niestabilne, zadania cykliczne, alerty i automatyczne kopie zapasowe mogą nie zostać wykonane zgodnie z harmonogramem, dlatego kontrola stanu usług i historii jobów jest podstawowym elementem utrzymania środowiska SQL Server.