SYS.DM_EXEC_SESSIONS

sys.dm_exec_sessions zwraca informacje o wszystkich aktywnych sesjach z instancją.

Kto obecnie siedzi w instancji

Widok wypisuje po jednym wierszu na każdą sesję nawiązaną z instancją SQL Servera, zarówno użytkownika, jak i procesów wewnętrznych silnika. Znajdziemy w nim session_id, login_name i original_login_name, host_name z nazwą stacji klienckiej, program_name z identyfikatorem aplikacji, status o wartościach running, sleeping lub dormant, oraz czas logowania. Kolumna is_user_process oddziela sesje aplikacyjne od systemowych - to pewniejsze kryterium niż stara reguła mówiąca, że identyfikatory do pięćdziesięciu należą do silnika.

Następca sysprocesses i jego zalety

Widok zastąpił dawną tabelę systemową sysprocesses, którą Microsoft utrzymuje już tylko dla zgodności. Różnica jest zasadnicza: stara tabela mieszała informacje o sesji, połączeniu i wykonywanym żądaniu w jednym wierszu, nowy model rozbija je na trzy widoki - sys.dm_exec_sessions dla sesji, sys.dm_exec_connections dla warstwy sieciowej wraz z adresem klienta i protokołem, oraz sys.dm_exec_requests dla aktualnie wykonywanego polecenia. Łączy się je po kolumnie session_id. Liczniki cpu_time, reads, writes i logical_reads w widoku sesji są narastające od momentu zalogowania, natomiast te same nazwy w widoku żądań dotyczą wyłącznie trwającego polecenia - pomylenie ich prowadzi do zupełnie błędnych wniosków o obciążeniu.

Co widok przemilcza i jak go źle czytać

Sesja o statusie sleeping nie jest bezczynna w sensie biznesowym - może trzymać otwartą transakcję i blokować innych, mimo że nie wykonuje w tej chwili żadnego polecenia. Kolumna program_name pochodzi wprost z parametrów połączenia klienta, więc bywa pusta albo zawiera domyślną nazwę sterownika, a nie nazwę systemu handlowego. Wartość host_name to nazwa stacji zgłoszona przez klienta, nie zaś zweryfikowany adres - ten trzeba wziąć z widoku połączeń. Sesje przez pulę połączeń aplikacyjnych nie giną po zamknięciu okna programu, tylko wracają do puli, co potrafi zmylić przy liczeniu aktywnych użytkowników pod kątem licencji.

Rozplątywanie zatorów w firmowej bazie

Zgłoszenia w rodzaju program stanął na zapisie dokumentu rozwiązujemy właśnie od tego widoku - ustalamy, która stacja i który użytkownik trzyma transakcję, i czy blokada bierze się z niezatwierdzonego dokumentu, czy z długiego raportu. Dopiero potem decydujemy o zakończeniu sesji poleceniem KILL, bo wycofanie dużej transakcji potrafi trwać dłużej niż samo czekanie. Obsługujemy w ten sposób bazy systemów handlowych działających na SQL Serverze, także w nocy i w weekendy.