sql >> Databáze >  >> RDS >> Database

Rozšířené události pro SSAS

Kostky vyžadují časté sledování, protože jejich produktivita poměrně často klesá (zpomalení při vytváření dotazu, zvýšení doby zpracování). Abychom zjistili důvod poklesu, musíme monitorovat náš systém. K tomu používáme SQL Server Profiler. Společnost Microsoft však plánuje vyloučit tento nástroj pro sledování SQL v dalších verzích. Hlavní nevýhodou tohoto nástroje je náročnost na zdroje a měl by být spouštěn na produkčním serveru opatrně, protože může způsobit kritickou ztrátu produktivity systému.

Extended Events je tedy obecný systém pro zpracování událostí pro serverové systémy. Tento systém podporuje korelaci dat ze serveru SQL Server, což umožňuje získat události stavu SQL Server.

Architektura systému je zobrazena níže:

Ve skutečnosti máme balíček, který obsahuje události, cíle, akce, typy, predikáty a mapy. Na serveru jsou spuštěny relace obsahující události, cíle a akce. Nebudu podrobně popisovat architekturu, protože nápověda obsahuje explicitní popis.

Nyní se vraťme zpět k našemu SSAS. Aby vše bylo názornější, zvažte několik scénářů, které používáme pro analýzu problémů.

První scénář:Analýza zpracování krychle (Multidimenzionální krychle)

Často se jedná o případ, kdy je kostka během zpracování aktualizována po velmi dlouhou dobu, ačkoli objem dat je poměrně malý. Abychom zjistili důvod, musíme pochopit, jaký dotaz nebo jaké místo zpracování způsobuje zpomalení. Samozřejmě můžeme spustit zpracování na produkci a podívat se, co se děje, ale nejsem si jistý, že to vaši uživatelé ocení. Zde na pomoc přichází Extended Events. Spusťte naši relaci a nakonfigurujte její ukládání do souboru.

Spusťte SSMS a připojte se k SSAS a poté přepněte na Správa.

Nyní vytvoříme novou relaci:

  • Na kartě Obecné zadejte název naší relace a načtěte šablonu.
  • Události karta zobrazuje události, které nám pomohou analyzovat problémy. Karta obsahuje všechny naše staré přátele z Profileru. Vyberme následující události pro analýzu zpracování:CommandBegin , CommandEnd, Progr. essReportBegin a ProgressReportEnd, ResourseUsage.

CommandBegin , CommandEnd zobrazí začátek a konec provádění příkazu během zpracování.

Progr. essReportBegin a ProgressReportEn poskytovat rozšířené informace o délce každé události a zobrazovat načtená data, provádění SQL dotazů, délku atd.

Použití zdroje zobrazuje počet zdrojů, které byly vynaloženy na provedení dotazu, akce.

Když jsme vybrali události, můžeme přepnout na konfiguraci každé události a určit, které události musí být zobrazeny a které události musí být skryté (například můžeme skrýt ID procesu).

  • Úložiště dat tab. Zde můžeme určit, zda se mají události zobrazovat v reálném čase, nebo je zapisovat do souboru:
    • soubor_události – uložení události do souboru pro další analýzu. Zadejte maximální velikost souboru a cílovou cestu. Pokud velikost souboru překročí zadanou velikost, bude vytvořen nový soubor. Můžeme také určit počet souborů, které musí být vytvořeny (maximální počet souborů).
    • event_stream – umožňuje prohlížení událostí v reálném čase.
    • ring_buffer – určuje, že data relace musí být uložena v paměti, dokud je server spuštěn. V případě opětovného načtení budou data odstraněna.
  • Pokročilé karta umožňuje konfiguraci zdrojů (paměť, procesor) pro danou relaci.

Nakonec klikněte na OK a získat relaci. Spusťte zpracování kostky a podívejte se na zpracování podle událostí. Přepněte do režimu živých dat.

V horní části následujícího snímku obrazovky můžeme vidět události, které se právě odehrávají s naší instancí. Podrobnosti o událostech jsou uvedeny dole. Jakoukoli hodnotu podrobností události lze přidat jako samostatný sloupec nahoře. Klikněte pravým tlačítkem na vybranou hodnotu podrobností události a zobrazte je v tabulce.

Ve výsledku získáme následující pohled:

Proto Extended Events umožňují analyzovat naše zpracování v reálném čase. Dokážeme pochopit, kolik času je vynaloženo na zpracování každého objektu, kolik zdrojů je na to použito. To pomáhá dělat závěry a najít slabá místa. Kromě toho nepřetěžujeme systém a nedochází ke ztrátě produktivity.

Můžete také vytvořit relaci pomocí XMLA. Skript můžete získat na GitHubu.

Zastavení a smazání relace je možné prostřednictvím SSMS i XMLA.

  • Přes SSMS (v roce 2016 však došlo k chybě a nepodařilo se mi odstranit relaci přes rozhraní).
  • XMLA skript – lze stáhnout zde.

Toto je první část článku o Extended Events pro SSAS. Ve druhé části se zaměříme na scénář analýzy produktivity dotazů v krychli, práci s trasovacím souborem a analýzu souboru prostřednictvím Power BI.

Doporučuji také podívat se na následující blogové příspěvky:

  • Pinal Dave – SQL SERVER – SQL Profiler vs Extended Events
  • Chris Web — Profiler, Extended Events And Analysis Services. Autor článku sice uvádí, že Profiler se na produkčních serverech téměř nepoužívá, ale potvrzuje jeho problémy se zatížením serveru.
  • Brent Ozar — SQL Server Extended Events

  1. Vypočítejte počet záznamů pro každé datum mezi 2 daty

  2. Časový limit dotazu SQL Server v závislosti na klauzuli Where

  3. Jaký je správný typ SQL pro uložení .Net Timespan s hodnotami> 24:00:00?

  4. Python REST API s Flask, Connexion a SQLAlchemy – část 3