Widok sys.dm_exec_connections

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

Czym jest widok sys.dm_exec_connections

Widok sys.dm_exec_connections służy do obserwowania połączeń nawiązanych z instancją Microsoft SQL Server. Każdy rekord opisuje określone połączenie widziane z perspektywy silnika bazy danych, dlatego można dzięki niemu sprawdzić między innymi identyfikator połączenia, sesję powiązaną z połączeniem, adres sieciowy klienta, użyty protokół oraz stan szyfrowania. Jest to widok dynamiczny, czyli jego zawartość odzwierciedla bieżącą sytuację, a nie trwały rejestr historyczny.

W praktyce trzeba odróżnić połączenie od sesji i od żądania. Połączenie opisuje kanał komunikacyjny pomiędzy klientem a instancją. Sesja reprezentuje kontekst pracy użytkownika lub aplikacji, natomiast żądanie dotyczy konkretnej operacji wykonywanej w danym momencie. Jedna sesja może być powiązana z połączeniem, ale te pojęcia nie są zamienne. Z tego powodu sam odczyt sys.dm_exec_connections nie zawsze wystarcza do ustalenia, jakie zapytanie zużywa zasoby albo które polecenie oczekuje na blokadę.

Widok przydaje się przede wszystkim podczas diagnostyki problemów z dostępnością, konfiguracją sieci, uwierzytelnianiem i szyfrowaniem. Pozwala sprawdzić, czy połączenie zostało przyjęte przez właściwy punkt komunikacyjny, z jakiego adresu pochodzi klient oraz czy używane są oczekiwane właściwości transportu. Wyniki należy jednak interpretować w kontekście konfiguracji instancji, topologii sieci, ustawień sterownika oraz sposobu, w jaki aplikacja zarządza pulą połączeń.

Kontekst techniczny widoku sys.dm_exec_connections i porównania

sys.dm_exec_connections należy do dynamicznych widoków zarządzania. Odczyt danych z takiego widoku nie oznacza pobrania informacji z tabeli aplikacyjnej, lecz zapytanie do mechanizmów diagnostycznych utrzymywanych przez silnik. Dane mogą zmieniać się pomiędzy kolejnymi wykonaniami tego samego zapytania, ponieważ klienci otwierają połączenia, zamykają je, ponawiają próby albo korzystają z puli utrzymywanej przez sterownik.

Najważniejsze porównanie dotyczy widoku sys.dm_exec_sessions. Ten widok opisuje sesje, ich identyfikatory, użytkowników, czas rozpoczęcia oraz część parametrów kontekstu pracy. sys.dm_exec_connections koncentruje się natomiast na warstwie połączenia. Jeżeli potrzebne jest ustalenie, kto wykonuje zapytanie i jak długo trwa jego praca, zwykle trzeba połączyć dane z obu widoków za pomocą odpowiednich identyfikatorów.

Inną rolę pełni sys.dm_exec_requests. Ten widok pokazuje aktywne żądania, ich status, czas oczekiwania, bazę danych, typ oczekiwania oraz identyfikatory blokujących operacji. Połączenie z sys.dm_exec_connections może dać szerszy obraz: skąd pochodzi komunikacja, do jakiej sesji należy oraz jakie żądanie jest aktualnie wykonywane. Jeszcze inną kategorię stanowią widoki dotyczące konfiguracji punktów nasłuchu, protokołów i endpointów. One opisują ustawienia dostępności, podczas gdy sys.dm_exec_connections pokazuje połączenia faktycznie widziane w danym momencie.

Przy analizie należy rozróżniać połączenia lokalne i zdalne. Dla połączeń lokalnych adres klienta może być pusty, uproszczony albo prezentowany w sposób zależny od stosu komunikacyjnego. Nie powinno się więc automatycznie uznawać braku wartości adresu za dowód awarii. Znaczenie poszczególnych kolumn może również zależeć od wersji SQL Server, rodzaju protokołu oraz uprawnień osoby wykonującej zapytanie.

Typowe problemy wykrywane przez sys.dm_exec_connections

Jednym z częstych przypadków jest sytuacja, w której aplikacja zgłasza brak dostępu, mimo że sama instancja działa. Odczyt połączeń może wtedy pomóc ustalić, czy próby klienta w ogóle docierają do silnika. Jeżeli nie pojawia się oczekiwane połączenie, przyczyna może znajdować się w nazwie instancji, konfiguracji sterownika, zaporze, trasie sieciowej, ustawieniach protokołu albo w niezgodnych parametrach szyfrowania.

Innym problemem są liczne połączenia pozostawione w stanie bezczynności. Nie każde bezczynne połączenie jest błędem. Wiele aplikacji korzysta z puli, aby uniknąć kosztu ciągłego otwierania i zamykania kanału komunikacyjnego. Niepokój powinien pojawić się wtedy, gdy liczba połączeń stale rośnie, czas ich utrzymywania jest nieuzasadniony, a użytkownicy otrzymują komunikaty o wyczerpaniu limitu albo o braku dostępnych zasobów.

Warto również sprawdzić niezgodność pomiędzy adresem oczekiwanym a adresem rzeczywistym. Może ona wynikać z translacji adresów, pośrednika sieciowego, puli połączeń, kontenera, aplikacji wielowarstwowej lub konfiguracji biblioteki klienckiej. Sam adres zapisany w widoku nie zawsze wskazuje fizyczne urządzenie końcowego użytkownika. Jest to informacja o punkcie, z którego połączenie zostało zaobserwowane przez SQL Server.

