API do SQL Server Agent

API do SQL Server Agent to interfejs umożliwiający programowe zarządzanie zaplanowanymi zadaniami serwera bazodanowego.

Zakres API SQL Server Agent

API do SQL Server Agent oznacza zestaw programowych mechanizmów służących do tworzenia, odczytywania, modyfikowania i uruchamiania obiektów agenta z poziomu aplikacji lub skryptu. SQL Server Agent jest składnikiem Microsoft SQL Server odpowiedzialnym za wykonywanie zadań w określonych warunkach i terminach. Najczęściej zarządza się nim przez Transact-SQL, procedury składowane w bazie systemowej msdb albo bibliotekę SQL Server Management Objects, czyli SMO. W środowiskach korzystających z PowerShell można również używać modułów i obiektów SMO do automatyzacji administracyjnej.

Podstawowym obiektem jest zadanie, czyli job. Zadanie może zawierać jeden lub wiele kroków wykonywanych w ustalonej kolejności. Krok może uruchamiać instrukcję Transact-SQL, polecenie systemu operacyjnego, pakiet usług SSIS albo inne działanie obsługiwane przez konkretną instalację SQL Server Agent. Zadanie może zostać uruchomione ręcznie, zgodnie z harmonogramem, przez alert albo w reakcji na określone zdarzenie. API nie wykonuje samo logiki biznesowej zadania, lecz pozwala programowo definiować jej konfigurację i kontrolować cykl wykonania.

Obiekty zarządzane przez program

Interfejs administracyjny SQL Server Agent obejmuje kilka powiązanych typów obiektów. Do zadania można przypisać kroki, harmonogramy, powiadomienia i warunki uruchomienia. Harmonogram określa między innymi częstotliwość, godzinę rozpoczęcia, datę obowiązywania oraz sposób powtarzania zadania. Jeden harmonogram może być powiązany z więcej niż jednym zadaniem, dlatego zmiana jego definicji może wpłynąć na wiele procesów. API powinno rozróżniać zmianę konfiguracji zadania od jednorazowego uruchomienia jego bieżącej instancji.

SQL Server Agent obsługuje także alerty i operatorów. Alert może reagować na błąd określonego poziomu, konkretny numer błędu SQL Server, zdarzenie zapisane w dzienniku aplikacji albo warunek wydajnościowy obsługiwany przez agenta. Operator jest odbiorcą powiadomień, na przykład wiadomości e-mail, pagera lub powiadomienia sieciowego, zależnie od skonfigurowanych funkcji i wersji środowiska. W definicji zadania można również określić akcję po sukcesie, niepowodzeniu albo zakończeniu, co pozwala budować zależności między zadaniami bez ręcznego nadzorowania każdego uruchomienia.

Automatyzacja przez T-SQL i SMO

W Transact-SQL zarządzanie zadaniami odbywa się przede wszystkim przez udokumentowane procedury składowane SQL Server Agent, takie jak sp_add_job, sp_add_jobstep, sp_add_schedule, sp_attach_schedule oraz sp_start_job. Procedury te są wykonywane w kontekście bazy msdb i wymagają odpowiednich uprawnień. Przy projektowaniu skryptu należy kontrolować kolejność operacji: najpierw tworzy się zadanie, następnie jego kroki i harmonogram, a później wiąże harmonogram z zadaniem. W przeciwnym razie skrypt może utworzyć częściową konfigurację albo zakończyć się błędem zależności.

SMO udostępnia obiektowy model administracji SQL Server. Aplikacja może połączyć się z instancją, odszukać kolekcję zadań agenta, pobrać właściwości konkretnego zadania, zmienić jego kroki lub harmonogram, a następnie zapisać konfigurację na serwerze. Przy takim podejściu trzeba uwzględnić różnice między połączeniem do silnika SQL Server a stanem usługi SQL Server Agent. Agent musi działać, aby wykonywać zadania według harmonogramu, lecz część operacji konfiguracyjnych może być realizowana przez połączenie administracyjne nawet wtedy, gdy usługa agenta nie wykonuje bieżących zadań.

Uprawnienia, wykonanie i kontrola wyników

Wywołanie API SQL Server Agent odbywa się z określonym kontekstem bezpieczeństwa. Uprawnienia użytkownika w bazie msdb, członkostwo w rolach SQL Server Agent oraz uprawnienia do obiektów używanych przez kroki zadania decydują o tym, co można utworzyć lub uruchomić. Dla zadań wykonujących Transact-SQL znaczenie ma konto używane przez agenta, właściciel zadania oraz ewentualne konto proxy. Krok uruchamiający polecenie systemowe nie dziedziczy automatycznie wszystkich uprawnień osoby, która utworzyła zadanie. Z tego powodu sama poprawna definicja zadania nie gwarantuje poprawnego wykonania.

Program korzystający z API powinien sprawdzać zarówno wynik operacji administracyjnej, jak i historię wykonania zadania. Informacja o przyjęciu polecenia sp_start_job nie jest równoznaczna z pomyślnym zakończeniem wszystkich kroków. Do analizy służą między innymi historia zadania przechowywana w msdb, status poszczególnych kroków, komunikaty błędów oraz dziennik SQL Server Agent. Należy też unikać wielokrotnego tworzenia obiektów przy ponownym uruchomieniu automatyzacji: skrypt powinien rozpoznawać istniejące zadanie, harmonogram i kroki oraz jawnie określać, czy ma je zaktualizować, czy utworzyć od początku.