Zastaralé funkce, které je třeba vyjmout ze sady nástrojů – část 2

Ve svém posledním příspěvku jsem ilustroval jeden důvod, proč byste měli přestat používat zastaralé systémové tabulky jako sysprocesses . Nebylo to přímo z důvodů výkonu nebo jednoduše proto, aby se řídily zdokumentovanými osvědčenými postupy společnosti Microsoft, ale více se to točilo kolem rozhodnutí, která můžete udělat, když máte přístup pouze k některým datům.

Tentokrát chci hovořit o funkci obsažené v klientských nástrojích SQL Server, kterou bychom dnes neměli používat – nejen proto, že je zastaralá, ale co je důležitější, protože má potenciál úplně zničit server:

SQL Server Profiler

Od SQL Server 2012 (a v mnohem menší míře od SQL Server 2008) jsou nejkompletnějším a nejflexibilnějším řešením pro monitorování událostí na instanci SQL Serveru Extended Events. Na druhou stranu, od doby, kdy byl poprvé vynalezen (zhruba v době, kdy jsem začínal svou kariéru), byl SQL Server Profiler jedním z nejplodnějších způsobů, jak náhodně srazit server na kolena.

Není to tak dávno, co se nám stalo něco podobného. Vývojář provedl změnu ve své aplikaci, aby snížil počet zpátečních cest, které prováděli. Spustili aplikaci lokálně a v našem vývojovém prostředí pomocí Profileru s filtrovaným trasováním, aby potvrdili, že jejich změny fungují podle očekávání. Dovolte mi, abych vám na tomto místě připomněl, že oficiální dokumentace pro SQL Server Profiler obsahuje následující varování:

Každopádně, když nasadili novou verzi své aplikace do produkce a zamířili na produkční server se stejným filtrovaným trasováním, nedopadlo to tak dobře. Jejich filtr zástupných znaků na název aplikace nebral v úvahu ostatní (podobně pojmenované) aplikace, které se také připojovaly k tomuto serveru, a okamžitě začaly zachycovat mnohem více informací, než jejich otevřené okno Profiler dokázalo zvládnout. To vedlo ke katastrofálnímu prodloužení doby připojení pro všechny uživatele a aplikace, které se k této instanci připojují. Bylo by podceněním říci, že byly podány stížnosti.

Když byl určen viník a dostali jsme odpověď od vývojáře, můžete vidět, že doba připojení se vrátila k normálu téměř okamžitě poté, co zastavili trasování Profiler (kliknutím zvětšíte):

Mini katastrofa SQL Server Profiler

Toto je rozhodně scénář, kdy staré prohlášení „pracoval na mém počítači“ v žádném případě neznamená, že bude dobře fungovat na zaneprázdněném produkčním serveru. A tento incident vedl k aktivní konverzaci o úpravě spouštěče přihlášení, které již existuje na všech serverech v našem prostředí, aby bylo možné jednoduše zablokovat název aplikace, který Profiler předává ve svém připojovacím řetězci.

Možná to není problém Profileru. (Ale tak nějak je.)

Nejsem zde, abych naznačoval, že jiné monitorovací nástroje, včetně Extended Events, nemohou být použity nevhodně ke zhroucení serveru podobným (nebo horším!) způsobem. Existuje spousta příležitostí, jak neúmyslně ovlivnit instanci SQL Serveru skutečně nepříznivým způsobem, aniž byste se dotkli SQL Server Profiler.

Profiler je však tímto typem příznaku známý díky způsobu spotřeby data. Je to uživatelské rozhraní s mřížkou, která představuje nové řádky tak, jak je přijímá; bohužel to nutí SQL Server čekat, než je vykreslí, než umožní serveru SQL přenést více řádků. Toto chování je podobné tomu, jak SQL Server Management Studio může zpomalit dotazy a způsobit vysoký ASYNC_NETWORK_IO čeká, když se pokouší vykreslit velké množství výstupu do své vlastní sítě. To je zjednodušení (a nesmí být zaměňováno se způsobem, jakým se může chovat základní SQL Trace, což Greg Gonzalez (@SQLsensei) vysvětluje v „Don't Fear the Trace“), ale je to přesně to, co vede k výše uvedený typ scénáře:toto úzké hrdlo má kaskádový efekt na všechny ostatní procesy, které se pokoušejí udělat cokoli ve stejné cestě kódu jako to, co trasujete (včetně pokusu o navázání spojení).

Bojíte se prodloužených událostí?

Nebuď. Je nejvyšší čas, abychom všichni opustili Profiler a přijali přítomnost . Neexistuje žádný nedostatek výukových programů a průvodců, včetně vlastního QuickStart společnosti Microsoft a několika článků přímo zde na tomto webu.

Pokud máte existující trasování, na které se spoléháte, Jonathan Kehayias (@SQLPoolBoy) má opravdu praktický skript pro převod existujícího trasování na Extended Events. Stále můžete bez obav nakonfigurovat původní trasování pomocí uživatelského rozhraní Profiler, pokud vám to nejvíce vyhovuje; udělejte to prosím bez připojení k produkčnímu serveru. O tomto skriptu si můžete přečíst zde a zde se podívat na některé z dalších Jonathanových článků Extended Events.

Pokud máte problémy s uživatelskou zkušeností, nejste sami, ale existuje několik odpovědí:

• Erin Stellato (@erinstellato) je již dlouho velkolepou zastánkyní Extended Events a často se nahlas diví, proč se lidé zdráhají pustit Profiler a SQL Trace obecně. Ve svém příspěvku z roku 2016 „Proč se VY vyhýbáte rozšířeným událostem?“ má určitý náhled (a inspirovala mnoho komentářů); možná tam je nějaký pohled na to, zda vaše důvody pro zdržení jsou stále (jako) platné v roce 2021.
  
• Do moderních verzí SSMS je integrován XEvent Profiler s ekvivalentním rozšířením pro Azure Data Studio. I když, matoucí, toto rozšíření nazvali – ze všech věcí, které si člověk dokáže představit – Profiler serveru SQL . Erin má také několik úvah o této volbě.
  
• Erik Darling (@erikdarlingdata) vytvořil sp_HumanEvents abyste si trochu ulevili při přechodu na rozšířené události. Erik, jeden z mých oblíbených lidí, kteří se drží věci, popisuje sp_HumanEvents takto:„Pokud chcete bezproblémový způsob profilování metrik dotazů, statistik čekání, blokování, kompilace nebo rekompilace pomocí Extended Events, toto je váš jednorožec.“