SYS.DM_EXEC_INPUT_BUFFER

sys.dm_exec_input_buffer zwraca ostatnie polecenie wysłane przez daną sesję lub żądanie.

SYS.DM_EXEC_INPUT_BUFFER — czym jest to polecenie diagnostyczne

SYS.DM_EXEC_INPUT_BUFFER to dynamiczny widok zarządzania dostępny w Microsoft SQL Server, używany do sprawdzania treści polecenia powiązanego z określoną sesją albo żądaniem. W praktyce pozwala ustalić, jaki tekst SQL był ostatnio przekazany do silnika przez wskazane połączenie. Ma to znaczenie podczas analizy zawieszonych operacji, nietypowego obciążenia procesora, długiego oczekiwania na blokadę oraz problemów zgłaszanych przez aplikację, która korzysta z bazy danych.

Widok nie służy do pobierania pełnej historii pracy użytkownika ani do odtwarzania wszystkich poleceń wykonanych w przeszłości. Zwracany jest przede wszystkim ostatni dostępny komunikat wejściowy związany z sesją lub konkretnym żądaniem. Jeżeli sesja wykonała kilka instrukcji, wynik nie powinien być interpretowany jako kompletny dziennik aktywności. Do szerszej analizy potrzebne są inne mechanizmy, na przykład śledzenie zdarzeń, odpowiednio skonfigurowany monitoring albo analiza logów aplikacyjnych.

Warto również odróżnić treść polecenia od jego aktualnego planu wykonania, czasu trwania oraz stanu blokowania. SYS.DM_EXEC_INPUT_BUFFER pomaga odpowiedzieć na pytanie, jakie polecenie zostało przesłane, natomiast informacje o planie, oczekiwaniu czy zasobach trzeba zestawić z innymi widokami dynamicznymi. Dzięki temu można uniknąć pochopnego wniosku, że sama treść zapytania wyjaśnia całą przyczynę problemu.

SYS.DM_EXEC_INPUT_BUFFER — kontekst techniczny i porównania

Najczęściej widok łączy się z SYS.DM_EXEC_SESSIONS oraz SYS.DM_EXEC_REQUESTS. Pierwszy z tych widoków opisuje połączenia, między innymi identyfikator sesji, użytkownika, aplikację i podstawowy stan. Drugi pokazuje aktywne żądania, takie jak wykonywana komenda, czas rozpoczęcia, oczekiwany typ zasobu, identyfikator blokującej sesji oraz identyfikator aktualnie przetwarzanego polecenia. SYS.DM_EXEC_INPUT_BUFFER uzupełnia te dane o tekst wejściowy przypisany do wskazanego kontekstu.

Istotne są dwa identyfikatory: SPID, czyli identyfikator sesji, oraz identyfikator żądania. W przypadku analizy całej sesji można odwołać się do jej identyfikatora, natomiast przy badaniu konkretnego aktywnego żądania należy uwzględnić również numer żądania. W przeciwnym razie może zostać pokazany komunikat odnoszący się do szerszego kontekstu połączenia, a nie do operacji obserwowanej w danej chwili.

W praktyce spotyka się dwa sposoby użycia widoku: wywołanie funkcji dla pojedynczego identyfikatora sesji oraz zastosowanie zapytania z CROSS APPLY przy zestawianiu listy sesji lub aktywnych żądań. Pierwszy wariant jest wygodny podczas szybkiego sprawdzenia jednego połączenia. Drugi ułatwia przygotowanie przekrojowego zestawienia, w którym obok tekstu wejściowego widoczne są dane o użytkowniku, aplikacji, czasie rozpoczęcia i oczekiwaniu.

Nie należy mylić SYS.DM_EXEC_INPUT_BUFFER z SYS.DM_EXEC_SQL_TEXT. Ten drugi mechanizm służy do odczytywania tekstu skojarzonego z uchwytem planu lub instrukcji, gdy taki uchwyt jest dostępny. Input buffer odpowiada na nieco inne pytanie: jaki komunikat wejściowy został przypisany do sesji albo żądania. Różnica jest ważna przy procedurach składowanych, wywołaniach z parametrami i poleceniach uruchamianych przez warstwę aplikacyjną.

SYS.DM_EXEC_INPUT_BUFFER — typowe problemy w użyciu

Jednym z częstszych błędów jest sprawdzanie nie tego identyfikatora, który faktycznie odpowiada problematycznej operacji. Lista aktywnych żądań może zmieniać się bardzo szybko, dlatego odczyt numeru sesji, a następnie wykonanie osobnego zapytania po kilku chwilach nie zawsze daje obraz tej samej sytuacji. Przy krótkich operacjach wynik może już dotyczyć następnego polecenia albo połączenia oczekującego na kolejną pracę.

Drugim problemem jest brak uprawnień do obserwowania cudzych sesji. Zakres widocznych informacji zależy od konfiguracji zabezpieczeń i poziomu uprawnień przyznanego kontu. Przy ograniczonym dostępie można uzyskać dane dotyczące własnego połączenia, ale niekoniecznie pełny obraz aktywności pozostałych użytkowników. W razie potrzeby należy skonsultować wymagane uprawnienia z osobą odpowiedzialną za bezpieczeństwo bazy, zamiast przyznawać szeroki dostęp bez analizy ryzyka.

