Przestarzałe funkcje do wyjęcia z przybornika – część 2

W moim ostatnim poście zilustrowałem jeden powód, dla którego powinieneś przestać używać przestarzałych tabel systemowych, takich jak sysprocesses . Nie było to bezpośrednio związane z wydajnością lub po prostu postępowaniem zgodnie z udokumentowanymi najlepszymi praktykami firmy Microsoft, ale dotyczyło to decyzji, które możesz podjąć, gdy masz dostęp tylko do niektórych danych.

Tym razem chcę porozmawiać o funkcji zawartej w narzędziach klienckich SQL Server, której nie powinniśmy obecnie używać — nie tylko dlatego, że jest przestarzała, ale, co ważniejsze, ponieważ może całkowicie wyłączyć serwer:

Profil serwera SQL

Od SQL Server 2012 (i w znacznie mniejszym stopniu od SQL Server 2008) najbardziej kompletnym i elastycznym rozwiązaniem do monitorowania zdarzeń na instancji SQL Server jest Extended Events. Z drugiej strony, odkąd został wynaleziony (mniej więcej w tym samym czasie, w którym zaczynałem swoją karierę), SQL Server Profiler był jednym z najbardziej płodnych sposobów na przypadkowe rzucenie serwera na kolana.

Nie tak dawno temu przydarzyło nam się coś takiego. Deweloper wprowadził zmianę w swojej aplikacji, aby zmniejszyć liczbę wykonywanych podróży w obie strony. Uruchomili aplikację lokalnie i w naszym środowisku programistycznym, używając Profilera z filtrowanym śladem, aby potwierdzić, że ich zmiany działają zgodnie z oczekiwaniami. Przypomnę w tym miejscu, że oficjalna dokumentacja programu SQL Server Profiler zawiera następujące ostrzeżenie:

W każdym razie, kiedy wdrożyli nową wersję swojej aplikacji w środowisku produkcyjnym i skierowali na serwer produkcyjny ten sam filtrowany ślad, nie poszło to tak dobrze. Ich filtr wieloznaczny na nazwie aplikacji nie brał pod uwagę innych (o podobnych nazwach) aplikacji, które również łączą się z tym serwerem, i natychmiast zaczęli przechwytywać znacznie więcej informacji, niż mogło obsłużyć ich otwarte okno programu Profiler. Spowodowało to katastrofalny wzrost czasu połączenia dla wszystkich użytkowników i aplikacji łączących się z tą instancją. Za mało powiedziane byłoby stwierdzenie, że złożono skargi.

Kiedy ustalono winowajcę i otrzymaliśmy odpowiedź od dewelopera, widać, że czas połączenia wrócił do normy niemal natychmiast po zatrzymaniu śledzenia przez Profiler (kliknij, aby powiększyć):

Mini katastrofa programu SQL Server Profiler

Jest to zdecydowanie scenariusz, w którym stare stwierdzenie „Pracował na moim komputerze” w żaden sposób nie oznacza, że ​​będzie działać dobrze na zajętym serwerze produkcyjnym. Incydent ten doprowadził do aktywnej rozmowy na temat modyfikowania wyzwalacza logowania, który już istnieje na wszystkich serwerach w naszym środowisku, aby po prostu zablokować nazwę aplikacji, którą Profiler przekazuje w ciągu połączenia.

Może to nie jest problem Profilera. (Ale tak jest.)

Nie jestem tutaj, aby sugerować, że inne narzędzia monitorujące, w tym zdarzenia rozszerzone, nie mogą być użyte w niewłaściwy sposób do wyłączenia serwera w podobny (lub gorszy!) sposób. Istnieje wiele możliwości nieumyślnego wpłynięcia na instancję SQL Server, w naprawdę niekorzystny sposób, bez dotykania SQL Server Profiler.

Ale Profiler jest znany z tego typu symptomów ze względu na sposób, w jaki zużywa dane. Jest to interfejs użytkownika z siatką, która prezentuje nowe wiersze w momencie ich otrzymania; niestety powoduje, że SQL Server czeka, aż je wyrenderuje, zanim pozwoli SQL Serverowi przesłać więcej wierszy. To zachowanie jest podobne do tego, jak SQL Server Management Studio może spowalniać zapytania i powodować wysokie wartości ASYNC_NETWORK_IO czeka, próbując wyrenderować dużą ilość danych wyjściowych do własnej siatki. Jest to uproszczenie (i nie należy go mylić ze sposobem, w jaki można zachowywać bazowe śledzenie SQL, co Greg Gonzalez (@SQLsensei) wyjaśnia w „Don't Fear the Trace”), ale to właśnie prowadzi do typ scenariusza pokazany powyżej:to wąskie gardło ma kaskadowy wpływ na wszystkie inne procesy, które próbują zrobić cokolwiek w tej samej ścieżce kodu, co śledzone (w tym próby nawiązania połączenia).

Boisz się rozszerzonych wydarzeń?

Nie bądź. Najwyższy czas, abyśmy wszyscy porzucili Profiler i przyjęli teraźniejszość . Nie brakuje samouczków i przewodników, w tym QuickStart firmy Microsoft i kilka artykułów w tej witrynie.

Jeśli masz istniejące ślady, na których polegasz, Jonathan Kehayias (@SQLPoolBoy) ma naprawdę przydatny skrypt do konwersji istniejącego śladu na zdarzenia rozszerzone. Nadal możesz swobodnie konfigurować oryginalny ślad za pomocą interfejsu użytkownika Profiler, jeśli jest to miejsce, w którym czujesz się najwygodniej; po prostu zrób to bez łączenia się z serwerem produkcyjnym. Możesz przeczytać o tym skrypcie tutaj i zobaczyć niektóre inne artykuły Jonathana o wydarzeniach rozszerzonych tutaj.

Jeśli masz trudności z wrażeniami użytkownika, nie jesteś sam, ale jest kilka odpowiedzi:

• Erin Stellato (@erinstellato) od dawna jest spektakularną orędowniczką zdarzeń rozszerzonych i często głośno się zastanawia, dlaczego ludzie niechętnie rezygnują z Profilera i SQL Trace. Ma pewien wgląd (i zainspirował wiele komentarzy) w swoim poście z 2016 r. „Dlaczego unikasz wydarzeń rozszerzonych?”; być może jest tam jakiś wgląd w to, czy twoje powody, dla których się nie zgadzasz, są nadal (tak) aktualne w 2021 r.
  
• Istnieje XEvent Profiler wbudowany w nowoczesne wersje SSMS z równoważnym rozszerzeniem dla Azure Data Studio. Chociaż, myląco, nazwali to rozszerzenie – ze wszystkich rzeczy, które można sobie wyobrazić – Profil serwera SQL . Erin również ma kilka przemyśleń na temat tego wyboru.
  
• Erik Darling (@erikdarlingdata) utworzył sp_HumanEvents aby złagodzić ból związany z przejściem na wydarzenia rozszerzone. Jeden z moich ulubionych „trzymaj się rzeczy”, Erik opisuje sp_HumanEvents w następujący sposób:„Jeśli chcesz bezbolesnego sposobu profilowania metryk zapytań, statystyk oczekiwania, blokowania, kompilacji lub rekompilacji za pomocą zdarzeń rozszerzonych, to jest twój jednorożec”.