DROP EVENT SESSION

DROP EVENT SESSION to polecenie Transact-SQL usuwające zdefiniowaną sesję rozszerzonych zdarzeń.

DROP EVENT SESSION — czym jest to polecenie

DROP EVENT SESSION jest instrukcją języka Transact-SQL służącą do usunięcia wcześniej utworzonej sesji rozszerzonych zdarzeń. Taka sesja stanowi zdefiniowany mechanizm obserwowania wybranych sytuacji zachodzących podczas pracy środowiska bazodanowego. Mogą być w niej wskazane między innymi zdarzenia związane z wykonywaniem zapytań, błędami, blokadami, przekroczeniem określonego czasu działania albo innymi sygnałami przydatnymi podczas analizy problemu. Samo polecenie DROP EVENT SESSION nie służy do zatrzymywania pojedynczego przechwytywania danych, lecz usuwa definicję sesji z systemu.

Usunięcie definicji oznacza utratę konfiguracji zapisanej pod daną nazwą. Jeżeli sesja była aktywna, wykonanie polecenia powoduje również zakończenie jej działania. Przed użyciem instrukcji warto więc ustalić, czy sesja nie jest właśnie wykorzystywana do diagnostyki, obserwacji wydajności lub zbierania materiału potrzebnego do wyjaśnienia błędu. W razie potrzeby konfigurację można wcześniej zapisać w skrypcie, aby później odtworzyć ją przy użyciu instrukcji CREATE EVENT SESSION.

Podstawowa postać polecenia obejmuje nazwę sesji oraz opcjonalne wskazanie zakresu, w którym została utworzona:

• DROP EVENT SESSION nazwa_sesji ON SERVER;
• DROP EVENT SESSION nazwa_sesji ON DATABASE;

Wybór właściwego wariantu zależy od miejsca utworzenia sesji. Nazwa musi odpowiadać rzeczywistej nazwie zapisanej w systemie, a zakres powinien być taki sam jak podczas tworzenia. Z tego powodu przed wykonaniem instrukcji zaleca się sprawdzenie listy istniejących sesji oraz ich właściwości.

EVENT w DROP EVENT SESSION — kontekst techniczny i porównania

Rozszerzone zdarzenia są mechanizmem pozwalającym rejestrować określone aktywności bez stałego analizowania całego środowiska. Sesja może zawierać zestaw zdarzeń, filtry, akcje dodatkowe oraz miejsce docelowe dla zebranych danych. W zależności od konfiguracji zapis może trafiać do pamięci, pliku albo innego obsługiwanego celu. DROP EVENT SESSION oddziałuje na całą taką definicję, dlatego nie należy utożsamiać go z usuwaniem pojedynczego zdarzenia, filtra czy pliku wynikowego.

Istotne jest rozróżnienie kilku operacji. ALTER EVENT SESSION służy do zmiany wybranych elementów istniejącej sesji, na przykład dodania zdarzenia lub modyfikacji celu. START SESSION uruchamia przechwytywanie zgodnie z zapisaną konfiguracją, a STOP SESSION kończy bieżące zbieranie danych bez usuwania samej definicji. DROP EVENT SESSION wykonuje krok dalej: usuwa obiekt sesji, przez co nie pozostaje on dostępny do ponownego uruchomienia bez wcześniejszego odtworzenia konfiguracji.

Można to porównać do różnicy między wyłączeniem narzędzia obserwacyjnego a usunięciem jego ustawień. Zatrzymanie sesji zachowuje nazwę, zdarzenia i filtry. Usunięcie sesji usuwa jej opis z systemu. Plik, który powstał wcześniej jako cel zapisu, nie powinien być automatycznie traktowany jako część definicji sesji. Jego dalsze istnienie i sposób obsługi zależą od użytego celu, konfiguracji oraz przyjętych zasad zarządzania danymi.

W środowiskach, w których kilka osób prowadzi diagnostykę, znaczenie ma także czytelne nazewnictwo. Sesje tymczasowe powinny mieć nazwy wskazujące ich zastosowanie, a po zakończeniu analizy powinny być przeglądane pod kątem dalszej przydatności. Dzięki temu łatwiej odróżnić konfigurację testową od sesji używanej regularnie oraz ograniczyć ryzyko usunięcia niewłaściwego obiektu.

SESSION w DROP EVENT SESSION — typowe problemy i błędy

Jednym z częstszych problemów jest próba usunięcia sesji pod nieprawidłową nazwą. Literówka, pominięty znak albo różnica w zapisie może zakończyć się komunikatem o braku obiektu. W takim przypadku należy zweryfikować nazwę za pomocą widoków systemowych i sprawdzić, czy sesja należy do zakresu serwera, czy do konkretnej bazy danych. Samo podobieństwo nazw nie wystarcza do potwierdzenia, że wybrano właściwą definicję.

Inny problem wynika z pomylenia polecenia DROP z instrukcją STOP. Jeżeli zamiarem było tylko chwilowe ograniczenie obciążenia lub zatrzymanie zbierania danych, usunięcie sesji będzie działaniem zbyt daleko idącym. Po wykonaniu DROP nie będzie można jej uruchomić ponownie bez odtworzenia konfiguracji. Warto zachować skrypt tworzący sesję, szczególnie gdy zawiera rozbudowane filtry, niestandardowe akcje albo precyzyjnie dobrany cel zapisu.