Wynik może także zawierać nazwę procedury, wywołanie parametryzowane lub tekst, który nie opisuje bezpośrednio najbardziej kosztownego fragmentu pracy. Aplikacja często wysyła wywołanie procedury, podczas gdy szczegółowe instrukcje są wykonywane wewnątrz jej kodu. Z tego powodu sam input buffer powinien być punktem wyjścia do dalszego sprawdzenia, a nie jedynym dowodem używanym przy formułowaniu diagnozy.

Nie zawsze da się również uzyskać użyteczny tekst po zakończeniu żądania. Sesja może pozostać aktywna, lecz nie wykonywać aktualnie instrukcji, albo mogła zostać rozłączona przed wykonaniem odczytu. W takiej sytuacji potrzebne bywają dane z wcześniejszego monitoringu. Pomocne jest rejestrowanie istotnych zdarzeń w sposób ograniczony do wymaganego zakresu, z uwzględnieniem ochrony danych i wpływu monitoringu na wydajność.

SYS.DM_EXEC_INPUT_BUFFER — praktyczne wskazówki diagnostyczne

Analizę najlepiej rozpocząć od zapisania czasu obserwacji, identyfikatora sesji, nazwy aplikacji i użytkownika. Następnie warto porównać treść wejściową z bieżącym stanem żądania, czasem trwania oraz informacją o blokowaniu. Takie zestawienie pozwala rozdzielić kilka odmiennych sytuacji: długie wykonywanie zapytania, oczekiwanie na inną sesję, bezczynne połączenie z otwartą transakcją oraz ponawianie tego samego polecenia przez aplikację.

Przy analizie blokad trzeba sprawdzić zarówno sesję blokowaną, jak i blokującą. Odczytanie input buffer wyłącznie dla pierwszego połączenia może wskazać skutek, ale nie przyczynę. Dla obu stron powinno się zebrać tekst wejściowy, nazwę aplikacji, użytkownika, bazę danych i czas rozpoczęcia. Dopiero później można ocenić, czy problem wynika z nieoptymalnej instrukcji, zbyt długiej transakcji, braku właściwego indeksu, niewłaściwego poziomu izolacji albo błędnego sposobu obsługi połączeń.

Warto zachować ostrożność przy udostępnianiu wyników. Tekst polecenia może zawierać nazwy tabel, nazwy użytkowników, identyfikatory dokumentów lub wartości przekazane przez formularz. Raport diagnostyczny powinien ograniczać ujawnianie danych do tego, co jest potrzebne do rozwiązania problemu. Jeżeli materiał ma być przekazany poza zespół administrujący bazą, można zamaskować wartości parametrów, pozostawiając strukturę zapytania i informacje istotne dla oceny wydajności.

Przed zmianą konfiguracji lub przerywaniem sesji dobrze jest potwierdzić, że obserwowany proces rzeczywiście powoduje problem. Zakończenie niewłaściwego połączenia może przerwać transakcję, wywołać wycofanie zmian i zwiększyć czas oczekiwania innych użytkowników. SYS.DM_EXEC_INPUT_BUFFER wspiera rozpoznanie sytuacji, lecz decyzja o dalszym działaniu powinna uwzględniać znaczenie operacji, stan transakcji i możliwość bezpiecznego powtórzenia pracy.

SYS.DM_EXEC_INPUT_BUFFER — kiedy zgłosić się do serwisu

Warto zgłosić problem do serwisu, gdy odczyt z SYS.DM_EXEC_INPUT_BUFFER wskazuje na powtarzające się zapytania, długotrwałe blokady, nagłe spowolnienie aplikacji lub trudności z prawidłowym działaniem komputera, na którym wykonywana jest administracja bazą. Pomoc może być potrzebna także wtedy, gdy nie można ustalić, czy źródłem kłopotu jest sama baza, połączenie sieciowe, system operacyjny, nieprawidłowa konfiguracja programu czy awaria nośnika danych.

Przy zgłoszeniu dobrze opisać objawy, przybliżony moment ich wystąpienia, nazwę używanej aplikacji oraz to, czy problem powtarza się po ponownym uruchomieniu programu. Przydatne bywają zrzuty ekranowe komunikatów, fragmenty bezpiecznie zanonimizowanych wyników oraz informacja, czy inne operacje działają prawidłowo. Nie powinno się przekazywać haseł ani pełnych danych klientów. Warszawskie Pogotowie Komputerowe 24/7 może pomóc uporządkować diagnostykę sprzętu i oprogramowania związaną z takim zgłoszeniem.

Jeżeli problem dotyczy pojedynczego komputera, należy zwrócić uwagę na temperatury, wolne miejsce na dysku, stan aktualizacji, działanie zabezpieczeń oraz stabilność połączenia z bazą. Jeżeli objaw występuje na wielu stanowiskach jednocześnie, większe znaczenie mogą mieć ustawienia samej bazy, sieci albo aplikacji. Rozdzielenie tych obszarów przed rozpoczęciem naprawy przyspiesza ustalenie przyczyny i ogranicza ryzyko ingerencji w element, który działa prawidłowo.