SYS.DM_EXEC_CONNECTIONS

sys.dm_exec_connections zwraca informacje o aktywnych połączeniach klientów z instancją.

SYS.DM_EXEC_CONNECTIONS jako obraz połączeń z instancją

SYS.DM_EXEC_CONNECTIONS jest dynamicznym widokiem zarządzania dostępnym w Microsoft SQL Server. Służy do odczytywania informacji o połączeniach nawiązanych z konkretną instancją oraz o kanałach komunikacji wykorzystywanych przez sesje klientów. W praktyce pozwala ustalić, jakie połączenia są obecnie widoczne dla silnika, z jakiego adresu lub procesu pochodzą i jaki sposób uwierzytelniania został użyty.

Warto rozdzielić pojęcie połączenia od pojęcia sesji. Połączenie opisuje kanał komunikacyjny między klientem a instancją, natomiast sesja odnosi się do kontekstu pracy użytkownika lub aplikacji po zalogowaniu. Jeden klient może utrzymywać więcej niż jedno połączenie, a aplikacja może korzystać z puli połączeń, przez co liczba obserwowanych rekordów nie zawsze odpowiada liczbie osób pracujących z bazą danych.

Widok jest szczególnie przydatny podczas analizy problemów z dostępnością, diagnostyki nagłego wzrostu liczby połączeń oraz sprawdzania, czy aplikacja nawiązuje komunikację zgodnie z oczekiwaniami. Odczyt danych z SYS.DM_EXEC_CONNECTIONS nie oznacza automatycznego zakończenia żadnego połączenia ani zmiany konfiguracji. Jest to przede wszystkim źródło informacji diagnostycznej, które należy interpretować razem z innymi widokami systemowymi.

SYS.DM_EXEC_CONNECTIONS a sesje, żądania i procesy klienta

W kontekście analizy działania SQL Server często porównuje się SYS.DM_EXEC_CONNECTIONS z SYS.DM_EXEC_SESSIONS oraz SYS.DM_EXEC_REQUESTS. Pierwszy z tych widoków koncentruje się na kanałach połączeń, drugi pokazuje konteksty sesji, a trzeci przedstawia aktualnie wykonywane żądania. Dzięki takiemu zestawieniu można przejść od ogólnego pytania „kto jest podłączony” do bardziej precyzyjnej odpowiedzi dotyczącej tego, jaka operacja jest wykonywana i z jakim obciążeniem się wiąże.

Kolumny dostępne w SYS.DM_EXEC_CONNECTIONS mogą zawierać między innymi identyfikator połączenia, identyfikator sesji, informacje o czasie zestawienia kanału, adresie klienta, porcie, protokole oraz metodzie uwierzytelniania. Zakres i znaczenie poszczególnych pól zależą od wersji silnika, sposobu zestawienia komunikacji oraz uprawnień osoby wykonującej zapytanie. Z tego powodu nie należy zakładać, że każda kolumna będzie wypełniona w każdej sytuacji.

Przydatne bywa także odróżnienie połączeń lokalnych od zdalnych. Połączenie lokalne może być związane z aplikacją uruchomioną na tym samym komputerze co instancja, natomiast połączenie zdalne zwykle wskazuje na inny host w sieci. Sam adres klienta nie przesądza jednak o tożsamości użytkownika, nazwie aplikacji ani przyczynie obciążenia. Do pełniejszego obrazu potrzebne są dane z sesji, aktywnych żądań, dzienników oraz konfiguracji aplikacji.

SYS.DM_EXEC_CONNECTIONS można więc traktować jako element większej układanki. Widok pomaga ustalić, czy problem dotyczy nawiązywania kanału, nadmiarowych połączeń, zerwanych komunikacji czy też operacji wykonywanych już po poprawnym zalogowaniu. Takie rozróżnienie skraca drogę do właściwej diagnozy.

SYS.DM_EXEC_CONNECTIONS przy typowych problemach diagnostycznych

Jednym z częstych zastosowań jest badanie sytuacji, w której użytkownicy zgłaszają opóźnienia albo okresową utratę dostępu do bazy danych. W pierwszym kroku można sprawdzić, czy połączenia rzeczywiście docierają do instancji, czy mają aktualne identyfikatory sesji i czy pojawia się oczekiwany protokół. Jeżeli połączeń nie ma, przyczyny należy szukać między innymi w ustawieniach klienta, rozpoznawaniu nazwy hosta, regułach zapory, konfiguracji nasłuchiwania lub niezgodnych parametrach połączenia.

Innym przypadkiem jest szybkie narastanie liczby połączeń. Może to oznaczać niewłaściwe zarządzanie pulą połączeń, brak ich zwalniania po zakończeniu operacji, błędną obsługę wyjątków albo nieprawidłowo ustawiony czas bezczynności. SYS.DM_EXEC_CONNECTIONS pozwala zaobserwować skalę zjawiska, lecz nie wskazuje samodzielnie, dlaczego aplikacja utrzymuje dany kanał. Niezbędne może być powiązanie identyfikatora połączenia z sesją i logami aplikacyjnymi.