Problemy z szyfrowaniem wymagają ostrożnej interpretacji. Wartość związana z użyciem szyfrowania mówi, jak zostało zestawione konkretne połączenie, ale nie zastępuje kontroli certyfikatów, protokołów, ustawień klienta i polityk bezpieczeństwa. Po zmianie konfiguracji nie należy zakładać, że wszystkie istniejące połączenia natychmiast przejmą nowe parametry. Często konieczne jest zamknięcie połączeń w puli i nawiązanie ich ponownie.

• Brak oczekiwanego rekordu może wskazywać na problem przed warstwą silnika albo na bardzo krótki czas trwania próby.
• Duża liczba bezczynnych połączeń wymaga porównania z konfiguracją puli, a nie automatycznego zamykania sesji.
• Adres klienta należy analizować razem z topologią sieci i ewentualnymi pośrednikami.
• Stan szyfrowania powinien być oceniany razem z ustawieniami sterownika oraz certyfikatu.
• Sam widok połączeń nie wyjaśnia przyczyn blokad, wolnych zapytań ani wysokiego zużycia procesora.

Praktyczne wskazówki dotyczące sys.dm_exec_connections

Zapytanie diagnostyczne powinno wybierać tylko kolumny potrzebne do konkretnego celu. Ułatwia to czytanie wyników i ogranicza ryzyko błędnej interpretacji. W typowej analizie można zestawić identyfikator połączenia, identyfikator sesji, adres klienta, protokół, port, czas rozpoczęcia oraz informacje o szyfrowaniu. Następnie warto połączyć wynik z sys.dm_exec_sessions i sys.dm_exec_requests, jeżeli potrzebny jest pełniejszy obraz aktywności.

Przykładowa forma zapytania może wyglądać następująco:

SELECT c.session_id, c.connect_time, c.client_net_address, c.protocol_type, c.encrypt_option
FROM sys.dm_exec_connections AS c;

Takie zapytanie ma charakter obserwacyjny. Nie zmienia konfiguracji i nie rozłącza klientów. Przed użyciem w środowisku produkcyjnym należy jednak sprawdzić wymagane uprawnienia oraz ograniczyć zakres odczytu do informacji potrzebnych podczas diagnozy. Jeżeli dane mają być porównywane w czasie, wynik trzeba zapisywać w kontrolowany sposób wraz ze znacznikiem czasu, ponieważ sam widok nie stanowi historii połączeń.

Podczas powtarzania pomiarów trzeba zachować tę samą metodę filtrowania. Raz wykonane zapytanie bez filtra może pokazać sytuację chwilową, a kolejne zapytanie po kilku sekundach może już zawierać zupełnie inny zestaw rekordów. Przydatne jest wykonywanie kilku obserwacji w różnych momentach i zestawienie ich z logami aplikacji, licznikami systemowymi oraz komunikatami sterownika. Dopiero zgodność kilku źródeł pozwala ostrożnie ocenić, czy problem jest stały, czy występuje tylko przy skokowym obciążeniu.

Nie powinno się usuwać połączeń wyłącznie na podstawie ich wieku. Długie połączenie może być prawidłowym elementem puli, a gwałtowne rozłączanie klientów może wywołać dodatkowe błędy logowania i przerwane transakcje. Najpierw należy ustalić właściciela aplikacyjnego połączenia, sprawdzić zasady bezczynności i potwierdzić, że zamknięcie jest bezpieczne z punktu widzenia użytkowników.

Kiedy zgłosić się do serwisu z problemem wokół sys.dm_exec_connections

Do konsultacji technicznej warto zgłosić się wtedy, gdy problem z połączeniami powtarza się mimo sprawdzenia konfiguracji klienta, gdy aplikacja traci dostęp w losowych momentach albo gdy obserwowane dane nie zgadzają się z logami. Pomoc może być potrzebna również wtedy, gdy nie wiadomo, czy źródłem trudności jest system, sterownik, sieć, ustawienia bezpieczeństwa czy sama aplikacja. Przed zgłoszeniem dobrze przygotować godzinę wystąpienia problemu, komunikat błędu, nazwę używanego programu oraz zanonimizowany wynik diagnostyczny.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się analizą problemów ze sprzętem komputerowym i oprogramowaniem, a naprawy z reguły są realizowane do 3 dni roboczych. Przy przekazywaniu materiałów diagnostycznych nie należy udostępniać haseł, kluczy szyfrujących ani pełnych danych użytkowników. Wystarczające bywają fragmenty logów, identyfikatory techniczne oraz opis kolejności zdarzeń, o ile zostały wcześniej pozbawione danych wrażliwych.

Najważniejszym celem diagnozy jest rozdzielenie problemu komunikacyjnego od problemu wykonania zapytania. Jeżeli połączenie nie powstaje, należy badać dostępność i konfigurację kanału. Jeżeli połączenie istnieje, ale operacje są wolne, trzeba przejść do analizy sesji, żądań, oczekiwań, blokad i planów wykonania. Taki podział ogranicza przypadkowe działania i ułatwia dobranie dalszych kroków do rzeczywistego źródła trudności.