Widok msdb.dbo.sysjobservers

Widok msdb.dbo.sysjobservers zawiera informacje o przypisaniu zadań do serwerów docelowych.

Widok msdb.dbo.sysjobservers w SQL Server

Widok msdb.dbo.sysjobservers jest elementem bazy systemowej msdb w Microsoft SQL Server i służy do odczytywania informacji o powiązaniu zadań SQL Server Agent z miejscami, w których te zadania mogą być wykonywane. W praktyce pozwala sprawdzić, czy określone zadanie zostało przypisane do lokalnej instancji, czy też bierze udział w konfiguracji obejmującej więcej niż jeden serwer. Nie jest to widok przeznaczony do przechowywania samej definicji zadania, harmonogramu ani historii uruchomień. Jego znaczenie polega przede wszystkim na pokazaniu relacji pomiędzy zadaniem a docelową instancją.

Nazwa widoku może prowadzić do nieporozumienia, ponieważ w codziennej pracy spotyka się również inne obiekty związane z zadaniami agenta. Za opis zadania odpowiada przede wszystkim msdb.dbo.sysjobs, za kroki jego wykonania służy msdb.dbo.sysjobsteps, a za informacje o harmonogramach wykorzystywane są między innymi msdb.dbo.sysjobschedules oraz msdb.dbo.sysschedules. Widok sysjobservers należy więc traktować jako warstwę przypisania, a nie jako kompletny katalog właściwości zadania.

Widok msdb.dbo.sysjobservers a przypisanie zadań

Najważniejszym zastosowaniem widoku jest ustalenie, do jakiego serwera lub instancji odnosi się dane zadanie. W środowisku lokalnym wynik może wydawać się prosty, ponieważ większość zadań jest związana z bieżącą instancją. W konfiguracji wieloserwerowej znaczenie rośnie, gdyż jedno zadanie może być rozpatrywane w kontekście serwera głównego oraz serwerów docelowych. Taki model pozwala rozdzielić miejsce zarządzania zadaniem od miejsca jego wykonania.

Podczas analizy należy pamiętać, że przypisanie nie oznacza jeszcze, że zadanie zakończyło się powodzeniem, działa zgodnie z oczekiwaniami albo jest aktywne w harmonogramie. Informacja o powiązaniu nie zastępuje danych z historii uruchomień, statusu zadania ani konfiguracji poszczególnych kroków. Do sprawdzenia rezultatu wykonania przydatny jest widok msdb.dbo.sysjobhistory, natomiast do poznania aktualnych ustawień zadania potrzebny jest odczyt z msdb.dbo.sysjobs.

W porównaniu z widokiem zawierającym definicje zadań sysjobservers odpowiada na inne pytanie. sysjobs pomaga ustalić, jakie zadanie istnieje, jaki ma identyfikator, nazwę, właściciela i status. sysjobservers pomaga ustalić, z jakim miejscem wykonania jest ono powiązane. Z kolei sysjobsteps pokazuje, co zadanie wykonuje w kolejnych krokach, a sysjobhistory wskazuje, jak przebiegały wcześniejsze uruchomienia. Dopiero zestawienie tych danych daje pełniejszy obraz konfiguracji SQL Server Agent.

Widok msdb.dbo.sysjobservers i typowe problemy diagnostyczne

Jednym z częstych problemów jest błędna interpretacja pustego albo nieoczekiwanego wyniku. Brak wiersza nie musi oznaczać uszkodzenia zadania. Może wynikać z tego, że zadanie jest analizowane w innej instancji, że użyto nieprawidłowej bazy msdb albo że odczyt wykonano z konta, które nie ma dostępu do wszystkich informacji dotyczących zadań. Widoczność obiektów SQL Server Agent zależy również od uprawnień oraz członkostwa w odpowiednich rolach bazy msdb.

Inny problem pojawia się po migracji lub odtworzeniu bazy. Identyfikatory zadań, nazwy instancji i powiązania z miejscami docelowymi mogą nie odpowiadać wcześniejszemu środowisku. Samo przeniesienie definicji zadania nie gwarantuje odtworzenia całej konfiguracji agenta. Po zmianach warto sprawdzić nie tylko obecność zadania w sysjobs, lecz także relację widoczną w sysjobservers, harmonogramy, właściciela, poświadczenia i historię.

