ALTER EVENT SESSION

Polecenie ALTER EVENT SESSION modyfikuje konfigurację sesji rozszerzonych zdarzeń wykorzystywanej do diagnostyki serwera SQL.

ALTER EVENT SESSION jako narzędzie zmiany konfiguracji

ALTER EVENT SESSION to polecenie języka Transact-SQL służące do modyfikowania już utworzonej sesji rozszerzonych zdarzeń. Taka sesja zbiera informacje o wybranych zdarzeniach zachodzących w środowisku SQL Server, dzięki czemu można obserwować wydajność, błędy, blokady, długie operacje oraz nietypowe zachowanie zapytań. Istotą polecenia nie jest utworzenie nowego mechanizmu diagnostycznego, lecz zmiana ustawień obiektu, który już istnieje w systemie.

Sesja zdarzeń składa się między innymi z nazwy, listy zdarzeń, predykatów ograniczających zakres zbieranych danych, docelowego miejsca zapisu oraz ustawień uruchamiania. Polecenie ALTER EVENT SESSION pozwala modyfikować wybrane elementy tej konfiguracji, a także rozpocząć lub zatrzymać działanie sesji. Dzięki temu sposób monitorowania można dopasować do aktualnego problemu bez tworzenia od podstaw całej definicji.

Ogólna konstrukcja polecenia może wyglądać następująco:

ALTER EVENT SESSION [NazwaSesji] ON SERVER
ADD EVENT [pakiet].[nazwa_zdarzenia]
ADD TARGET [pakiet].[nazwa_celu]
WITH (STARTUP_STATE = ON);

W zależności od potrzeby stosuje się również klauzule DROP EVENT, DROP TARGET, ADD EVENT, ALTER EVENT SESSION ... ON SERVER STATE = START lub STATE = STOP. Konkretna składnia zależy od rodzaju modyfikacji oraz od wersji używanego systemu. Przed wykonaniem zmiany warto sprawdzić, czy podana nazwa sesji, zdarzenia, celu i pakietu jest poprawna.

ALTER EVENT SESSION a inne sposoby obserwacji pracy bazy

Rozszerzone zdarzenia są rozwiązaniem bardziej elastycznym niż starsze mechanizmy śledzenia, ponieważ pozwalają precyzyjnie wybrać interesujące zdarzenia i ograniczyć ilość rejestrowanych informacji. W praktyce przekłada się to na mniejsze obciążenie oraz łatwiejsze dopasowanie diagnostyki do konkretnego pytania. Sesja może rejestrować na przykład wykonania zapytań przekraczających określony czas, błędy, zakleszczenia, zmiany planów wykonania albo aktywność związaną z określonym modułem.

W porównaniu z prostym odczytem bieżącego stanu systemu sesja zdarzeń dostarcza również danych historycznych, o ile skonfigurowano odpowiedni cel, taki jak plik zdarzeń lub bufor w pamięci. Z kolei mechanizmy raportowe i widoki dynamicznego zarządzania pokazują głównie stan aktualny albo informacje zależne od czasu działania instancji. ALTER EVENT SESSION umożliwia dostosowanie sposobu gromadzenia danych do sytuacji, w której standardowy podgląd nie wyjaśnia przyczyny problemu.

Nie każda modyfikacja wymaga zatrzymywania sesji. Dodanie zdarzenia lub celu może być możliwe w czasie jej działania, lecz nie należy zakładać tego bez sprawdzenia dokumentacji dla konkretnej wersji oprogramowania. Czasem bezpieczniej jest zatrzymać sesję, wprowadzić zmianę i uruchomić ją ponownie. Szczególnej uwagi wymaga ustawienie STARTUP_STATE, które określa, czy sesja ma uruchamiać się automatycznie po restarcie usługi.

• ADD EVENT rozszerza zakres obserwowanych zdarzeń.
• DROP EVENT usuwa niepotrzebne zdarzenie z konfiguracji.
• ADD TARGET wskazuje dodatkowe miejsce odbioru danych.
• DROP TARGET usuwa wybrany cel rejestracji.
• STATE = START uruchamia sesję, a STATE = STOP ją zatrzymuje.
• STARTUP_STATE określa zachowanie sesji po ponownym uruchomieniu usługi.

ALTER EVENT SESSION przy typowych problemach diagnostycznych

Jednym z częstych zastosowań jest tymczasowe rozszerzenie sesji o zdarzenia związane z długim wykonywaniem zapytań. Jeżeli obserwowane są opóźnienia, można dodać zdarzenia dostarczające informacji o czasie trwania operacji, tekście zapytania, identyfikatorze procesu lub bazie, w której wykonano polecenie. Ważne jest ustawienie odpowiedniego predykatu, ponieważ rejestrowanie każdej operacji może szybko zwiększyć ilość danych i utrudnić analizę.

Inny przypadek dotyczy zakleszczeń. Sesja może zostać skonfigurowana tak, aby zapisywała informacje o konflikcie blokad, uczestniczących transakcjach i zasobach, o które rywalizowały procesy. Zebrany materiał pomaga ustalić, czy problem wynika z kolejności modyfikowania tabel, zbyt długiej transakcji, braku właściwego indeksu albo nieoczekiwanej aplikacji działającej w tle.