Podczas analizy warto uważać na połączenia techniczne tworzone przez narzędzia monitorujące, zadania automatyczne, sterowniki oraz biblioteki pośredniczące. Nie każde połączenie odpowiada bezpośredniej pracy człowieka. Zdarzają się również krótkotrwałe połączenia, które znikają przed zakończeniem obserwacji, dlatego pojedynczy odczyt nie zawsze wystarcza do znalezienia źródła problemu.

Znaczenie ma także moment wykonania zapytania. Dane w widoku opisują stan obserwowany w określonej chwili, a nie pełną historię komunikacji. Przy trudno odtwarzalnych błędach przydatne jest wykonywanie kontrolnych odczytów w odstępach czasu i zestawianie ich ze zdarzeniami aplikacyjnymi. Należy przy tym ograniczyć zakres zbieranych danych do informacji potrzebnych do diagnozy, ponieważ adresy klientów i identyfikatory sesji mogą mieć znaczenie administracyjne.

SYS.DM_EXEC_CONNECTIONS i praktyczne wskazówki interpretacji

Przed rozpoczęciem analizy warto określić pytanie, na które ma odpowiedzieć odczyt. Inaczej interpretuje się dane, gdy sprawdzana jest niedostępność, inaczej gdy poszukiwane są nadmiarowe połączenia, a jeszcze inaczej podczas weryfikowania sposobu uwierzytelniania. Takie podejście pozwala uniknąć gromadzenia przypadkowych informacji i ułatwia późniejsze porównanie wyników.

Wynik SYS.DM_EXEC_CONNECTIONS powinien być odczytywany razem z nazwami kolumn oraz z uwzględnieniem ich możliwych wartości pustych. Brak wartości nie zawsze jest błędem. Może wynikać z rodzaju połączenia, ograniczeń bezpieczeństwa, lokalnego charakteru komunikacji albo z tego, że dana informacja nie jest dostępna dla konkretnego kontekstu. Wnioski powinny być formułowane na podstawie kilku zgodnych obserwacji.

Przydatne jest zachowanie czasu pomiaru, nazwy instancji, środowiska oraz okoliczności wystąpienia problemu. Jeśli sprawdzany jest wzrost liczby połączeń, można porównywać identyfikatory sesji, adresy klientów, nazwy aplikacji widoczne po stronie sesji oraz czas rozpoczęcia komunikacji. Jeżeli celem jest analiza zrywania połączeń, warto zestawić wyniki z komunikatami sterownika, dziennikami systemowymi i logami aplikacji.

Nie należy traktować samej liczby rekordów jako miary wydajności. Duża liczba bezczynnych połączeń może wskazywać na prawidłowe działanie puli, ale może też sygnalizować nieprawidłową konfigurację. Z kolei mała liczba połączeń nie wyklucza przeciążenia, jeżeli aktywne żądania wykonują kosztowne operacje. SYS.DM_EXEC_CONNECTIONS odpowiada na pytania dotyczące komunikacji, natomiast ocena obciążenia wymaga dodatkowych danych o sesjach, żądaniach, blokadach i czasie wykonania.

Przy sporządzaniu dokumentacji diagnostycznej warto opisywać obserwacje bez ujawniania niepotrzebnych danych identyfikujących użytkowników. Zaleca się anonimizowanie adresów oraz nazw aplikacji w materiałach przekazywanych poza zespołem administracyjnym. Ułatwia to zachowanie zasad bezpieczeństwa, a jednocześnie pozostawia informacje potrzebne do odtworzenia toku analizy.

SYS.DM_EXEC_CONNECTIONS i moment zgłoszenia problemu do serwisu

Do zgłoszenia problemu warto się przygotować, gdy połączenia z instancją znikają mimo poprawnych danych logowania, pojawiają się cykliczne przerwy w pracy aplikacji, liczba kanałów rośnie bez wyraźnej przyczyny albo różne stanowiska otrzymują odmienne komunikaty dostępu. Przydatne będą godzina wystąpienia zjawiska, nazwa używanej aplikacji, opis powtarzalności, komunikaty błędów oraz wyniki odczytów z SYS.DM_EXEC_CONNECTIONS i widoków powiązanych.

Przed przekazaniem materiałów można sprawdzić, czy problem dotyczy jednego stanowiska, kilku urządzeń czy całego środowiska pracy. Należy również ustalić, czy zmieniano ostatnio sterowniki, ustawienia sieciowe, zasady uwierzytelniania albo konfigurację aplikacji. Takie informacje pomagają odróżnić awarię po stronie komputera od problemu z komunikacją lub konfiguracją instancji.

W przypadku usterek sprzętowych związanych z laptopem lub komputerem PC pomoc może obejmować sprawdzenie urządzenia, systemu, sterowników i połączeń sieciowych. Warszawskie Pogotowie Komputerowe 24/7 wykonuje naprawy z reguły do 3 dni roboczych, co może ułatwić szybkie przywrócenie stanowiska do pracy. Przy zgłoszeniu warto przekazać dokładny opis objawów, ponieważ dane o SYS.DM_EXEC_CONNECTIONS dotyczą warstwy komunikacji z bazą, ale przyczyna może znajdować się również w konfiguracji lokalnego komputera.