Trudność może pojawić się również wtedy, gdy sesja jest aktywna, a jej usunięcie jest wykonywane z konta pozbawionego odpowiednich uprawnień. Wymagany zakres uprawnień zależy od wersji oprogramowania, miejsca utworzenia sesji i przyjętego modelu zabezpieczeń. Komunikat o odmowie dostępu nie powinien być omijany przez przypadkowe podnoszenie uprawnień. Najpierw powinno się ustalić, jaka rola jest wymagana i czy osoba wykonująca operację ma podstawę do jej użycia.

Przed usunięciem trzeba też uwzględnić dane, które zostały już zgromadzone. Skasowanie sesji nie musi oznaczać usunięcia wcześniej utworzonych plików z wynikami. Nie powinno się jednak zakładać, że zachowanie danych będzie identyczne w każdej konfiguracji. Należy osobno sprawdzić stan celu, nazwy plików, sposób rotacji oraz zasady przechowywania. Jeżeli materiał jest potrzebny do raportu lub dalszej analizy, powinien zostać zabezpieczony przed wykonaniem operacji porządkowej.

Niepożądane skutki może przynieść także usuwanie sesji bez dokumentacji. Po czasie trudniej wtedy ustalić, jakie zdarzenia były obserwowane, jakie filtry zastosowano i dlaczego sesja została utworzona. Krótki opis celu, data utworzenia oraz osoba odpowiedzialna za konfigurację ułatwiają późniejsze decyzje dotyczące modyfikacji lub usunięcia.

DROP EVENT SESSION — praktyczne wskazówki przed usunięciem

Bezpieczny sposób postępowania zaczyna się od identyfikacji obiektu. Najpierw należy wyświetlić istniejące sesje, potwierdzić ich nazwy, zakres oraz status. Następnie warto ustalić, czy wskazana sesja jest aktywna, kiedy była ostatnio używana i czy korzysta z niej skrypt automatyczny albo procedura diagnostyczna. Takie sprawdzenie ogranicza ryzyko przerwania obserwacji prowadzonej przez inną osobę.

Jeżeli sesja ma zostać usunięta, zaleca się zachowanie jej definicji w repozytorium skryptów lub w dokumentacji zmian. Przydatne jest zapisanie informacji o zdarzeniach, filtrach, akcjach i celu danych. W przypadku konfiguracji tworzonej wyłącznie na potrzeby jednego badania należy opisać, jaki problem miała wyjaśnić oraz czy zebrane dane zostały już przeanalizowane.

Przed wykonaniem polecenia można zastosować następującą kolejność czynności:

• potwierdzenie dokładnej nazwy sesji i jej zakresu;
• sprawdzenie, czy sesja jest aktywna;
• ocena, czy zapisane dane zostały zachowane i opisane;
• wykonanie kopii definicji w postaci skryptu;
• wykonanie DROP EVENT SESSION w odpowiednim kontekście;
• ponowne sprawdzenie listy sesji oraz komunikatów po operacji.

Po usunięciu warto sprawdzić, czy obiekt rzeczywiście zniknął z listy oraz czy nie występują błędy w zadaniach, które próbowały go uruchomić. Jeżeli sesja była elementem powtarzalnego procesu diagnostycznego, należy zaktualizować dokumentację i usunąć nieaktualne odwołania. Pomocne bywa także odnotowanie przyczyny usunięcia, ponieważ sam fakt wykonania polecenia nie wyjaśnia, czy chodziło o zakończenie testu, zmianę konfiguracji, czy porządkowanie nieużywanych definicji.

DROP EVENT SESSION — kiedy zgłosić się do serwisu

Do konsultacji warto zgłosić się wtedy, gdy nie da się ustalić, która sesja odpowiada za obserwowane działanie, pojawiają się odmowy dostępu albo po usunięciu konfiguracji przestają działać procesy diagnostyczne. Wskazaniem jest również sytuacja, w której wykonanie polecenia może przerwać trwającą analizę, usunąć ważne ustawienia lub utrudnić odtworzenie wcześniejszego sposobu zbierania danych. Przed przekazaniem sprawy dobrze przygotować komunikat błędu, nazwę sesji, zakres obiektu oraz informację, czy sesja była aktywna.

Wsparcie techniczne może obejmować rozpoznanie struktury sesji, ocenę zależności, przygotowanie kopii definicji i uporządkowanie nieużywanych konfiguracji. W Warszawie takie czynności może realizować Warszawskie Pogotowie Komputerowe 24/7, zwłaszcza gdy problem z poleceniem DROP EVENT SESSION jest częścią szerszych trudności z działaniem komputera, narzędzi administracyjnych lub oprogramowania bazodanowego. Najważniejsze pozostaje zachowanie kontroli nad konfiguracją i potwierdzenie, że usuwany obiekt jest rzeczywiście przeznaczony do likwidacji.