session_created to zdarzenie Extended Events rejestrujące moment nawiązania nowej sesji z instancją.
Co oznacza zdarzenie session_created w SQL Server
session_created jest zdarzeniem dostępnym w mechanizmie Extended Events programu Microsoft SQL Server. Rejestruje utworzenie nowej sesji na instancji silnika, czyli moment, w którym SQL Server przygotowuje kontekst obsługi połączenia klienta. Sesja jest wewnętrznym obiektem silnika identyfikowanym między innymi przez numer SPID, nazywany również identyfikatorem sesji. Nie należy utożsamiać samego utworzenia sesji z wykonaniem konkretnego zapytania ani z rozpoczęciem transakcji.
Zdarzenie może pojawić się w związku z połączeniem aplikacji, narzędzia administracyjnego, usługi systemowej albo innego klienta korzystającego z protokołu obsługi SQL Server. W środowisku z pulą połączeń aplikacja może utrzymywać wcześniej utworzone sesje i wielokrotnie używać ich do wykonywania żądań. W takim przypadku liczba zdarzeń session_created nie musi odpowiadać liczbie żądań aplikacji ani liczbie użytkowników korzystających z programu.
Jakie informacje można analizować
Zakres danych zależy od definicji sesji Extended Events, wybranego celu zdarzeń oraz wersji SQL Server. Podczas konfiguracji można dołączyć do zdarzenia dodatkowe akcje, które uzupełniają zapis o informacje kontekstowe, na przykład identyfikator sesji, nazwę hosta klienta, nazwę aplikacji, konto użyte do połączenia lub tekst powiązany z aktywnością. Akcje nie są tym samym co pola zdarzenia: dodaje się je jawnie, a ich dostępność trzeba sprawdzić dla konkretnej wersji silnika i pakietu zdarzeń.
Analiza rekordów powinna uwzględniać czas wystąpienia, identyfikator sesji oraz źródło połączenia. Krótki odstęp między wieloma zdarzeniami może wskazywać na częste otwieranie i zamykanie połączeń przez aplikację, błędnie skonfigurowaną pulę połączeń albo mechanizm ponawiania prób po błędzie. Samo session_created nie wyjaśnia jednak przyczyny takiego zachowania. Do pełnej diagnozy trzeba zestawić je z innymi zdarzeniami, na przykład dotyczącymi logowania, rozłączeń, błędów, blokad lub wykonywania instrukcji.
Konfiguracja i odbiór zdarzeń Extended Events
Sesję Extended Events tworzy się poleceniem CREATE EVENT SESSION, a interesujące zdarzenie dodaje klauzula ADD EVENT wskazująca pakiet i nazwę zdarzenia. W przypadku SQL Server nazwa zdarzenia jest kwalifikowana nazwą pakietu, dlatego przed zapisaniem konfiguracji należy potwierdzić ją w katalogu systemowym Extended Events dla używanej instancji. Pomocne są widoki katalogowe, w tym sys.server_event_sessions, sys.server_event_session_events oraz sys.server_event_session_targets, które pokazują odpowiednio sesje, przypisane zdarzenia i cele.
Do odbioru danych można wykorzystać cel plikowy albo bufor pierścieniowy. Cel plikowy pozwala zachować większą liczbę rekordów i analizować je po zakończeniu obserwacji, natomiast bufor pierścieniowy przechowuje dane w pamięci i jest przydatny przy krótkiej diagnostyce. Po utworzeniu sesji trzeba ją uruchomić poleceniem ALTER EVENT SESSION ... ON SERVER STATE = START. Zatrzymanie sesji wykonuje się przez ustawienie stanu STOP. Uprawnienia wymagane do tworzenia, uruchamiania i odczytu sesji zależą od wersji SQL Server oraz przyjętego modelu uprawnień, dlatego konfigurację należy wykonywać na koncie posiadającym odpowiednie prawa administracyjne.
Znaczenie diagnostyczne w administracji SQL Server
session_created pomaga ustalić, kiedy instancja SQL Server zaczęła obsługiwać nowe konteksty klientów. Może być użyteczne przy badaniu skokowego wzrostu liczby połączeń, przeciążenia limitów zasobów, problemów po wdrożeniu nowej wersji aplikacji oraz nieoczekiwanego ruchu generowanego przez usługi korzystające z bazy. Porównanie czasu utworzenia sesji z logami aplikacji pozwala sprawdzić, czy połączenia powstają podczas uruchamiania programu, po błędach komunikacji, czy w regularnych odstępach wynikających z harmonogramu zadań.
Nie należy traktować obecności tego zdarzenia jako dowodu udanego uwierzytelnienia, wykonania zapytania ani poprawnego działania aplikacji. Utworzenie sesji jest tylko jednym etapem obsługi połączenia. Wnioski powinny być oparte na korelacji kilku źródeł: danych Extended Events, widoków dynamicznych takich jak sys.dm_exec_sessions i sys.dm_exec_connections, dziennika SQL Server oraz logów klienta. Trzeba także uwzględnić filtr predykatowy, czas życia sesji diagnostycznej i sposób zapisu danych, ponieważ te elementy wpływają na kompletność obserwacji. W środowisku produkcyjnym rozsądne filtry i ograniczony zakres akcji zmniejszają narzut związany z rejestrowaniem zdarzeń.
