Оттеглени функции, които да извадите от кутията си с инструменти – част 2

В последната си публикация илюстрирах една причина да спрете да използвате остарели системни таблици като sysprocesses . Това не беше пряко от съображения за производителност или просто да се следват документираните най-добри практики на Microsoft, а се върти повече около решенията, които може да вземете, когато имате достъп само до някои от данните.

Този път искам да говоря за функция, включена в клиентските инструменти на SQL Server, която не бива да използваме в наши дни – не само защото е отхвърлена, но, което е по-важно, защото има потенциала да премахне напълно сървъра:

SQL Server Profiler

След SQL Server 2012 (и в много по-малка степен след SQL Server 2008) най-пълното и гъвкаво решение за наблюдение на събития в екземпляр на SQL Server е Extended Events. От друга страна, откакто беше изобретен за първи път (приблизително точно по времето, когато започнах кариерата си), SQL Server Profiler беше един от най-плодотворните начини случайно да поставите сървър на колене.

Не много отдавна ни се случи нещо подобно. Разработчик направи промяна в приложението си, за да намали броя на двупосочните пътувания, които правеха. Те стартираха приложението локално и в нашата среда за разработка, използвайки Profiler с филтрирана трасировка, за да потвърдят, че промените им работят според очакванията. Нека ви напомня в този момент, че официалната документация за SQL Server Profiler включва следното предупреждение:

Както и да е, когато внедриха новата версия на приложението си в производството и насочиха производствения сървър със същата филтрирана трасировка, не се получи толкова добре. Техният заместващ филтър за името на приложението не отчита другите (подобно наречени) приложения, които също се свързват към този сървър, и те веднага започнаха да улавят много повече информация, отколкото техният отворен прозорец на Profiler може да поеме. Това доведе до катастрофално нарастване на времето за връзка за всички потребители и приложения, свързващи се с този екземпляр. Би било подценяване да се каже, че са подадени жалби.

Когато виновникът беше определен и получихме отговор от разработчика, можете да видите, че времето на връзката се върна към нормалното почти веднага след като спряха проследяването на Profiler (щракнете, за да увеличите):

Мини-катастрофа на SQL Server Profiler

Това определено е сценарий, при който старото изявление „работи на моята машина“ по никакъв начин не означава, че ще работи добре на натоварен производствен сървър. И този инцидент доведе до активен разговор за промяна на тригера за влизане, който вече съществува във всички сървъри в нашата среда, за просто да блокира името на приложението, което Profiler предава в неговия низ за връзка.

Може би това не е проблем с Profiler. (Но някак си е така.)

Не съм тук, за да предполагам, че други инструменти за наблюдение, включително разширени събития, не могат да бъдат използвани неподходящо за сваляне на сървър по подобен (или по-лош!) начин. Има много възможности неволно да повлияете на екземпляр на SQL Server по наистина неблагоприятни начини, без да докосвате SQL Server Profiler.

Но Profiler е известен с този тип симптоми поради начина, по който консумира данни. Това е потребителски интерфейс с мрежа, която представя нови редове, докато ги получава; за съжаление, това кара SQL Server да изчака, докато ги рендира, преди да позволи на SQL Server да предаде повече редове. Това поведение е подобно на това как SQL Server Management Studio може да забави заявките и да причини високо ASYNC_NETWORK_IO изчаква, докато се опитва да изведе голямо количество продукция в собствената си мрежа. Това е опростяване (и не трябва да се бърка с начина, по който базовата SQL Trace може да бъде накарана да се държи, което Грег Гонзалес (@SQLsensei) обяснява в „Не се страхувайте от следата“), но точно това води до типа сценарий, показан по-горе:това тесно място има каскаден ефект върху всички други процеси, които се опитват да направят нещо в същия кодов път като този, който проследявате (включително опитите за установяване на връзка).

Страхуваш се от продължителни събития?

Не бъди. Крайно време е всички да се откажем от Profiler и да прегърнем настоящето . Няма недостиг на уроци и ръководства, включително собствения QuickStart на Microsoft и няколко статии точно тук на този сайт.

Ако имате съществуващи трасета, на които разчитате, Джонатан Кехая (@SQLPoolBoy) има наистина удобен скрипт за преобразуване на съществуваща трасировка в разширени събития. Все още можете да се чувствате свободни да конфигурирате оригиналното проследяване с потребителския интерфейс на Profiler, ако това ви е най-удобно; просто моля, направете го без да се свързвате с производствен сървър. Можете да прочетете за този скрипт тук и да видите някои от другите статии на Джонатан за разширени събития тук.

Ако изпитвате затруднения с потребителското изживяване, не сте сами, но има някои отговори:

• Ерин Стелато (@erinstellato) отдавна е грандиозен защитник на разширените събития и често се чуди на глас защо хората не са склонни да се откажат от Profiler и SQL Trace като цяло. Тя има известна представа (и вдъхнови много коментари) в публикацията си от 2016 г. „Защо избягвате разширени събития?“; може би има някаква представа за това дали причините ви да издържите все още са валидни през 2021 г.
  
• Има XEvent Profiler, вграден в съвременните версии на SSMS, с еквивалентно разширение за Azure Data Studio. Въпреки че, объркващо, те нарекоха това разширение – от всички неща, които човек може да си представи – SQL Server Profiler . Ерин също има няколко мисли относно този избор.
  
• Ерик Дарлинг (@erikdarlingdata) създаде sp_HumanEvents за да облекчите част от болката от преминаването към разширени събития. Един от любимите ми хора, които се придържат към точката, Ерик описва sp_HumanEvents както следва:„Ако искате безболезнен начин за профилиране на показателите на заявката, статистиката за чакане, блокиране, компилиране или прекомпилиране с разширени събития, това е вашият еднорог.“