Kursor w wyzwalaczu

Kursor w wyzwalaczu to konstrukcja przetwarzająca wiersze pojedynczo wewnątrz triggera, zwykle znacząco pogarszająca wydajność.

Kursor w wyzwalaczu – czym jest ta konstrukcja

Kursor w wyzwalaczu oznacza sposób przetwarzania danych, w którym instrukcja uruchamiana po zmianie rekordu przechodzi przez wynik zapytania wiersz po wierszu. Wyzwalacz, nazywany także triggerem, jest automatycznie wykonywany po wystąpieniu określonego zdarzenia, na przykład po dodaniu, modyfikacji albo usunięciu danych. Jeżeli w jego wnętrzu umieszczony zostanie kursor, każde zdarzenie może powodować utworzenie zbioru wynikowego, otwarcie mechanizmu odczytu oraz wielokrotne wykonanie operacji dla kolejnych wierszy.

Taki model bywa przydatny w szczególnych sytuacjach, gdy każda pozycja wymaga osobnej logiki i nie da się jej łatwo opisać jednym poleceniem działającym na całym zbiorze. Nie powinien jednak być traktowany jako domyślny sposób pisania wyzwalaczy. Wyzwalacz działa w ramach operacji, która go uruchomiła, dlatego czas jego pracy wpływa na czas zapisu danych. Nawet pozornie prosta zmiana może stać się długotrwała, gdy dotyczy większej liczby wierszy, a dla każdego z nich uruchamiany jest osobny przebieg kursora.

W praktyce problem nie wynika z samej obecności kursora, lecz z połączenia kilku cech: przetwarzania rekordów pojedynczo, wykonywania dodatkowych zapytań, blokowania zasobów podczas trwania operacji oraz braku kontroli nad liczbą wierszy objętych zmianą. Z tego powodu ocena takiej konstrukcji powinna obejmować zarówno kod triggera, jak i zapytania, które mogą go uruchamiać.

Kursor w wyzwalaczu a przetwarzanie zbiorowe

Najważniejszym punktem porównania jest różnica między podejściem wierszowym a operacją zbiorową. Przetwarzanie wierszowe zakłada schemat: pobierz jeden rekord, wykonaj instrukcję, przejdź do następnego rekordu i powtórz całość aż do końca wyniku. Każdy krok wiąże się z obsługą zmiennych, warunków, odczytów i zapisów. Przy dużej liczbie elementów narzut tych czynności sumuje się.

Przetwarzanie zbiorowe opisuje natomiast regułę dla całego zestawu danych. Silnik bazy może wtedy dobrać plan wykonania, ograniczyć liczbę operacji wejścia i wyjścia oraz lepiej wykorzystać indeksy. Przykładem może być jednorazowe uzupełnienie wartości w tabeli pomocniczej na podstawie wszystkich zmienionych rekordów, zamiast wykonywania osobnego zapytania dla każdego z nich. Nie zawsze da się całkowicie zastąpić kursor jedną instrukcją, ale często możliwe jest przeniesienie części pracy poza pętlę albo ograniczenie jej do niewielkiego fragmentu.

Znaczenie ma także rodzaj zdarzenia. W niektórych systemach wyzwalacz jest wywoływany raz dla całej instrukcji modyfikującej dane, a nie osobno dla każdego wiersza. W takim przypadku trzeba szczególnie uważać na założenia dotyczące pojedynczej wartości. Kod przygotowany tak, jakby zawsze zmieniany był jeden rekord, może działać poprawnie podczas prostych testów, a następnie generować błędy lub duże opóźnienia przy operacji obejmującej wiele wierszy.

Porównanie powinno uwzględniać też czytelność. Krótkie zapytanie zbiorowe bywa łatwiejsze do sprawdzenia niż rozbudowana pętla z wieloma warunkami. Kursor może być uzasadniony, gdy kolejność działań ma znaczenie, gdy wynik jednego kroku wpływa na następny albo gdy wymagana jest procedura trudna do zapisania deklaratywnie. W takich przypadkach potrzebne są jednak wyraźne warunki zakończenia, właściwa obsługa błędów i ograniczenie zakresu blokad.

Kursor w wyzwalaczu – typowe problemy i objawy

Najczęstszym skutkiem zastosowania kursora w triggerze jest wydłużenie czasu zapisu. Użytkownik może odczuwać to jako powolne dodawanie, edytowanie lub usuwanie rekordów, choć samo zapytanie główne wygląda na niewielkie. Przyczyną może być praca wykonywana w tle przez wyzwalacz. Im więcej wierszy obejmuje modyfikacja, tym dłużej pozostaje aktywna cała transakcja.

Drugim problemem jest narastanie liczby odwołań do tabel. Jeżeli dla każdego odczytanego rekordu wykonywane jest kolejne zapytanie kontrolne, a następnie jeszcze osobny zapis, jedna operacja wejściowa może prowadzić do setek lub tysięcy dodatkowych działań. Gdy zapytania nie korzystają z odpowiednich indeksów, czas wykonania rośnie jeszcze szybciej. W logach można wtedy zauważyć długie transakcje, oczekiwanie na blokady albo zwiększone obciążenie procesora i pamięci.