ALTER EVENT SESSION może być również użyte podczas sprawdzania błędów logowania, nieudanych operacji, zmian uprawnień oraz nietypowych przerw w wykonywaniu poleceń. Dobór zdarzeń powinien wynikać z hipotezy diagnostycznej. Włączenie zbyt wielu kategorii naraz zwiększa szum informacyjny, a czasem także obciążenie zapisu. Lepsze rezultaty daje stopniowe rozszerzanie konfiguracji i porównywanie wyników po każdej zmianie.

Problemy mogą wynikać także z niewłaściwego celu. Bufor pamięci jest wygodny do szybkiego podglądu, lecz jego zawartość może zostać utracona po ponownym uruchomieniu usługi lub po zapełnieniu bufora. Plik zdarzeń lepiej nadaje się do dłuższej obserwacji, ale wymaga kontroli lokalizacji, uprawnień oraz rozmiaru plików. Przy modyfikowaniu sesji należy sprawdzić, czy konto usługi może zapisywać w wybranym miejscu.

ALTER EVENT SESSION i praktyczne zasady bezpiecznej zmiany

Przed użyciem polecenia należy odczytać aktualną definicję sesji, zamiast zakładać, że zawiera ona tylko elementy znane z wcześniejszej konfiguracji. Pozwala to uniknąć przypadkowego usunięcia zdarzenia, celu albo filtra, który jest potrzebny innemu procesowi diagnostycznemu. Przydatne jest także zapisanie bieżącego skryptu jako kopii odniesienia. W razie niepożądanego efektu można wtedy odtworzyć poprzedni stan krok po kroku.

Warto stosować nazwy jednoznacznie wskazujące cel sesji, na przykład obserwację zakleszczeń, opóźnionych zapytań lub błędów logowania. Ułatwia to późniejszą identyfikację wśród innych obiektów. Dobrym zwyczajem jest również ograniczenie zbierania do konkretnej bazy, aplikacji, procedury lub przedziału czasu, jeżeli warunki pozwalają na takie filtrowanie. Diagnostyka powinna być możliwie krótka i ukierunkowana, a po zakończeniu analizy zbędną sesję należy zatrzymać albo usunąć z aktywnego użycia.

Zmianę najlepiej wykonywać po sprawdzeniu uprawnień. Wymagany poziom dostępu może zależeć od zakresu modyfikacji, wersji systemu i miejsca, w którym sesja została utworzona. Błąd składni, brak dostępu do obiektu lub niezgodność nazwy pakietu może zatrzymać wykonanie całego polecenia. Przydatne jest przeprowadzenie próby w środowisku testowym oraz zapisanie komunikatu błędu wraz z pełnym tekstem użytego skryptu.

Należy też rozróżniać zmianę konfiguracji od zmiany danych zebranych wcześniej. ALTER EVENT SESSION nie służy do ręcznego poprawiania zapisów diagnostycznych. Modyfikuje sposób działania sesji od momentu wykonania polecenia, natomiast wcześniejsze dane pozostają w swoim dotychczasowym celu i podlegają jego własnym zasadom przechowywania.

ALTER EVENT SESSION a moment zgłoszenia problemu

Po ALTER EVENT SESSION warto sięgnąć wtedy, gdy pojawia się problem trudny do odtworzenia, a zwykły odczyt komunikatu lub bieżącego stanu nie wystarcza do ustalenia przyczyny. Dotyczy to między innymi okresowych opóźnień, sporadycznych błędów, nagłych blokad, przerw w pracy aplikacji i różnic między oczekiwanym a rzeczywistym czasem wykonania zapytań. Jeżeli nie ma pewności, które zdarzenia wybrać, przydatne jest najpierw opisanie objawów, czasu występowania i operacji, których problem dotyczy.

Przy analizie można skorzystać z pomocy serwisu Warszawskie Pogotowie Komputerowe 24/7, zwłaszcza gdy diagnoza wymaga uporządkowania konfiguracji, sprawdzenia logów i bezpiecznego przygotowania zmian. Naprawy z reguły realizowane są do 3 dni roboczych. Przed przekazaniem zgłoszenia warto przygotować wersję systemu, nazwę sesji, treść polecenia, komunikat błędu oraz informację, czy problem występuje stale, czy tylko w określonych momentach.

Nie należy zmieniać sesji bez planu, gdy zbierane dane mogą wpływać na działanie systemu lub gdy problem występuje w środowisku obsługującym ważne procesy. W takiej sytuacji bezpieczniejsze jest najpierw wykonanie kopii konfiguracji, ustalenie zakresu obserwacji i określenie warunku zakończenia zbierania. Dzięki temu ALTER EVENT SESSION pozostaje precyzyjnym narzędziem diagnostycznym, a nie przypadkowym zestawem zmian wykonywanych bez możliwości porównania wyników.