Widok sys.objects (typ TR)

Obiekty typu TR w sys.objects to wyzwalacze przypisane do tabel lub widoków bazy.

Wyzwalacze widziane od strony katalogu obiektów

Kod TR w kolumnie type widoku sys.objects opisuje wyzwalacz języka manipulacji danymi napisany w T-SQL, przypisany do konkretnej tabeli lub widoku. Kolumna parent_object_id wskazuje obiekt macierzysty, dzięki czemu jednym zapytaniem da się wypisać wszystkie wyzwalacze wraz z nazwami tabel, do których należą. Odpowiednikiem tworzonym w kodzie zarządzanym jest typ TA. Pełniejszy obraz daje widok sys.triggers, który dokłada kolumny is_disabled i is_instead_of_trigger, oraz sys.trigger_events opisujący, na jakie operacje — wstawienie, aktualizację czy usunięcie — wyzwalacz reaguje.

Moment wykonania i dostęp do danych zmienianych

Wyzwalacz typu AFTER uruchamia się po wykonaniu operacji, ale wciąż wewnątrz tej samej transakcji, więc instrukcja ROLLBACK w jego ciele wycofuje także pierwotny zapis. Wyzwalacz INSTEAD OF zastępuje operację i to on decyduje, co faktycznie trafi do tabeli — na tym opiera się możliwość zapisu do widoków łączących kilka tabel. Wewnątrz ciała dostępne są dwie tabele wirtualne: inserted z nowym stanem wierszy i deleted ze stanem poprzednim. Kluczowa właściwość, o którą rozbija się większość źle napisanego kodu, to fakt, że wyzwalacz odpala się raz na instrukcję, a nie raz na wiersz. Aktualizacja obejmująca tysiąc rekordów uruchamia go jeden raz z tysiącem wierszy w tabeli inserted, więc kod przypisujący wartość do zmiennej przez SELECT bez pętli obsłuży tylko jeden przypadkowy wiersz.

Objawy, po których poznaje się problem z wyzwalaczem

Pierwszy to niewyjaśnione spowolnienie zapisu dokumentów: operacja, która kiedyś trwała ułamek sekundy, po dopisaniu wyzwalacza logującego zmiany zaczyna czekać na zapis do tabeli historii bez indeksu. Drugi to zakleszczenia — dwa wyzwalacze sięgające do tych samych tabel w odwrotnej kolejności potrafią zablokować się wzajemnie i silnik ubija jedną z sesji komunikatem o wybraniu jej na ofiarę zakleszczenia. Trzeci to wyzwalacze wyłączone poleceniem DISABLE TRIGGER na czas migracji i nigdy nie włączone z powrotem, przez co historia zmian urywa się w konkretnym dniu, a nikt tego nie zauważa miesiącami. Czwarty to rekurencja i zagnieżdżanie: wyzwalacz modyfikujący własną tabelę wywołuje sam siebie, a limit zagnieżdżeń kończy operację błędem o przekroczeniu maksymalnego poziomu.

Przeglądy baz przed migracją serwera

Wyzwalacze to najczęstsza przyczyna niespodzianek po przeniesieniu bazy na nowy sprzęt albo nowszą wersję silnika, bo działają w tle i nie widać ich w kodzie aplikacji. Warszawskie Pogotowie Komputerowe przed taką operacją spisuje istniejące wyzwalacze wraz ze stanem włączenia i sprawdza po migracji, czy wszystkie wróciły do pracy. Serwisujemy firmowe wdrożenia oprogramowania handlowego opartego o SQL Server oraz sprzęt, na którym one stoją — od serwera po komputery pracowników. Pracujemy całodobowo, także w weekendy, więc przeniesienie bazy da się zaplanować na czas, gdy firma nie pracuje.