Procedury składowane automatyczne

Procedury składowane automatyczne uruchamiają się przy starcie instancji, jeśli oznaczono je jako startup procedures.

Mechanizm uruchamiania procedury przy starcie SQL Server

Procedura składowana automatyczna w tym znaczeniu jest procedurą składowaną oznaczoną w SQL Server jako procedura startowa, czyli startup procedure. Silnik sprawdza takie oznaczenia podczas uruchamiania instancji i wykonuje wskazane procedury po rozpoczęciu pracy. Nie jest to wyzwalacz tabeli ani zadanie harmonogramu SQL Server Agent. Uruchomienie następuje w związku z uruchomieniem instancji, a nie po wykonaniu określonej operacji na danych.

Procedura startowa musi być zapisana w bazie master. Samo utworzenie procedury składowanej nie powoduje jej automatycznego wykonania. Najpierw należy utworzyć ją w odpowiedniej bazie, a następnie włączyć dla niej opcję startową za pomocą systemowej procedury sp_procoption. Ustawienie dotyczy konkretnej procedury i konkretnej instancji SQL Server, dlatego przeniesienie kodu do innej instancji wymaga odtworzenia także konfiguracji tej opcji.

Włączanie i wyłączanie opcji startup

Do oznaczenia procedury jako startowej służy wywołanie w rodzaju EXEC sys.sp_procoption @ProcName = N'nazwa_procedury', @OptionName = N'startup', @OptionValue = N'true';. Procedura musi już istnieć w bazie master. Wyłączenie automatycznego uruchamiania wykonuje się przez użycie tej samej opcji z wartością false. W praktyce należy zachować pełną nazwę procedury, a jeżeli jest używany schemat inny niż domyślny, podać nazwę razem ze schematem.

Zmiana opcji startowej nie powinna być traktowana jak zwykła zmiana treści procedury. Kod może zostać poprawiony, ale oznaczenie startup pozostaje osobnym elementem konfiguracji. Przy migracji, odtworzeniu bazy master albo budowie nowej instancji trzeba więc sprawdzić zarówno definicję procedury, jak i jej status. Do weryfikacji można użyć widoków katalogowych dotyczących procedur oraz sprawdzić, czy procedura znajduje się w bazie master i czy ma oczekiwane właściwości.

Zakres wykonania i obsługa błędów

Procedura startowa działa w kontekście uruchamianej instancji, dlatego jej kod powinien być krótki, przewidywalny i odporny na sytuację, w której część usług lub obiektów nie jest jeszcze gotowa. Odwołanie do tabeli, widoku, funkcji albo konfiguracji, która nie istnieje w danym momencie, może zakończyć się błędem. Szczególnej uwagi wymagają instrukcje wykonujące operacje poza bazą master, ponieważ muszą uwzględniać dostępność docelowej bazy i poprawność używanych nazw obiektów.

Błąd wykonania procedury startowej nie powinien być diagnozowany wyłącznie na podstawie faktu, że usługa SQL Server została uruchomiona. Należy sprawdzić dziennik błędów SQL Server, dziennik systemowy oraz treść procedury. Warto rejestrować w kontrolowany sposób rozpoczęcie i zakończenie działania, a operacje podatne na błąd zabezpieczać odpowiednią obsługą wyjątków. Jednocześnie procedura nie powinna wykonywać niepotrzebnie długich operacji, blokować obiektów ani uruchamiać logiki, która może być bez końca powtarzana przy każdym restarcie instancji.

Kontrola konfiguracji podczas diagnostyki instancji

Podczas analizy problemu należy ustalić, czy procedura rzeczywiście jest oznaczona jako startowa, czy została utworzona w bazie master, kiedy ostatnio zmieniono jej definicję oraz jakie uprawnienia i zależności wykorzystuje. Trzeba również sprawdzić, czy instancja nie została uruchomiona z konfiguracją pomijającą procedury startowe. W SQL Server służy do tego między innymi flaga śledzenia 4022, która wyłącza wykonywanie procedur startowych. Jej obecność może wyjaśniać sytuację, w której poprawnie oznaczona procedura nie uruchamia się po restarcie.

Wynik diagnostyki powinien rozróżniać trzy przypadki: procedura nie ma ustawionej opcji startup, procedura jest oznaczona, lecz jej wykonanie kończy się błędem, albo wykonanie jest pomijane przez konfigurację startową instancji. Takie rozdzielenie zapobiega błędnej naprawie polegającej na wielokrotnym oznaczaniu tej samej procedury bez sprawdzenia logów i kodu. W przypadku zmian należy najpierw zachować kopię definicji, następnie przetestować zachowanie po kontrolowanym restarcie i potwierdzić rezultat w dzienniku błędów oraz w stanie obiektów, które procedura ma przygotować.