V průběhu sledování výkonu nebo odstraňování problémů, jako je pomalost systému, může být nutné najít nebo zachytit dotazy, které mají dlouhou dobu trvání, vysoký CPU nebo generují významné I/O během provádění. K získání informací o výkonu dotazů můžete použít DMV nebo Query Store, ale informace v obou zdrojích jsou souhrnné. DMV představují průměrný CPU, I/O, trvání atd. pro dotaz pouze tak dlouho, dokud je v mezipaměti. Query Store také poskytuje průměrné metriky pro mnoho zdrojů, ale jsou agregovány za definované časové okno (např. 30 minut nebo jedna hodina). Samozřejmě existují řešení monitorování třetích stran, která jsou více než schopná poskytnout vám toto vše a ještě více (jako SentryOne), ale v tomto příspěvku jsem se chtěl zaměřit na nativní nástroje.
Chcete-li porozumět výkonu dotazu pro jednotlivá spuštění a určit přesný dotaz nebo sadu dotazů, které by mohly být problémem, nejjednodušší možností je použít rozšířené události. A jedním z nejrychlejších způsobů, jak začít, je použít XEvent Profiler, který je dostupný prostřednictvím SQL Server Management Studio (od verze 17.3):
XEvent Profiler v SSMS
Základní použití
Pro XEvent Profiler jsou dvě možnosti:Standard a TSQL. Chcete-li použít kterýkoli z nich, stačí dvakrát kliknout na název. V zákulisí se vytvoří a spustí interně definovaná relace události (pokud již neexistuje) a okamžitě se otevře prohlížeč živých dat se zaměřením. Upozorňujeme, že po zahájení relace se také zobrazí pod Management | Rozšířené akce | Relace. Za předpokladu, že máte aktivitu proti serveru, měli byste začít zobrazovat záznamy v prohlížeči do pěti sekund nebo méně.
Prohlížeč živých dat (po dvojitém kliknutí spustíte standardní relaci)
Relace Standard a TSQL sdílejí některé události, přičemž Standard jich má celkem více. Zde je seznam událostí pro každou z nich:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Pokud chcete porozumět informacím o provádění dotazu, například jak dlouho trvalo spuštění dotazu nebo kolik I/O spotřeboval, pak je Standard lepší volbou kvůli dvěma dokončeným událostem. U obou relací je jediným filtrem vyloučení systémových dotazů pro události typu dávka, RPC a pozornost.
Zobrazení a ukládání dat
Pokud spustíme standardní relaci a spustíme nějaké dotazy, v prohlížeči uvidíme událost, text dotazu a další užitečné informace, jako je cpu_time, logical_reads a trvání. Jednou z výhod použití rpc_completed a sql_batch_completed je, že se zobrazí vstupní parametr. V případě, že existuje uložená procedura, která má velké rozdíly ve výkonu, může být zachycení vstupního parametru extrémně užitečné, protože můžeme porovnat provedení, které trvá déle, s konkrétní hodnotou předanou uložené proceduře. Abychom takový parametr našli, potřebujeme seřadit data podle doby trvání, což při aktivním datovém kanálu nemůžeme. Chcete-li provést jakýkoli druh analýzy, musí být přenos dat zastaven.
Zastavení přenosu dat v prohlížeči Live Viewer
Nyní, když se mé dotazy již nestřídají, mohu kliknout na sloupec trvání a události seřadit. Když poprvé kliknu, seřadí se vzestupně, a protože jsem líný a nechce se mi posouvat dolů, kliknu znovu a seřadím sestupně.
Události seřazené podle trvání sestupně
Nyní vidím všechny události, které jsem zachytil, v pořadí od nejvyšší délky po nejnižší. Pokud bych hledal konkrétní uloženou proceduru, která byla pomalá, mohl jsem buď posouvat dolů, dokud ji nenajdu (což by mohlo být bolestivé), nebo jsem mohl data seskupit nebo filtrovat. Seskupování je zde jednodušší, protože znám název uložené procedury.
Název_objektu se zobrazí v horní části prohlížeče, ale kliknutím na jakoukoli událost rpc_completed zobrazíte všechny prvky zachycené v podokně Podrobnosti. Klikněte pravým tlačítkem na název_objektu, čímž se zvýrazní, a vyberte Zobrazit sloupec v tabulce.
Přidat object_name do prohlížeče dat
V horním panelu nyní mohu kliknout pravým tlačítkem na název_objektu a vybrat Seskupit podle tohoto sloupce. Pokud rozbalím události pod usp_GetPersonInfo a poté je znovu seřadím podle trvání, nyní vidím, že provedení s PersonID=3133 mělo nejvyšší trvání.
Události seskupené podle object_name, usp_GetPersonInfo seřazené podle trvání sestupně
Filtrování dat:Použijte buď tlačítko Filtry…, možnost nabídky (Rozšířené události | Filtry…), nebo CTRL + R k zobrazení okna pro zmenšení sady výsledků na základě různých zobrazených polí. V tomto případě jsme filtrovali podle object_name =usp_GetPersonInfo, ale můžete také filtrovat podle polí jako server_principal_name nebo client_app_name, protože ty byly shromážděny.
Stojí za zmínku, že ani relace Standard ani TSQL se nezapisuje do souboru. Ve skutečnosti neexistuje žádný cíl pro žádnou relaci události (pokud jste nevěděli, že můžete vytvořit relaci události bez cíle, nyní to víte). Pokud chcete tato data uložit pro další analýzu, musíte provést jednu z následujících akcí:
- Zastavte zdroj dat a uložte výstup do souboru pomocí nabídky Extended Events (Export to | XEL File…)
- Zastavte zdroj dat a uložte výstup do tabulky v databázi prostřednictvím nabídky Rozšířené události (Exportovat do | Tabulka…)
- Změňte relaci události a přidejte soubor události jako cíl.
Možnost 1 je mým doporučením, protože vytváří soubor na disku, který můžete sdílet s ostatními a později si jej prohlédnout v Management Studio pro další analýzu. V Management Studio máte možnost filtrovat data, která nejsou relevantní, třídit je podle jednoho nebo více sloupců, seskupovat data a provádět výpočty (např. průměry). Můžete to udělat, pokud jsou data tabulka, ale musíte napsat TSQL; analýza dat v uživatelském rozhraní je jednodušší a rychlejší.
Změna relací XEvent Profiler
Relace událostí Standard a TSQL můžete upravit a provedené změny přetrvají i po restartování instance. Pokud se však relace události zruší (poté, co jste provedli úpravy), vrátí se zpět na výchozí hodnoty. Pokud zjistíte, že neustále provádíte stejné změny, navrhuji, abyste změny naskriptovali a vytvořili novou relaci události, která bude přetrvávat i po restartování. Pokud se například podíváme na dosud zachycený výstup, můžeme vidět, že byly provedeny adhoc dotazy i uložené procedury. A i když je skvělé, že vidím různé vstupní parametry pro uložené procedury, nevidím jednotlivé příkazy, které se s touto sadou událostí provádějí. Abych tyto informace získal, musel bych přidat událost sp_statement_completed.
Pochopte, že relace událostí Standard i TSQL jsou navrženy tak, aby byly nenáročné. Události statement_completed se budou spouštět častěji než události batch a rpc, takže když jsou tyto události součástí relace události, může to být více režie. Při použití událostí příkazů vysoce doporučujeme zahrnout další predikáty. Připomínáme, že události rpc a batch pouze odfiltrují systémové dotazy – žádný jiný predikát neexistuje. Obecně k těmto událostem doporučuji i doplňkové predikáty, zejména pro velké objemové zatížení.
Pokud se obáváte, zda spuštění relací Standard nebo TSQL způsobí snížení výkonu ve vašem systému, uvědomte si, že prohlížeč Live Data Viewer se odpojí, pokud v systému vytváří příliš velkou režii. To je skvělé zabezpečení, ale přesto bych byl při používání těchto relací událostí ohleduplný. Věřím, že jsou fantastickým prvním krokem pro řešení problémů, zejména pro ty, kteří jsou na SQL Server nebo Extended Events noví. Pokud však máte otevřený prohlížeč Live Data Viewer a odejdete od svého počítače, relace události pokračuje . Zastavením nebo zavřením prohlížeče Live Data Viewer se zastaví relace události, což doporučuji, až skončíte se shromažďováním dat nebo odstraňováním problémů.
Pro relace událostí, které chcete spouštět delší dobu, vytvořte samostatné relace událostí, které se zapisují do cíle event_file a mají vhodné predikáty. Pokud potřebujete více informací o tom, jak začít s Extended Events, podívejte se na relaci, kterou jsem minulý rok poskytl na SQLBits o migraci z Profileru na Extended Events.