Problematyczne bywa także porównywanie wyników bez uwzględnienia czasu. Widoki systemowe pokazują stan konfiguracji w chwili zapytania, podczas gdy historia może dotyczyć wcześniejszego układu. Jeżeli zadanie zostało przeniesione, przemianowane lub przypisane ponownie, bieżący widok i starsze wpisy historii mogą opisywać różne etapy działania. Z tego powodu przy diagnozie należy zapisać moment wykonania zapytań i porównywać dane z kilku powiązanych obiektów.

Widok msdb.dbo.sysjobservers — praktyczne wskazówki zapytań

Odczyt można rozpocząć od prostego połączenia widoku z sysjobs, aby zamiast samego identyfikatora zobaczyć nazwę zadania. Przykładowy schemat zapytania może wyglądać następująco:

SELECT
    j.name AS job_name,
    js.*
FROM msdb.dbo.sysjobservers AS js
INNER JOIN msdb.dbo.sysjobs AS j
    ON j.job_id = js.job_id
ORDER BY j.name;

Takie zapytanie warto traktować jako punkt wyjścia, a nie gotowy raport kontrolny. Najpierw należy obejrzeć dostępne kolumny w konkretnej wersji SQL Server, ponieważ zakres oraz znaczenie pól mogą zależeć od wydania i sposobu konfiguracji agenta. Nie powinno się zakładać, że każda kolumna będzie miała identyczną wartość w środowisku lokalnym i wieloserwerowym.

Przy porównywaniu instancji przydatne jest filtrowanie po job_id, ponieważ identyfikator jest stabilniejszy niż nazwa zadania. Nazwa może zostać zmieniona, natomiast identyfikator pozwala łatwiej śledzić to samo zadanie w kilku zapytaniach. Jednocześnie nie należy przenosić identyfikatorów pomiędzy niezależnymi instancjami bez weryfikacji, gdyż ten sam zapis tekstowy nie musi oznaczać tego samego obiektu.

Dobrym zwyczajem jest wykonywanie odczytów w sposób niezmieniający danych. Widoki systemowe powinny służyć do obserwacji, porównań i przygotowania diagnozy. Modyfikowanie tabel systemowych bezpośrednio nie jest właściwą metodą administracji. Zmiany konfiguracji zadań należy przeprowadzać przez obsługiwane procedury systemowe, SQL Server Management Studio albo inne narzędzie administracyjne, a przed zmianą zachować opis bieżącego ustawienia.

Kiedy sprawdzać widok msdb.dbo.sysjobservers

Analizę tego widoku warto rozpocząć wtedy, gdy zadanie istnieje, lecz wykonuje się w nieoczekiwanym miejscu, nie pojawia się na właściwej instancji albo po migracji nie zachowuje się tak jak wcześniej. Przydatne jest również sprawdzenie relacji, gdy zmieniono nazwę instancji, odtworzono bazę msdb, przebudowano konfigurację SQL Server Agent lub dodano obsługę zadań wykonywanych na wielu serwerach. Sam widok nie wskaże całej przyczyny, ale może zawęzić obszar dalszego sprawdzania.

Do serwisu warto zgłosić się wtedy, gdy analiza konfiguracji SQL Server łączy się z problemami sprzętowymi komputera, niestabilnym działaniem systemu, błędami nośnika danych albo trudnościami z dostępem do środowiska administracyjnego. Warszawskie Pogotowie Komputerowe 24/7 zajmuje się wsparciem przy problemach komputerowych w Warszawie. Przed przekazaniem sprzętu dobrze przygotować opis objawów, moment pojawienia się problemu, informacje o ostatnich zmianach oraz bezpieczną kopię danych. W przypadku zadań SQL Server przydatne są także fragmenty komunikatów błędów, nazwa używanej instancji i informacja, czy problem dotyczy jednego zadania, czy większej grupy.

Jeżeli problem ogranicza się do interpretacji danych w msdb, należy zachować ostrożność i nie usuwać zadań ani nie modyfikować tabel systemowych na podstawie pojedynczego wyniku. Najpierw powinno się potwierdzić uprawnienia, wersję SQL Server, aktualny kontekst instancji oraz zgodność informacji z sysjobs, sysjobsteps i sysjobhistory. Dopiero po takim porównaniu można ocenić, czy występuje rzeczywisty błąd przypisania, problem z harmonogramem, brak dostępu, czy jedynie nieprawidłowa interpretacja widoku.