Ryzyko dotyczy również zakleszczeń. Wyzwalacz może modyfikować tabele, które są jednocześnie używane przez inne operacje. Jeżeli różne procesy uzyskują blokady w odmiennej kolejności, może dojść do wzajemnego oczekiwania. Czasem objawem jest pojedynczy błąd pojawiający się nieregularnie, a czasem całe grupy nieudanych zapisów. Kursor utrzymujący transakcję przez dłuższy czas zwiększa prawdopodobieństwo takiej sytuacji.

Niepożądane skutki mogą mieć także charakter logiczny. Wyzwalacz może uruchamiać kolejne wyzwalacze, zmieniać dane, które ponownie aktywują tę samą regułę, albo wykonywać operacje w kolejności innej, niż zakładano. Pojawiają się wtedy powtarzające się zapisy, niespójne wartości, trudne do odtworzenia różnice między tabelami oraz problemy występujące wyłącznie przy większych partiach danych. Szczególną uwagę należy zwrócić na sytuacje, w których kursor nie jest poprawnie zamykany po błędzie lub gdy nie obsłużono pustego wyniku.

Kursor w wyzwalaczu – praktyczne wskazówki diagnostyczne

Analizę warto rozpocząć od ustalenia, jakie zdarzenie uruchamia wyzwalacz oraz czy jest on wykonywany dla każdego wiersza, czy dla całej instrukcji. Następnie należy sprawdzić, jakie tabele są odczytywane i modyfikowane, jakie warunki filtrują dane oraz czy operacje korzystają z indeksów. Pomocne jest zmierzenie czasu wykonania dla jednej zmiany i dla partii obejmującej większą liczbę rekordów. Różnica między tymi wynikami często pokazuje, czy problem wynika z kosztu stałego, czy z powtarzania tej samej pracy.

Warto również przeanalizować plan zapytań wykonywanych wewnątrz pętli. Jeżeli dla każdego wiersza przeprowadzane jest pełne przeszukiwanie tabeli, konieczne może być dodanie właściwego indeksu albo zmiana warunku łączenia. Sam indeks nie rozwiąże jednak problemu, gdy logika powinna zostać wykonana zbiorowo. Przed zmianą kodu należy opisać oczekiwany rezultat, uwzględniając przypadki pustego zestawu, wielu zmienionych wierszy, wartości pustych oraz sytuacji, w których rekord powiązany nie istnieje.

Bezpiecznym kierunkiem jest ograniczanie pracy wykonywanej w wyzwalaczu. Jeżeli dana czynność nie musi odbywać się w tej samej transakcji, można rozważyć przeniesienie jej do kontrolowanego procesu wykonywanego po zatwierdzeniu danych. Jeżeli musi pozostać w triggerze, należy skrócić kod, zmniejszyć liczbę odczytów i zapisów oraz unikać dodatkowych operacji niezwiązanych bezpośrednio z integralnością informacji. Każda zmiana powinna być przetestowana na kopii danych i przy obciążeniu zbliżonym do rzeczywistego.

Nie należy usuwać wyzwalacza bez sprawdzenia jego roli. Może on odpowiadać za kontrolę spójności, zapis historii, aktualizację wartości zależnych albo ochronę przed nieprawidłową modyfikacją. Najpierw trzeba ustalić, jakie procesy korzystają z jego działania, a dopiero potem zdecydować o uproszczeniu, zastąpieniu go operacją zbiorową lub rozdzieleniu odpowiedzialności między kilka mniejszych elementów.

Kursor w wyzwalaczu – kiedy zgłosić się do serwisu

Pomoc serwisowa może być potrzebna, gdy opóźnienia pojawiają się po wdrożeniu nowej reguły automatycznej, gdy zapis danych kończy się błędem albo gdy problem występuje tylko przy większej liczbie zmienianych rekordów. Zgłoszenie powinno zawierać opis operacji, przybliżony moment występowania trudności, komunikaty błędów oraz informację, czy spowolnienie dotyczy jednego stanowiska, czy całego środowiska pracy. Przydatne są również kopie zapasowe i bezpieczny dostęp do konfiguracji, o ile mogą zostać udostępnione bez naruszania poufności danych.

W Warszawie analizę takich problemów można zlecić firmie Warszawskie Pogotowie Komputerowe 24/7, kontaktując się pod numerem +48 22 100 48 29. W ramach zgłoszenia można omówić diagnostykę, ocenę konfiguracji oraz sposób ograniczenia opóźnień związanych z automatycznym przetwarzaniem danych. Szczególnie istotne jest wcześniejsze ustalenie zakresu zmian, wykonanie kopii zapasowej i zachowanie możliwości odtworzenia poprzedniej konfiguracji.

Przed przekazaniem systemu do analizy warto przygotować przykładowe zapytanie wywołujące problem, opis oczekiwanego działania oraz informację o tym, kiedy pojawiła się pierwsza zauważalna zmiana. Ułatwia to odróżnienie problemu z samym kursorem od kłopotów wynikających z blokad, brakujących indeksów, nieprawidłowych relacji albo przeciążenia innych elementów systemu. Dzięki temu możliwe staje się dobranie rozwiązania do rzeczywistej przyczyny, zamiast doraźnego wyłączania mechanizmu, który może być potrzebny do zachowania spójności danych.