SQL Server Monitor aktivity: Kompletní průvodce pro správce databází [2026]

1. Úvod

1.1 Co je SQL Server ActivityMonitor?

SQL Server Monitor aktivity je vestavěný diagnostický nástroj v SQL Server Management Studio, které zobrazuje informace o SQL Server procesy a jejich vliv na výkon serveru. Umožňuje vám sledovat SQL Server procesy, monitorovat čekání na zdroje, analyzovat náročné dotazy a sledovat vzorce I/O – to vše z jednoho rozhraní.

1.2 Proč používat SQL Server ActivityMonitor?

Sledování aktivity slouží jako vaše první linie obrany při řešení problémů s výkonem. Poskytuje okamžitý přehled o tom, co se děje na vašem SQL Server instance bez nutnosti složitých T-SQL dotazů nebo nástrojů třetích stran.

Tento nástroj vyniká v tom, že vám pomáhá rychle identifikovat běžné problémy, jako jsou blokující relace, dotazy náročné na CPU, nadměrné provádění dotazů a úzká hrdla I/O. Když uživatelé nahlásí, že aplikace je pomalá nebo nereaguje, Activity Monitor vám pomůže určit, zda je viníkem databázový server.

Pro správce databází, kteří nepracují s SQL Server Activity Monitor nabízí denně přístupný vstupní bod pro pochopení aktivity serveru. I zkušení správci databází jej používají jako výchozí bod pro analýzu výkonu.

1.3 Sledování aktivity vs. jiné monitorovací nástroje

I když je Monitor aktivity cenný, je důležité pochopit, jak si vede v porovnání s jinými možnostmi monitorování:

Sledování aktivity vs. sp_WhoIsActive: Monitor aktivity nabízí grafické rozhraní s více panely, zatímco sp_WhoIsActive je komplexní uložená procedura, která nabízí podrobnější informace v jedné sadě výsledků. Sp_WhoIsActive zobrazuje konkrétní typy čekání, které Monitor aktivity seskupuje, a poskytuje podrobnější informace o blokování.

Monitor aktivity vs. sp_who2: Tradiční příkaz sp_who2 zobrazuje základní informace o relaci, ale Activity Monitor jde ještě dál a zobrazuje statistiky čekání, náročné dotazy a metriky I/O v uspořádaném, vizuálním formátu.

Sledování aktivity vs. nástroje třetích stran: Komerční monitorovací řešení, jako je SolarWinds Database Performance Analyzer, nabízejí historické sledování, upozornění a pokročilou analýzu, které Activity Monitor postrádá. Activity Monitor však nevyžaduje žádné další náklady ani instalaci.

1.4 Klíčové výhody pro správce databází

Monitor aktivity nabízí několik výhod, díky nimž je nezbytným nástrojem pro správu databází:

• Nulové náklady: Jako vestavěný SQL Server Funkce Management Studio nevyžaduje žádné licenční poplatky ani úsilí spojené s nasazením.
• Sledování v reálném čase: Sledujte aktuální aktivitu serveru v reálném čase s nastavitelnými intervaly aktualizace od 1 sekundy do 1 hodiny.
• Integrované akce: Kliknutím pravým tlačítkem myši na procesy ukončíte relace, zobrazíte podrobnosti dotazu nebo je spustíte. SQL Server Trasování profileru – vše přímo z nástroje.
• Více perspektiv: Prohlédněte si stav serveru z různých úhlů pohledu prostřednictvím pěti specializovaných panelů, z nichž každý se zaměřuje na specifické aspekty výkonu.
• Rychlé odstraňování problémů: Identifikujte nejčastější problémy s výkonem během několika minut a zrychlete tak průměrnou dobu jejich řešení.
• Nízká vstupní bariéra: Pro efektivní používání nástroje nejsou potřeba žádné pokročilé znalosti, i když hlubší SQL Server odborné znalosti pomáhají s interpretací.

2. Začínáme s Monitorem aktivity

Než budete moci efektivně využívat Sledování aktivity, musíte porozumět předpokladům, požadovaným oprávněním a různým metodám pro spuštění nástroje.

2.1 Předpoklady a systémové požadavky

Chcete-li použít SQL Server Monitor aktivity, který potřebujete SQL Server Management Studio (SSMS) nainstalované na vašem lokálním počítači nebo jump serveru. Nástroj Activity Monitor byl v roce 2004 výrazně přepracován. SQL Server 2008, takže informace v této příručce platí pro SQL Server Verze z roku 2008 a novější.

Musíte mít síťové připojení k SQL Server instanci, kterou chcete monitorovat. U databází hostovaných v cloudu budete pro přístup k instanci obvykle potřebovat připojení VPN nebo správně nakonfigurovaná pravidla firewallu.

Monitor aktivity funguje se všemi edicemi SQL Server, včetně verzí Express, Standard a Enterprise. Samotný nástroj běží na klientském počítači v rámci SSMS, takže prostředky serveru jsou ovlivněny pouze monitorovacími dotazy, které provádí.

2.2 Požadovaná oprávnění

Pro správné fungování Monitoru aktivity jsou nezbytná správná oprávnění. Bez příslušných oprávnění se může zobrazit prázdný displej nebo se mohou objevit chyby „přístup odepřen“.

2.2.1 Oprávnění k zobrazení stavu serveru

Jedno ZOBRAZIT STAV SERVERU Oprávnění je primárním požadavkem pro používání Sledování aktivity. Toto oprávnění na úrovni serveru vám umožňuje zobrazit všechny aktivní procesy a jejich přidružené metriky.

Pro udělení tohoto oprávnění může správce serveru spustit:

GRANT VIEW SERVER STATE TO [YourLoginName];

Bez možnosti VIEW SERVER STATE se může Monitor aktivity otevřít, ale v žádném ze svých panelů nezobrazovat žádná data.

2.2.2 Oprávnění na úrovni databáze

Pro zobrazení informací v podokně V/V datových souborů potřebujete další oprávnění. Konkrétně musíte mít jednu z následujících kombinací:

• VYTVOŘTE DATABÁZE povolení, nebo
• ZMĚNA JAKÉKOLI DATABÁZE povolení, nebo
• ZOBRAZIT JAKOUKOLI DEFINICI povolení

Tato oprávnění musí být kombinována s ZOBRAZIT STAV SERVERU pro plnou funkčnost Monitoru aktivity.

2.2.3 Řešení problémů s oprávněními

Pokud se Monitor aktivity otevře, ale nezobrazuje žádná data, jsou nejčastější příčinou oprávnění. Zkontrolujte, zda má vaše přihlašovací údaje na úrovni serveru uděleno oprávnění VIEW SERVER STATE. Svá oprávnění můžete ověřit spuštěním:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

Vyhledejte ve sloupci permission_name položku „VIEW SERVER STATE“. Pokud chybí, obraťte se na administrátora databáze, aby vám ji udělil.

2.3 Jak otevřít Sledování aktivity v SSMS

SQL Server Management Studio nabízí čtyři různé metody spuštění Monitoru aktivity, což vám dává flexibilitu na základě vašich preferencí pracovního postupu.

2.3.1 Metoda 1: Z panelu nástrojů

Nejrychlejší způsob, jak otevřít Monitor aktivity, je pomocí ikony na panelu nástrojů:

1. Připojte se ke svému SQL Server instance v SQL Server Studio pro správu.
2. Najděte ikonu Sledování aktivity ve standardním panelu nástrojů (připomíná sloupcový graf se zeleným tlačítkem přehrávání).
3. Kliknutím na ikonu spusťte Sledování aktivity.

Tato metoda je nejrychlejší, pokud již pracujete v SSMS a potřebujete rychle zkontrolovat aktivitu serveru.

2.3.2 Metoda 2: Z Průzkumníka objektů

Sledování aktivity můžete také spustit přímo z Průzkumníka objektů:

1. V Průzkumníku objektů vyhledejte SQL Server instanci, kterou chcete monitorovat.
2. Klikněte pravým tlačítkem myši na název instance.
3. vybrat Activity Monitor z kontextové nabídky.

Tato metoda je užitečná při připojování k více serverům, protože zajišťuje, že monitorujete správnou instanci.

2.3.3 Metoda 3: Použití klávesové zkratky

Pro uživatele zaměřené na práci s klávesnicí, SQL Server Management Studio nabízí speciální zkratku:

1. Ujistěte se, že je aktivní okno SSMS a že jste připojeni k instanci.
2. Pro média Ctrl + Další + A.
3. Pro aktuálně vybranou instanci v Průzkumníku objektů se otevře Monitor aktivity.

Upozorňujeme, že Sledování aktivity se připojí k instanci serveru, kterou jste vybrali v Průzkumníku objektů, proto se před použitím této zkratky ujistěte, že jste vybrali správnou instanci.

2.3.4 Metoda 4: Z nabídky Možnosti (Konfigurace spouštění)

Pokud často používáte Sledování aktivity, můžete nakonfigurovat SSMS tak, aby se automaticky spouštěl při každém spuštění aplikace:

1. In SQL Server Management Studio, přejděte na Tools -> možnosti.
2. V dialogovém okně Možnosti rozbalte životní prostředíA poté vyberte Startup.
3. z Při spuštění rozbalovací seznam, vyberte Otevřete Průzkumník objektů a Sledování aktivity.
4. vybrat OK.

Při příštím spuštění SSMS a připojení k serveru se automaticky otevře Monitor aktivity spolu s Průzkumníkem objektů.

3. Principy panelů Sledování aktivity

Monitor aktivity organizuje informace do pěti rozbalitelných panelů, z nichž každý nabízí jiný pohled na aktivitu serveru. Pochopení toho, co každý panel zobrazuje, je klíčové pro efektivní řešení problémů.

3.1 Panel Přehled

Panel Přehled zobrazuje čtyři grafy v reálném čase, které vám poskytnou rychlý přehled o vašem zdravotním stavu. SQL Server například. Tyto grafy se aktualizují v konfigurovatelném intervalu a pomáhají vám na první pohled identifikovat abnormální vzorce.

3.1.1 % času procesoru

Tento graf znázorňuje procentuální podíl času, který procesor stráví prováděním nečinných vláken pro daný SQL Server instance napříč všemi CPU. Hodnota představuje SQL Servervyužití procesoru, nikoli využití CPU celého serveru.

Pokud se vám trvale zobrazuje využití procesoru na 100 % nebo blízko něj, váš server je omezen využitím CPU. To může znamenat neefektivní dotazy, chybějící indexy nebo nedostatečnou hardwarovou kapacitu. Pomocí podokna Nedávné drahé dotazy zjistěte, které dotazy spotřebovávají nejvíce CPU.

3.1.2 Čekající úkoly

Tato metrika zobrazuje počet úloh, které čekají na uvolnění zdrojů, než mohou pokračovat. Úlohy mohou čekat na CPU, I/O operace, paměť nebo zámky.

Trvale vysoký počet čekajících úloh naznačuje soupeření o zdroje. Podokno Čekání na zdroje poskytuje více podrobností o tom, jaké typy zdrojů způsobují čekání.

3.1.3 Databázové I/O operace (MB/s)

Tento graf znázorňuje rychlost přenosu dat mezi pamětí a diskem. Kombinuje čtení i zápis a měří se v megabajtech za sekundu.

Špičky v databázových I/O operacích mohou naznačovat dotazy provádějící prohledávání velkých tabulek, nadměrnou aktivitu protokolování nebo operace s kontrolními body. Panel Datový soubor I/O rozděluje aktivitu I/O podle databáze a souboru.

3.1.4 Počet dávkových požadavků/s

Tato metrika představuje počet SQL Server dávky přijaté instancí za sekundu. Dávka může být jeden příkaz nebo více příkazů odeslaných společně.

Tato hodnota vám dává představu o celkové aktivitě serveru. Náhlé poklesy dávkových požadavků během běžné pracovní doby mohou naznačovat problémy s připojením aplikací nebo problémy, na kterých se uživatel potýká.

3.1.5 Nastavení intervalů aktualizace

Můžete si přizpůsobit, jak často Sledování aktivity aktualizuje svá data:

1. Klikněte pravým tlačítkem myši kamkoli v podokně Přehled.
2. vybrat Interval obnovení.
3. Vyberte interval z předdefinovaných hodnot: 1 sekunda, 5 sekund, 10 sekund (výchozí), 30 sekund, 1 minuta nebo 1 hodina.

Nastavení intervalů aktualizace kratších než 10 sekund zvyšuje režijní náklady na monitorování serveru. U produkčních systémů s vysokou zátěží zvažte použití intervalů 30 sekund nebo delších, abyste minimalizovali dopad.

3.2 Panel Procesy

Panel Procesy zobrazuje informace o aktuálně spuštěných relacích na vašem SQL Server instance. Toto podokno je nezbytné pro identifikaci toho, kdo co dělá, a pro odhalení blokujících problémů.

3.2.1 Pochopení procesních informací

Každý řádek v podokně Procesy představuje aktivní relaci na serveru. Podokno zobrazuje relace ze všech databází a všechny uživatele, což vám poskytuje komplexní přehled o aktivitě serveru.

Zobrazené informace zahrnují přihlašovací jméno, název aplikace, název hostitele, databázi, ke které se přistupuje, a aktuální příkaz. To vám pomůže propojit aktivitu databáze s konkrétními uživateli nebo aplikacemi.

3.2.2 Vysvětlení klíčových sloupců

Pochopení klíčových sloupců vám pomůže efektivně interpretovat informace o procesu:

• ID relace: Jedinečný identifikátor pro každé připojení. Systémové procesy používají negativní ID relací.
• Uživatelský proces: Označuje, zda se jedná o uživatelskou relaci (Ano) nebo systémový proces (Ne).
• Přihlásit se: Jedno SQL Server přihlašovací jméno nebo účet Windows přidružený k relaci.
• Databáze: Aktuální kontext databáze pro relaci.
• Stav úkolu: Zobrazuje, co se relace aktuálně děje (BĚŽÍ, POZASTAVENO, SPANÍ atd.).
• příkaz: Typ prováděného příkazu (SELECT, INSERT, UPDATE atd.).
• Aplikace: Název aplikace, která vytvořila připojení.
• Čekací doba: Jak dlouho (v milisekundách) relace čeká na zdroje.
• Typ čekání: Konkrétní typ zdroje, na který relace čeká.
• Čas procesoru: Celkový čas spotřebovaný CPU touto relací od připojení.
• Využití paměti: Množství paměti (v KB) aktuálně přidělené relaci.

3.2.3 Procesy filtrování a třídění

Panel Procesy obsahuje výkonné funkce filtrování, které vám pomohou soustředit se na relevantní relace:

1. Klikněte na šipku rozbalovací nabídky v libovolném záhlaví sloupce.
2. Filtr zobrazuje dostupné hodnoty pro daný sloupec, včetně Vše , Blanks, a NonBlanks.
3. Vyberte konkrétní hodnoty pro filtrování zobrazení pouze na tyto relace.

Můžete například filtrovat Stav úkolu zobrazit pouze BĚŽÍCÍ relace nebo filtrovat Databáze zobrazit aktivitu v konkrétní databázi.

Můžete také seřadit podle libovolného sloupce kliknutím na jeho záhlaví. Kliknutím jednou seřadíte vzestupně, dvakrát seřadíte sestupně.

3.2.4 Identifikace blokování a zablokovaných relací

Panel Procesy vám pomůže identifikovat blokující scénáře, kdy jedna relace brání ostatním v pokračování:

• Blokováno uživatelem: Zobrazuje ID relace, která tuto relaci blokuje. Pokud tento sloupec obsahuje hodnotu, relace čeká na zámek držený jinou relací.
• Blokátor hlavy: Zobrazí se „1“, pokud tato relace blokuje ostatní, ale sama blokována není. Toto je hlavní příčina blokovacího řetězce.

Chcete-li prozkoumat problém s blokováním, nejprve identifikujte blokátor headu (relaci označenou ve sloupci Head Blocker číslicí „1“), poté prozkoumejte, co dělá, a rozhodněte se, zda jej necháte dokončit, nebo jej ukončíte.

3.2.5 Akce procesu (ukončení, podrobnosti, trasování)

Sledování aktivity umožňuje provádět akce v jednotlivých relacích:

1. Klikněte pravým tlačítkem myši na libovolnou relaci v podokně Procesy.
2. Uvidíte několik možností:
   • Detaily: Zobrazuje poslední příkaz provedený v této relaci.
   • Proces zabití: Ukončí relaci (používejte s opatrností).
   • Trasování procesu v SQL Server profilovač: Barky SQL Server profil a automaticky filtruje tak, aby zobrazovala pouze aktivitu z této relace.

Možnost Podrobnosti zobrazuje text příkazu, ale mějte na paměti, že se jedná o poslední příkaz provedený – nemusí být stále spuštěn. Možnost Trasování je obzvláště užitečná, když potřebujete vidět kompletní sekvenci příkazů, které relace provádí.

3.3 Podokno čekání na zdroje

Panel Čekání na zdroje shrnuje statistiky čekání a ukazuje, na jaké typy relací zdrojů se nejčastěji čeká. Tyto informace jsou klíčové pro diagnostiku úzkých míst výkonu.

3.3.1 Pochopení statistik čekání

Kdy SQL Server Pokud server nemůže okamžitě schválit požadavek na zdroj (například zámek, čas CPU nebo paměť), žádající úloha přejde do stavu čekání. Statistiky čekání sledují tyto doby čekání a pomáhají vám pochopit, kdy server tráví čas čekáním, místo aby pracoval.

Podokno Čekání na zdroje shromažďuje data ze zobrazení dynamické správy systému, jako jsou sys.dm_os_wait_stats a sys.dm_exec_requests. V každém intervalu aktualizace vypočítává rozdíl mezi aktuálním a předchozím snímkem a zobrazuje míru akumulace pro každý typ čekání.

3.3.2 Kategorie čekání

Monitor aktivity seskupuje stovky jednotlivých typů čekání do širších kategorií pro zjednodušení interpretace:

• CPU: Úlohy čekající na uvolnění času CPU.
• Západka vyrovnávací paměti: Čeká na krátkodobé synchronizační objekty chránící přístup k datovým stránkám v paměti. Tato kategorie zahrnuje čekání na západky stránek (PAGELATCH_*).
• Lock: Čekání způsobené relacemi, které drží zámky potřebné pro jiné relace.
• Paměť: Čeká na přidělení paměti potřebné pro operace jako řazení a hašování.
• Síťové vstupy/výstupy: Čeká na odesílání dat klientům nebo na příjem dat od klientů.
• SQL CLR: Čekání související se spuštěním Common Language Runtime.

Toto seskupení sice zjednodušuje zobrazení, ale zároveň zakrývá důležité detaily. Například „Buffer Latch“ může seskupovat čekání PAGELATCH_SH, PAGELATCH_UP a PAGELATCH_EX, které mají různé důsledky pro výkon.

3.3.3 Interpretace doby čekání a úkolů čekání

V podokně Čekání na zdroje se pro každou kategorii čekání zobrazují dvě klíčové metriky:

• Kumulativní doba čekání (ms): Celkový počet milisekund nashromážděných během aktuálního intervalu aktualizace pro tuto kategorii čekání.
• Čekající úkoly: Počet úloh, které aktuálně čekají na zdroje v této kategorii.

Obzvláště zajímavá je hodnota doby čekání. Pokud máte 10sekundový interval aktualizace a vidíte dobu čekání 20 000 ms pro kategorii, znamená to více souběžných čekání (20 000 ms / 10 000 ms = průměr 2 souběžných čekání během intervalu).

3.3.4 Identifikace úzkých míst ve výkonnosti

Pomocí podokna Čekání na zdroje zjistěte, kde váš server čeká nejvíce času:

1. Rozbalte podokno Čekání na zdroje.
2. Sledujte kategorie čekání, které shromažďují nejvyšší čekací doby.
3. Seřadit podle Kumulativní doba čekání zjistit, které zdroje jsou nejvíce omezené.

Čekání na vysokou hodnotu Buffer Latch často naznačuje soupeření o datové stránky v paměti, což může naznačovat úzká hrdla I/O nebo soupeření o dočasné databázi. Čekání na vysokou hodnotu Lock poukazuje na problémy s blokováním. Čekání na vysokou hodnotu paměti naznačuje nedostatek paměťových grantů pro operace s dotazy.

3.4 Panel I/O datových souborů

Panel I/O datových souborů zobrazuje aktivitu disku pro každý databázový soubor na vašem serveru, což vám pomáhá identifikovat úzká hrdla I/O a pochopit vzorce využití disku.

3.4.1 Pochopení metrik I/O

Panel Vstup/výstup datových souborů zobrazuje pro každý databázový soubor několik metrik:

• Databáze: Název databáze.
• Typ souboru: Buď Data (včetně tabulek a indexů), nebo Log (transakční protokol).
• Logický název: Logický název souboru, jak je definován v SQL Server.
• Čtení MB/s: Rychlost čtení dat z tohoto souboru.
• Zapsáno MB/s: Rychlost zápisu dat do tohoto souboru.
• Doba odezvy (ms): Průměrná doba odezvy pro I/O operace s tímto souborem.

Tyto metriky se aktualizují ve stejném intervalu jako podokno Přehled, což vám poskytuje přehled o aktivitě disku v reálném čase.

3.4.2 Identifikace úzkých míst I/O

Sledujte tyto vzorce, které naznačují problémy s výkonem I/O:

• Vysoká doba odezvy: Doby odezvy trvale nad 15–20 ms naznačují pomalé diskové subsystémy. Doby odezvy nad 50 ms naznačují vážná úzká hrdla I/O operací.
• Nevyvážené zatížení: Pokud jeden datový soubor vykazuje výrazně vyšší rychlosti I/O než ostatní ve stejné databázi, může být pro rozložení zátěže výhodné přidat další soubory.
• Nadměrná aktivita dočasné databáze: Vysoké rychlosti I/O u souborů tempdb často naznačují, že dotazy vytvářejí velké sady mezilehlých výsledků nebo používají neefektivní plány provádění.

3.4.3 Analýza databázových souborů

Pomocí podokna V/V datových souborů pochopíte, jak vaše databáze využívají diskové prostředky:

1. Rozbalte podokno Vstupně-výstupní operace s datovými soubory.
2. Seřadit podle MB/s Čtení or MB/s zapsáno identifikovat nejaktivnější soubory.
3. Poznamenejte si všechny soubory s trvale vysokou aktivitou nebo dlouhou dobou odezvy.
4. Porovnejte tyto informace s podoknem Nedávné nákladné dotazy a zjistěte, které dotazy způsobují zátěž I/O.

3.5 Panel Nedávné drahé dotazy

Panel Nedávné drahé dotazy je často nejcennějším panelem pro řešení problémů s výkonem aplikací. Zobrazuje dotazy, které spotřebovávají značné množství serverových prostředků, což vám pomáhá identifikovat příležitosti k optimalizaci.

3.5.1 Principy metrik dotazů

Sledování aktivity zobrazuje pro každý náročný dotaz několik metrik:

• Počet provedení/min: Kolikrát byl dotaz proveden během poslední minuty.
• Procesor (ms/s): Čas CPU spotřebovaný tímto dotazem za sekundu.
• Fyzické čtení/s: Počet čtení fyzického disku za sekundu pro tento dotaz.
• Logické zápisy/s: Počet logických zápisů (do mezipaměti vyrovnávací paměti) za sekundu.
• Logické čtení/s: Počet logických čtení (z mezipaměti vyrovnávací paměti) za sekundu.
• Průměrná doba trvání (ms): Průměrná doba provedení tohoto dotazu.
• Počet plánů: Počet plánů spuštění v mezipaměti pro tento dotaz.

Tyto metriky vám pomohou pochopit nejen, které dotazy jsou drahé, ale proč jsou drahé a jak často jezdí.

3.5.2 Možnosti řazení

Panel Nedávné drahé dotazy můžete seřadit podle různých metrik a najít tak různé typy problémů:

1. Kliknutím na libovolné záhlaví sloupce seřadíte podle dané metriky.
2. Mezi běžné strategie třídění patří:
   • Seřadit podle CPU: Najděte dotazy, které spotřebovávají nejvíce času procesoru.
   • Seřadit podle Počet provedení/min: Identifikujte dotazy, které se spouštějí nadměrně často.
   • Seřadit podle fyzického čtení: Najít dotazy způsobující nejvíce diskových I/O operací.
   • Seřadit podle průměrné délky trvání: Vyhledejte dlouhotrvající dotazy.

Při řešení problémů s výkonem zkuste řadit podle více sloupců, abyste získali různé perspektivy. Skutečným problémem by mohl být dotaz s mírným využitím CPU, ale extrémně vysokým počtem spuštění za minutu.

3.5.3 Zobrazení textu dotazu

Chcete-li zobrazit skutečný SQL příkaz za náročným dotazem:

1. V podokně Nedávné drahé dotazy klikněte pravým tlačítkem myši na řádek dotazu.
2. vybrat Upravit text dotazu.
   
3. Otevře se nové okno dotazu zobrazující kompletní příkaz SQL.
   

To vám umožní prozkoumat logiku dotazu a identifikovat potenciální příležitosti k optimalizaci. Text dotazu pak můžete zkopírovat pro testování upravených verzí.

3.5.4 Analýza realizačních plánů

Realizační plány vám ukážou, jak na to SQL Server provede dotaz a odhalí neefektivity, jako jsou chybějící indexy nebo nevhodné typy spojení:

1. V podokně Nedávné drahé dotazy klikněte pravým tlačítkem myši na řádek dotazu.
2. vybrat Zobrazit plán provedení.
   
3. SQL Server Management Studio zobrazuje grafické znázornění provádění dotazu.
   

Hledejte operace, které spotřebovávají velké procento nákladů na dotazy, varování o chybějících statistikách nebo indexech a neočekávané operace prohledávání tabulek. Ty často naznačují, na co by se mělo zaměřit optimalizační úsilí.

3.5.5 Identifikace problematických dotazů

V podokně Nedávné drahé dotazy sledujte tyto vzorce:

• Nadměrné popravy: Dotaz prováděný tisíckrát za minutu může naznačovat problém s dotazem N+1, kdy aplikační kód volá databázi uvnitř smyčky.
• Vysoké fyzické čtení: Dotazy s vysokou fyzickou rychlostí čtení se často dostávají na disk, což naznačuje chybějící indexy nebo špatně napsané dotazy.
• Vysoký CPU s nízkou dobou trvání: Mnoho rychlých dotazů, které spotřebovávají spoustu CPU, může mít stejný dopad na výkon serveru jako několik pomalých dotazů.
• Vícenásobné počty plánů: Dotazy s mnoha plány spuštění mohou trpět problémy s parametrickým sniffingem nebo neparametrizované dotazy způsobující nafouknutí mezipaměti plánu.

4. Použití nástroje Activity Monitor pro řešení problémů s výkonem

Sledování aktivity skutečně zazáří, když ho používáte systematicky k diagnostice a řešení problémů s výkonem. Tato část se zabývá běžnými scénáři řešení problémů a jejich řešením.

4.1 Diagnostika nadměrného provádění dotazů

Jedním z nejčastějších problémů s výkonem jsou dotazy spouštěné mnohem častěji, než je nutné, často kvůli problémům s návrhem aplikace.

4.1.1 Identifikace opakovaných dotazů

Chcete-li odhalit dotazy, které se provádějí příliš často:

1. Otevřete Sledování aktivity a rozbalte Nedávné drahé dotazy panel.
2. Seřadit podle Spuštění/min (počet provedení za minutu).
3. Hledejte dotazy nahoře s počty provedení, které se zdají být nepřiměřeně vysoké.
4. Klikněte pravým tlačítkem myši na podezřelý dotaz a vyberte Upravit text dotazu prozkoumat SQL příkaz.

Pokud například vidíte jednoduchý příkaz SELECT, který se provádí 37 000krát za minutu, zamyslete se nad tím, zda aplikace skutečně potřebuje volat tento dotaz tak často. Většina dotazů, které se provádějí více než několik tisíckrát za minutu, si zaslouží prošetření.

4.1.2 Analýza hlavních příčin

Nadměrné provádění dotazů obvykle pramení z těchto problémů:

• Problém s dotazem N+1: Kód aplikace načte seznam položek a poté pro každou položku provede samostatný dotaz, aby načetl související data. Tím se vytvoří N dalších dotazů, kde N je počet položek.
• Chybí ukládání do mezipaměti: Aplikace dotazuje databázi na data, která se mění jen zřídka, místo aby je ukládala do mezipaměti aplikace.
• Smyčky dotazování: Kód opakovaně dotazuje databázi a kontroluje změny stavu, místo aby používal oznámení o změnách nebo fronty zpráv.
• Neefektivnost ORM: Entity Framework a podobné nástroje někdy generují neefektivní vzory dotazů, když vývojáři nechápou, jak se jejich kód převádí do SQL.

Chcete-li určit hlavní příčinu, vystopujte dotaz zpět k kódu aplikace. Všimněte si editaci videa a Přihlášení sloupce v podokně Procesy při spuštění dotazu. Můžete také kliknout pravým tlačítkem myši na proces a vybrat Trasování procesu v SQL Server profil abyste viděli vzorec volání.

4.1.3 Řešení a osvědčené postupy

Jakmile identifikujete nadměrné provádění dotazů, zvažte tato řešení:

• Dávkové zpracování: Upravte kód aplikace tak, aby načítal více položek v jednom dotazu pomocí spojení nebo klauzulí IN, namísto provádění samostatných dotazů ve smyčce.
• Ukládání výsledků do mezipaměti: Často přístupná mezipaměť, zřídka se měnící data v paměti aplikace s odpovídajícími časy vypršení platnosti.
• Dychtivé načítání: Nakonfigurujte ORM tak, aby používaly strategie rychlého načítání, které načítají související data v menším počtu dotazů a jsou efektivnější.
• Parametrizace dotazu: Zajistěte, aby dotazy používaly parametry, nikoli zřetězení hodnot, což zlepšuje opětovné použití mezipaměti plánu a snižuje režijní náklady na kompilaci.

4.2 Zkoumání problémů s blokováním

K blokování dochází, když jedna relace drží zámky, které brání pokračování ostatních relací. To se projevuje pomalou dobou odezvy aplikací a frustrací uživatelů.

4.2.1 Identifikace blokovacích řetězců

Detekce a analýza blokování:

1. Otevřete Sledování aktivity a rozbalte Procesy panel.
2. Hledejte relace s hodnotami v Blokováno uživatelem sloupec – tyto čekají na zámky držené jinými relacemi.
3. Najít relace s '1' v Blokátor hlavy sloupec – to jsou hlavní příčiny blokování řetězců.
4. Poznámka: ID relace blokátoru hlavy.
5. Klikněte pravým tlačítkem myši na relaci blokování hlav a vyberte Detaily aby se zjistilo, jaký příkaz se provádí.

Pochopení blokovacího řetězce je klíčové. Blokujícím faktorem je relace, kterou je třeba prozkoumat, nikoli blokované relace navazující na relace.

4.2.2 Pochopení typů zámků

Jedno Typ čekání Sloupec v podokně Procesy označuje, na jaký typ zámku čekají blokované relace:

• LCK_M_X: Čekání na exkluzivní zámek, obvykle způsobené operacemi UPDATE, DELETE nebo INSERT.
• LCK_M_S: Čekání na sdílený zámek, obvykle příkazy SELECT čekající na uvolnění exkluzivních zámků.
• LCK_M_U: Čekání na zámek aktualizace, typ mezilehlého zámku používaný během aktualizací.
• LCK_M_IX: Čekání na exkluzivní zámek Intent, které indikuje soupeření o zámek na úrovni stránky nebo řádku.

Jedno Čekací zdroj Sloupec zobrazuje, který databázový objekt je uzamčen, což vám pomůže pochopit, která tabulka nebo index je součástí soupeření.

4.2.3 Řešení problémů s blokováním

Jakmile identifikujete blokující relaci a co dělá, máte několik možností:

1. Počkejte na dokončení: Pokud blokátor headu spouští legitimní dotaz, který bude brzy dokončen, může být nejlepší nechat ho dokončit přirozeně.
2. Ukončit relaci: Pokud je blokování hlaviček zaseknuté nebo spouští dotaz, který by měl být zrušen:
   • V podokně Procesy klikněte pravým tlačítkem myši na relaci.
   • vybrat Proces ukončení.
   • Potvrďte akci v dialogovém okně.
3. Optimalizační dotazy: Pokud se blokování opakuje u stejných dotazů, optimalizujte je tak, aby se zkrátila doba trvání uzamčení.
4. Úprava úrovní izolace: Zvažte použití READ COMMITTED SNAPSHOT IZOLATION pro snížení blokování v úlohách s velkým množstvím čtení.
5. Ladění indexu: Přidáním indexů zrychlíte dotazy a zkrátíte dobu, po kterou drží zámky.

4.3 Analýza vysokého využití CPU

Pokud podokno Přehled trvale zobrazuje využití procesoru na 100 % nebo blízko něj, je třeba identifikovat, které dotazy jsou za to zodpovědné, a určit, zda je lze optimalizovat.

4.3.1 Identifikace dotazů náročných na CPU

Chcete-li najít dotazy spotřebovávající nadměrné množství CPU:

1. Otevřete Nedávné drahé dotazy panel.
2. Seřadit podle Procesor (ms/s) zobrazit dotazy využívající nejvíce času CPU.
3. Prozkoumejte nejčastější dotazy v seznamu.
4. Klikněte pravým tlačítkem myši na dotazy s vysokou zátěží procesoru a vyberte Upravit text dotazu pro zobrazení SQL příkazu.
5. vybrat Zobrazit plán provedení abych pochopil, jak se dotaz provádí.

Věnujte pozornost nejen využití CPU jednotlivými dotazy, ale také Spuštění/min sloupec. Dotaz využívající mírné zatížení CPU na spuštění, ale spouštěný tisíckrát za minutu, může být největším spotřebitelem CPU.

4.3.2 Techniky optimalizace dotazů

Mezi běžné přístupy ke snížení spotřeby CPU patří:

• Přidat chybějící indexy: Vyhledávání indexů využívá mnohem méně CPU než prohledávání tabulek. V plánech provádění hledejte chybějící doporučení pro indexy.
• Přepište neefektivní dotazy: Nahraďte kurzory operacemi založenými na množinách, eliminujte nepotřebné funkce v klauzulích WHERE a odstraňte redundantní spojení.
• Aktualizace statistik: Zastaralé statistiky způsobují SQL Server zvolit neefektivní plány provedení. Spusťte příkaz UPDATE STATISTICS na postižených tabulkách.
• Snížení objemu dat: Pro dřívější filtrování dat přidejte klauzule WHERE, pro stránkování použijte TOP nebo OFFSET/FETCH a vyhněte se použití SELECT *.
• Oprava parametrů sniffingu: Pokud vyhledávání parametrů způsobuje problémy, použijte OPTION (RECOMPILE), nápovědy k dotazům nebo plánovací průvodce.

4.4 Zkoumání problémů s pamětí

Zatížení paměti může způsobit, že se dotazy přenesou na disk, což výrazně snižuje výkon. Sledování aktivity vám pomůže identifikovat operace náročné na paměť.

4.4.1 Pochopení metrik paměti

Jedno Využití paměti Sloupec v podokně Procesy zobrazuje paměť přidělenou jednotlivým relacím v kilobajtech. Vysoké využití paměti jednou relací často naznačuje:

• Rozsáhlé třídicí nebo hašovací operace, které se nevejdou do původně přidělené paměti
• Dotazy načítající obrovské sady výsledků
• Nadměrný paralelismus, který vytváří mnoho kopií operátorů plánu provádění
• Nevracení paměti v uložených procedurách nebo funkcích CLR

V podokně Čekání na zdroje se může zobrazit Čekání na paměť, když dotazy nemohou získat dostatek paměťových grantů a musí čekat na uvolnění paměti.

4.4.2 Identifikace dotazů náročných na paměť

Chcete-li najít dotazy způsobující zátěž paměti:

1. v Procesy podokno, seřadit podle Využití paměti zobrazit relace spotřebovávající nejvíce paměti.
2. Klikněte pravým tlačítkem myši na relace s vysokým využitím paměti a vyberte Detaily zobrazit jejich dotazy.
3. v Nedávné drahé dotazy v podokně vyhledejte dotazy s vysokou Logické čtení or Logické zápisy, protože ty často korelují s využitím paměti.
4. Prozkoumejte plány provádění pro operátory Sort a Hash Match, které používají paměťové granty.

Dotazy zobrazující varování „Udělení paměti“ v plánech provádění nebo varování před přetečením naznačují problémy s pamětí.

4.5 Detekce problémů s výkonem aplikací

Když uživatelé hlásí pomalou dobu odezvy aplikací, Activity Monitor vám pomůže určit, zda je úzkým hrdlem databáze.

4.5.1 Korelace monitoru aktivity s problémy aplikací

Prozkoumání pomalosti aplikace:

1. Poznamenejte si přesný čas, kdy uživatelé nahlásili problémy, a dotčené aplikace.
2. Otevřete Sledování aktivity a zkontrolujte Přehled podokno s údaji o špičkách zdrojů v daném okamžiku.
3. v Procesy panel, filtrovat podle editaci videa zobrazit pouze připojení z dotčené aplikace.
4. Hledejte vysokou Čekací doba hodnoty, které indikují zpoždění databáze.
5. Zkontrolovat Nedávné drahé dotazy podokno pro dotazy z dané aplikace, která spotřebovává značné množství zdrojů.

Pokud databáze nevykazuje žádnou neobvyklou aktivitu, zatímco uživatelé zaznamenávají pomalost, problém pravděpodobně spočívá v kódu aplikace, latenci sítě nebo výkonu na straně klienta.

4.5.2 Identifikace neefektivních aplikačních vzorců

Monitor aktivity odhaluje několik anti-vzorů v návrhu aplikací:

• Upovídané aplikace: Mnoho malých dotazů místo menšího počtu efektivnějších dotazů. Identifikováno vysokým počtem připojení a řadou jednoduchých dotazů v sekci Nedávné drahé dotazy.
• N+1 dotazů: Jeden dotaz následovaný N dalšími dotazy na související data. Zobrazuje se jako jednoduchý dotaz s extrémně vysokým počtem spuštění za minutu.
• Velké sady výsledků: Aplikace načítají mnohem více dat, než je potřeba. Hledejte vysokou Logické čtení v kombinaci s jednoduchými dotazy SELECT *.
• Chybějící časové limity: Aplikace, které nenastavují časové limity příkazů, mohou ponechat připojení otevřená na dobu neurčitou, což se v podokně Procesy zobrazí jako dlouhotrvající relace.

5. Alternativní metody: Získání dat monitoru aktivity pomocí T-SQL

I když Monitor aktivity poskytuje pohodlné grafické rozhraní, někdy je potřeba načíst ekvivalentní informace programově nebo vytvořit vlastní řešení monitorování.

5.1 Používání dynamických zobrazení pro správu (DMV)

SQL Server zpřístupňuje informace o aktivitě prostřednictvím dynamických zobrazení pro správu, na která se Monitor aktivity dotazuje v zákulisí.

5.1.1 Klíčové DMV pro monitorování aktivit

Mezi nejdůležitější DMV pro replikaci funkcí Activity Monitor patří:

• sys.dm_exec_requests: Zobrazuje aktuálně prováděné požadavky s informacemi o CPU, I/O a čekání.
• sys.dm_exec_sessions: Obsahuje informace na úrovni relace, jako je přihlašovací jméno, název hostitele a název programu.
• sys.dm_os_wait_stats: Poskytuje kumulativní statistiky čekání pro celou instanci.
• sys.dm_exec_query_stats: Obsahuje souhrnné statistiky výkonu pro dotazy uložené v mezipaměti.
• sys.dm_io_virtual_file_stats: Vrátí statistiky I/O pro data a soubory protokolů.
• sys.dm_exec_sql_text: Načte text SQL pro daný sql_handle nebo plan_handle.
• sys.dm_exec_query_plan: Vrátí plán provedení pro dotaz uložený v mezipaměti.

5.1.2 Ukázkové dotazy na informace o procesu

Chcete-li replikovat funkčnost podokna Procesy, můžete zadat dotaz:

SELECT 
    s.session_id AS [Session ID],
    CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
    s.login_name AS [Login],
    ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), '') AS [Database],
    ISNULL(t.task_state, '') AS [Task State],
    ISNULL(r.command, '') AS [Command],
    r.cpu_time AS [CPU Time],
    r.total_elapsed_time AS [Elapsed Time],
    r.wait_time AS [Wait Time],
    r.wait_type AS [Wait Type],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

5.1.3 Ukázkové dotazy pro statistiky čekání

Chcete-li zobrazit statistiky čekání podobné těm v podokně Čekání na zdroje:

SELECT TOP 10
    wait_type AS [Wait Type],
    wait_time_ms / 1000.0 AS [Wait Time (sec)],
    waiting_tasks_count AS [Waiting Tasks],
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
    AND wait_type NOT LIKE '%IDLE%'
    AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;

5.2 Použití sp_WhoIsActive

sp_WhoIsActive je výkonná uložená procedura vytvořená komunitou, která poskytuje podrobnější informace než Monitor aktivity v jediné sadě výsledků.

5.2.1 Instalace sp_WhoIsActive

Instalace sp_WhoIsActive:

1. Stáhněte si nejnovější verzi z http://whoisactive.com.
2. Stažený soubor je SQL skript obsahující definici procedury.
3. Otevřete skript v SQL Server Studio pro správu.
4. Připojte se ke svému SQL Server instance.
5. Spusťte skript pro vytvoření procedury v hlavní databázi.
6. Udělte oprávnění ke spuštění příslušným uživatelům.

Protože je sp_WhoIsActive nainstalován v masteru, je přístupný z libovolného kontextu databáze.

5.2.2 Základní příklady použití

Nejjednodušší způsob použití sp_WhoIsActive je:

EXEC sp_WhoIsActive;

Vrátí se sada výsledků zobrazující všechny aktivní relace s jejich dotazy, typy čekání, informacemi o blokování a využitím zdrojů.

Pro 10sekundový vzorek zobrazující aktivitu během daného období:

EXEC sp_WhoIsActive @delta_interval = 10;

Toto vypočítá delta pro metriky, jako je využití CPU a čtení, a ukazuje, co se stalo během těchto 10 sekund.

5.2.3 Pokročilé parametry

sp_WhoIsActive podporuje řadu parametrů pro přizpůsobení:

• @filtr: Filtrujte výsledky podle konkrétních relací, databází nebo přihlášení.
• @typ_filtru: Určete, na co se filtr vztahuje (relace, databáze, přihlášení atd.).
• @get_plans: Zahrnout do výsledků plány provedení (nastavit na 1).
• @get_locks: Zobrazit podrobné informace o zámku (nastaveno na 1).
• @get_transaction_info: Zobrazit podrobnosti transakce (nastaveno na 1).
• @sort_order: Seřaďte výsledky podle různých metrik (CPU, čtení, doba trvání atd.).
• @cílová_tabulka: Vložte výsledky do tabulky pro sledování historie.

Příklad zobrazující plány seřazené podle CPU:

EXEC sp_WhoIsActive 
    @get_plans = 1,
    @sort_order = '[CPU] DESC';

5.3 Používání systémových uložených procedur

SQL Server zahrnuje tradiční uložené procedury pro monitorování aktivity, i když poskytují méně informací než DMV nebo Activity Monitor.

5.3.1 sp_who a sp_who2

Procedura sp_who zobrazuje základní informace o relaci:

EXEC sp_who;

Procedura sp_who2 poskytuje o něco více podrobností:

EXEC sp_who2;

Oba postupy zobrazují ID relací, přihlašovací jména, čas CPU a informace o blokování. Chybí jim však podrobné informace dostupné prostřednictvím DMV nebo Activity Monitor. Jsou nejužitečnější pro rychlé kontroly, když potřebujete rychle jen minimum informací.

5.3.2 Další užitečné systémové postupy

Mezi další systémové postupy pro monitorování patří:

• sp_lock: Zobrazuje informace o zámku (zastaralé; použijte místo toho sys.dm_tran_locks).
• sp_monitor: Zobrazuje statistiky o SQL Server aktivitu.
• sp_nápověda: Zobrazuje definice objektů a metadata.
• DBCC SQLPERF: Zobrazuje využití prostoru v protokolu transakcí a statistiky čekání.

5.4 Vytváření vlastních monitorovacích skriptů

Pro prostředí vyžadující specifické monitorování nad rámec toho, co poskytuje Activity Monitor, můžete vytvářet vlastní řešení pomocí DMV.

5.4.1 Kompletní skript ekvivalentní monitoru aktivity

Zde je komplexní skript, který replikuje většinu funkcí Monitoru aktivity:

-- Processes Information
SELECT 
    s.session_id AS [Session ID],
    CONVERT(CHAR(1), s.is_user_process) AS [User Process],
    s.login_name AS [Login],
    ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), N'') AS [Database],
    ISNULL(t.task_state, N'') AS [Task State],
    ISNULL(r.command, N'') AS [Command],
    SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
        END - r.statement_start_offset) / 2) + 1) AS [Statement],
    st.text AS [Command Text],
    r.cpu_time AS [CPU Time (ms)],
    r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
    r.wait_time AS [Wait Time (ms)],
    r.wait_type AS [Wait Type],
    r.wait_resource AS [Wait Resource],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    c.client_net_address AS [Net Address],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id 
    AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

-- Recent Expensive Queries
SELECT TOP 20
    qs.execution_count / 
        DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
    qs.total_worker_time / 1000 AS [CPU Time (ms)],
    qs.total_physical_reads AS [Physical Reads],
    qs.total_logical_writes AS [Logical Writes],
    qs.total_logical_reads AS [Logical Reads],
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset) / 2) + 1) AS [Query Text]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;

5.4.2 Automatizace monitorování pomocí úloh SQL Agent

Můžete naplánovat vlastní monitorovací skripty pomocí SQL Server Činidlo:

1. Vytvořte tabulku pro ukládání výsledků monitorování.
2. Upravte monitorovací skript tak, aby vkládal výsledky do této tabulky.
3. In SQL Server Management Studio, rozbalit SQL Server Činidlo v Průzkumníku objektů.
4. Klepněte pravým tlačítkem myši Zaměstnání a zvolte Nová práce.
5. Nakonfigurujte úlohu tak, aby spouštěla ​​monitorovací skript v pravidelných intervalech.
6. Nastavte upozornění nebo reporty na základě shromážděných dat.

Tento přístup umožňuje historické sledování a analýzu trendů, které Monitor aktivity neposkytuje.

6. Omezení a aspekty sledování aktivity

I když je Monitor aktivity cenný, pochopení jeho omezení vám pomůže jej správně používat a v případě potřeby jej doplnit dalšími nástroji.

6.1 Pochopení režijních nákladů monitoru aktivity

Monitor aktivity není zdarma – spotřebovává serverové prostředky ke shromažďování a zobrazování informací. Pochopení této režie vám pomůže používat jej zodpovědně.

6.1.1 Dopad na serverové prostředky

Monitor aktivity spouští dotazy na systémové DMV při každé aktualizaci. Tyto dotazy spotřebovávají CPU, generují logické čtení a mohou krátce blokovat systémové tabulky. Na vytížených serverech může tato režie ovlivnit výkon.

Podokna Procesy a Nedávné drahé dotazy jsou obzvláště nákladná, protože musí prohledávat potenciálně velké DMV a tabulky v mezipaměti. Na serverech s tisíci plány dotazů uloženými v mezipaměti může aktualizace Nedávných drahých dotazů trvat několik sekund.

Dokumentace společnosti Microsoft varuje, že intervaly aktualizace kratší než 10 sekund mohou znatelně ovlivnit výkon serveru, zejména na již načtených systémech.

6.1.2 Nejlepší postupy pro interval aktualizace

Vyberte intervaly aktualizace vhodné pro vaši situaci:

• 1–5 sekund: Pouze pro okamžité řešení kritických problémů na málo zatížených serverech. Nenechávejte Sledování aktivity spuštěné v těchto intervalech.
• 10 sekund (výchozí): Vhodné pro většinu scénářů řešení problémů a obecné monitorování.
• 30–60 sekund: Lepší volba pro produkční servery s vysokou zátěží nebo při delším monitorování.
• Pouze ruční aktualizace: Pro situace, kdy chcete občas kontrolovat aktuální stav bez neustálého dotazování.

Po dokončení prověřování vždy zavřete Sledování aktivity. Nenechávejte ho běžet nepřetržitě, zejména pokud je spuštěno více instancí od různých uživatelů.

6.2 Problémy se seskupováním typů čekání

Přístup Monitoru aktivity ke kategorizaci čekání sice zjednodušuje zobrazení, ale může zakrýt důležité diagnostické informace.

6.2.1 Jak monitor aktivity seskupuje čekání

SQL Server Sleduje stovky různých typů čekání, z nichž každý označuje specifický zdroj nebo podmínku. Monitor aktivity je seskupuje do širokých kategorií, jako například „Blokování vyrovnávací paměti“, „Zámek“ a „Paměť“.

Například kategorie „Buffer Latch“ zahrnuje PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX a několik dalších specifických typů čekání. I když všechny souvisí s přístupem ke stránce, mají různé příčiny a řešení.

Společnost Microsoft přesně nedokumentuje, které typy čekání patří do kterých kategorií, takže je obtížné pochopit, co skutečně vidíte.

6.2.2 Chybějící typy čekání

Monitor aktivity nezobrazuje všechny typy čekání. Nejvíce pozoruhodné je, že často vynechává čekání CXPACKET, které indikuje paralelní provádění dotazů. Čekání CXPACKET je běžné a obvykle nepředstavuje problém, ale znalost jeho přítomnosti vám pomůže pochopit charakteristiky pracovní zátěže.

Pokud Activity Monitor zobrazuje jako nejvyšší čekací dobu „Buffer Latch“, ale jiné nástroje ukazují, že dominuje CXPACKET, rozdíl pramení z logiky filtrování a seskupování v Activity Monitoru.

6.2.3 Proč jsou specifické typy čekání důležité

Znalost konkrétního typu čekání je důležitá pro řešení problémů:

• PAGELATCH_EX: Často indikuje konflikty v databázi tempdb na alokačních stránkách. Řešení zahrnuje přidání dalších datových souborů tempdb.
• PAGELATCH_SH: Může ukazovat na aktivní stránky v uživatelských tabulkách. Řešení zahrnuje rozdělení nebo reorganizaci indexu.
• ZATÁČENÍ_STRANKY: Běžné během aktualizací. Může spíše znamenat normální provoz než problém.

Sledování aktivity seskupuje všechny tyto položky pod položkou „Buffer Latch“, což ztěžuje diagnostiku. Nástroje jako sp_WhoIsActive a dotazy DMV zobrazují specifické typy čekání.

6.3 Přesnost a aktuálnost dat

Monitor aktivity poskytuje zobrazení téměř v reálném čase, ale klíčové slovo je „téměř“. Pochopení jeho metody sběru dat vám pomůže správně interpretovat výsledky.

6.3.1 Snímky vs. kontinuální monitorování

Sledování aktivity zobrazuje snímky v čase pořízené v každém intervalu aktualizace. Události, které se mezi snímky vyskytnou, se nezaznamenávají. Pokud dotaz běží 2 sekundy a vy aktualizujete každých 10 sekund, může se zobrazit jednou nebo vůbec ne, v závislosti na načasování.

To znamená, že Activity Monitor vyniká v hledání přetrvávajících problémů (blokování trvající minuty, trvale vysoké využití CPU), ale může přehlédnout dočasné problémy (krátké zablokování, občasné nárůsty dotazů).

6.3.2 Agregace a vzorkování

V podokně Nedávné drahé dotazy se zobrazují data agregovaná od doby, kdy byly plány dotazů vloženy do mezipaměti. Dva identické dotazy s různými hodnotami parametrů se zobrazují jako jeden řádek, pokud sdílejí plán. Tato agregace může maskovat problémy se specifickými kombinacemi parametrů (problémy s čicháním parametrů).

V podokně Čekání na zdroje se vypočítávají četnost porovnáváním snímků. Pokud se statistiky čekání mezi snímky vynulují (což je vzácné, ale možné), vypočítaná četnost může být nesprávná.

6.4 Kdy NEPOUŽÍVAT Monitor aktivity

Sledování aktivity není vhodné pro každý scénář monitorování. Rozpoznejte, kdy jsou alternativní nástroje lepší volbou.

6.4.1 Požadavky na historickou analýzu

Monitor aktivity zobrazuje pouze aktuální nebo nedávnou aktivitu. Neukládá historická data. Pokud potřebujete analyzovat trendy v průběhu dnů nebo týdnů, porovnávat aktuální výkon s výchozími hodnotami nebo generovat zprávy o vzorcích výkonu, Monitor aktivity nestačí.

Pro historickou analýzu použijte SQL ServerVestavěný panel výkonu, rozšířené události s cílovými soubory nebo monitorovací řešení třetích stran.

6.4.2 Potřeby podrobných statistik čekání

Pokud potřebujete přesné informace o typu čekání pro pokročilé ladění, seskupování a filtrování v Monitoru aktivity je činí nedostatečnými. Použijte místo toho přímo dotazy DMV nebo sp_WhoIsActive.

Pro komplexní analýzu statistik čekání se dotazujte přímo na sys.dm_os_wait_stats a ručně odfiltrujte neškodná čekání.

6.4.3 Aspekty produkčního serveru

Na produkčních serverech s vysokou zátěží může být režie Activity Monitoru problematická. Více správců databází by nemělo spouštět Activity Monitor současně na stejném serveru.

Pro monitorování produkčního prostředí zvažte odlehčené alternativy, jako jsou plánované snímky DMV uložené v monitorovací databázi, nebo použijte směrování pouze pro čtení k monitorování sekundárních replik v konfiguracích Always On.

7. Nejlepší postupy pro používání Monitoru aktivity

Dodržování osvědčených postupů vám zajistí maximální hodnotu z Activity Monitoru a zároveň minimalizuje negativní dopady na vaše servery.

7.1 Kdy používat Sledování aktivity

Monitor aktivity se osvědčí v určitých situacích. Používejte ho, když jeho silné stránky odpovídají vašim potřebám.

7.1.1 Problémy s výkonem v reálném čase

Sledování aktivity je ideální, když uživatelé aktuálně mají problémy a potřebujete problém okamžitě diagnostikovat. Zobrazení v reálném čase vám pomůže zjistit, co se právě děje.

Když se vám ozve oznámení, že „aplikace je pomalá“, mělo by být jedním z prvních kroků otevření Monitoru aktivity. Můžete tak rychle zjistit, zda je databáze zaneprázdněná, blokovaná nebo nečinná.

7.1.2 Vyšetřování zpomalení aplikace

Když určitá aplikace přestane reagovat, Sledování aktivity vám pomůže určit, zda jsou příčinou problémy s databází. Filtrujte podokno Procesy podle názvu aplikace, abyste viděli pouze aktivitu databáze dané aplikace.

Pokud aplikace nevykazuje žádnou aktivitu databáze, zatímco uživatelé hlásí problémy, problém spočívá jinde v databázi. Pokud vidíte rozsáhlé blokování nebo nákladné dotazy, našli jste viníka.

7.1.3 Rychlé kontroly stavu

Monitor aktivity poskytuje vynikající řídicí panel pro rychlé kontroly stavu během běžné správy. Otevřete ho, podívejte se na grafy Přehled a ověřte, že nic nevypadá abnormálně.

Tato zběžná kontrola trvá jen několik sekund a může odhalit problémy dříve, než se stanou kritickými. Zařaďte ji do své denní rutiny.

7.2 Optimální nastavení konfigurace

Vhodná konfigurace Monitoru aktivity zlepšuje jak jeho užitečnost, tak i jeho náročnost na zdroje.

7.2.1 Doporučené intervaly aktualizace

Přizpůsobte interval obnovení svému účelu:

• Aktivní řešení problémů: 10 sekund poskytuje dobrou odezvu s rozumnou režií.
• Rozšířené monitorování: 30–60 sekund snižuje dopad na server během delších pozorovacích období.
• Diagnóza kritického problému: 5 sekund poskytuje vysokou granularitu, když se počítá každá sekunda, ale používejte krátce.
• Pravidelné zdravotní prohlídky: Ruční aktualizace (interval 1 hodiny), když aktivně nesledujete.

Nezapomeňte po dokončení zavřít Sledování aktivity. Nastavení dlouhého intervalu a jeho zapomenutí plýtvá serverovými zdroji.

7.2.2 Strategie filtrování

Použijte filtry k zaměření na relevantní informace a snížení kognitivní zátěže:

• Filtrovat procesy podle Databáze zobrazit pouze aktivitu v konkrétních databázích.
• filtrovat podle Přihlášení sledovat aktivitu konkrétního uživatele.
• filtrovat podle Stav úkolu = RUNNING pro skrytí nečinných relací.
• filtrovat podle editaci videa izolovat provoz od konkrétních programů.
• Zobrazit pouze neprázdné položky v Blokováno uživatelem zobrazit pouze blokující situace.

7.2.3 Výběr a řazení sloupců

Vypracujte systematický přístup k prohlížení dat z monitoru aktivity:

1. Začněte s přehledem: Zkontrolujte grafy, zda v nich nejsou zjevné výkyvy nebo anomálie.
2. Zkontrolujte procesy, zda neblokují: Seřaďte podle ID relace a poté vyhledejte hodnoty Blokováno.
3. Čekání na zdroje pro kontrolu: Seřaďte podle kumulativní doby čekání pro identifikaci úzkých míst v oblasti zdrojů.
4. Analýza drahých dotazů: Seřaďte podle různých metrik (CPU, spuštění, čtení) a vyhledejte různé typy problémů.
5. Ověření pomocí panelu I/O: Ověřte, zda dotazy náročné na I/O korelují s vysokou aktivitou disku.

7.3 Integrace s dalšími nástroji

Monitor aktivity funguje nejlépe jako součást širší sady nástrojů, než jako samostatné řešení.

7.3.1 Použití s SQL Server profil

Monitor aktivity a SQL Server Profilery se vzájemně dobře doplňují. Když v aplikaci Activity Monitor identifikujete problematickou relaci, klikněte na ni pravým tlačítkem myši a vyberte Trasování procesu v SQL Server profil.

Tím se spustí Profiler s filtry již nakonfigurovanými tak, aby zachytávaly pouze aktivitu dané relace. Zobrazí se kompletní sekvence provedených příkazů, informace o časování a chybové zprávy – podrobnosti, které Monitor aktivity neposkytuje.

Chcete-li se dozvědět více o SQL Server Možnosti profilování a pokročilé techniky trasování, viz naše obsáhlý SQL Server Průvodce profilerem.

7.3.2 Doplňování rozšířenými událostmi

Rozšířené události nabízí detailní monitorování s nízkými režijními náklady, které zachycuje informace, které Monitor aktivity přehlédne. Vytvořte relace rozšířených událostí pro sledování konkrétních událostí, jako jsou zablokování, dlouho běžící dotazy nebo nadměrné rekompilace.

Pro okamžité vyšetřování použijte Sledování aktivity a pro průběžné monitorování a historickou analýzu Rozšířené události. Tyto dva nástroje řeší různé potřeby.

Chcete-li se dozvědět více o SQL Server Rozšířené funkce pro události a pokročilé techniky monitorování, viz naše obsáhlý SQL Server Rozšířený průvodce událostmi.

7.3.3 Řešení pro monitorování od třetích stran

Komerční nástroje jako SolarWinds Database Performance Analyzer, Redgate SQL Monitor a Quest Spotlight poskytují funkce, které Activity Monitor postrádá: upozornění, historické trendy, plánování kapacity a automatizovanou diagnostiku.

Tyto nástroje jsou cenným doplňkem Monitoru aktivity, nikoli jeho náhradou. Monitor aktivity zůstává užitečný pro rychlé kontroly a vyšetřování, i když jsou k dispozici sofistikované monitorovací nástroje.

7.4 běžných chyb, kterým je třeba se vyhnout

Pochopení běžných chyb v Monitoru aktivity vám pomůže jej používat efektivněji.

7.4.1 Ponechání Monitoru aktivity běžícím nepřetržitě

Nejčastější chybou je otevření Monitoru aktivity a jeho neomezené běhání. To plýtvá serverovými zdroji a poskytuje jen malou hodnotu, protože se aktivně nedíváte.

Zavřete Sledování aktivity, když jej aktivně nepoužíváte. Pokud potřebujete nepřetržité monitorování, implementujte místo toho vhodné monitorovací řešení s plánovaným sběrem dat.

7.4.2 Přílišné spoléhání se pouze na Monitor aktivity

Sledování aktivity poskytuje jeden pohled na stav serveru. Nespoléhejte se výhradně na něj. Doplňte jej Sledováním výkonu systému Windows pro metriky na úrovni operačního systému, Rozšířenými událostmi pro podrobné sledování a Analýzou plánu provádění pro ladění dotazů.

Sledování aktivity vám pomáhá identifikovat problémy, ale jejich řešení často vyžaduje další nástroje a hlubší analýzu.

Další informace o SQL Server monitor výkonu v našem kompletní průvodce.

7.4.3 Ignorování historických trendů

Sledování aktivity zobrazuje aktuální stav, ale problémy s výkonem mají často viditelné vzorce až v průběhu času. Implementujte sběr historických dat, abyste mohli porovnávat aktuální metriky s výchozími hodnotami a identifikovat trendy.

Bez historického kontextu si možná neuvědomíte, že dnešní „normální“ využití CPU je o 30 % vyšší než v minulém měsíci, což naznačuje postupné snižování.

8. Řešení problémů s monitorem aktivity

Samotný Monitor aktivity někdy má problémy. Znalost toho, jak tyto problémy řešit, předchází frustraci.

8.1 Monitor aktivity se neotevře nebo nezobrazuje žádná data

Pokud se Monitor aktivity otevře, ale zobrazuje prázdné panely nebo se vůbec neotevře, může to být způsobeno několika faktory.

8.1.1 Problémy s oprávněními

Nejčastější příčinou problémů s funkcí Activity Monitor jsou nedostatečná oprávnění. Ověření a řešení:

1. Zkontrolujte oprávnění na úrovni serveru:

   SELECT * FROM fn_my_permissions(NULL, 'SERVER')
   WHERE permission_name = 'VIEW SERVER STATE';
   

2. Pokud se nevrací žádné řádky, nemáte oprávnění VIEW SERVER STATE.
3. Požádejte administrátora serveru o povolení:

   USE master;
   GRANT VIEW SERVER STATE TO [YourLogin];
   

4. Po udělení oprávnění zavřete a znovu otevřete Sledování aktivity.

8.1.2 Problémy s kompatibilitou verzí

Používání staré verze SQL Server Management Studio pro připojení k novějšímu SQL Server Verze může způsobit selhání Sledování aktivity. Nástroj nemusí rozumět novým typům čekání nebo sloupcům systémového zobrazení.

Vždy používejte verzi SSMS, která se shoduje s vaší verzí nebo je novější. SQL Server verze. Společnost Microsoft poskytuje nejnovější verzi SSMS ke stažení zdarma, odděleně od SQL Server sám.

8.1.3 Problémy s firewallem a sítí

Monitor aktivity vyžaduje připojení k SQL Server instance na standardních portech (výchozí nastavení je 1433). Pokud se můžete připojit přes Průzkumník objektů, ale Sledování aktivity selže, pravidla brány firewall mohou blokovat určitá připojení.

Ověřte, zda se váš klient může dostat k SQL Server počítač na všech potřebných portech. Zkontrolujte bránu firewall systému Windows i všechny síťové brány firewall mezi klientem a serverem.

8.2 Trvale pozastaveno sledování aktivity

Častý problém, zejména v SQL Server 2019, otevírá se Monitor aktivity v pozastaveném stavu a odmítá se obnovit.

8.2.1 Vysvětlení pozastaveného stavu

Když se Sledování aktivity pozastaví, všechny panely zobrazují stav „Pozastaveno“ s tlačítkem pro obnovení, které nemusí fungovat. Díky tomu nevidíte žádnou aktivitu serveru.

K pozastavení obvykle dochází kvůli problémům s oprávněními, omezením vzdáleného připojení nebo chybám verze SSMS, nikoli kvůli úmyslnému pozastavení.

8.2.2 Běžné příčiny

Monitor aktivity může přejít do trvalého pozastaveného stavu z důvodu:

• Chybí oprávnění VIEW SERVER STATE na novějších panelech přidaných v poslední době. SQL Server verze
• Vzdálená připojení jsou zakázána na SQL Server instance
• Selhání ověřování pro konkrétní systémové dotazy
• Chyby v konkrétních sestaveních SSMS, zejména ve verzích 18.0 až 18.3
• Problémy s připojením mezi klientem a serverem

8.2.3 Kroky řešení

Řešení problémů s pozastaveným stavem Monitoru aktivity:

1. Aktualizace SSMS: Stáhněte a nainstalujte nejnovější SQL Server Verze Management Studia z webu společnosti Microsoft. Mnoho chyb pozastaveného stavu bylo v pozdějších verzích opraveno.
2. Ověření oprávnění: Ujistěte se, že máte oprávnění ZOBRAZIT STAV SERVERU a ZOBRAZIT JAKOUKOLI DEFINICI.
3. Zkontrolujte vzdálená připojení: Ověřte, zda SQL Server instance umožňuje vzdálená připojení:

   EXEC sp_configure 'remote access';
   

   Pokud je hodnota 0, požádejte administrátora o její povolení.

4. Restartujte SSMS: Někdy stačí zavřít všechna okna a restartovat SQL Server Management Studio problém řeší.
5. Připojení s ověřováním systému Windows: Pokud používáte ověřování SQL, zkuste místo toho ověřování systému Windows, protože někdy obchází problémy s pozastavením související s ověřováním.

8.3 Problémy s výkonem při používání Sledování aktivity

Pokud se samotný Activity Monitor zpomalí nebo způsobí snížení výkonu serveru, je nutná úprava.

8.3.1 Snížení režijních nákladů na monitorování

Jak minimalizovat dopad Sledování aktivity:

1. Prodlužte interval aktualizace na 30 sekund nebo 1 minutu.
2. Zavřete panely, které aktivně nepoužíváte, kliknutím na tlačítko sbalit.
3. Pokud jsou panely sbalené, Monitor aktivity pro ně nezjišťuje data.
4. Nespouštějte více instancí Monitoru aktivity současně.
5. Pokud aktivně nezkoumáte problémy, úplně zavřete Sledování aktivity.

8.3.2 Alternativní metody monitorování lehkých systémů

Pokud je Monitor aktivity pro vaše prostředí příliš náročný na zdroje, zvažte alternativy:

• Dotazujte se přímo na DMV: Pište specifické T-SQL dotazy, které načítají pouze informace, které potřebujete.
• Použijte sp_WhoIsActive: Tato uložená procedura je vysoce optimalizovaná a obvykle má nižší režijní náklady než Activity Monitor.
• Implementace vzorkování: Naplánujte úlohy agenta SQL, které v pravidelných intervalech zachycují snímky dat DMV a ukládají výsledky do tabulek pro pozdější analýzu.
• Monitorování sekundárních replik: In Skupiny dostupnosti Always On, spusťte Sledování aktivity na čitelném sekundárním serveru, nikoli na primárním.

8.4 Nepřesné nebo chybějící informace

Monitor aktivity někdy zobrazuje informace, které se zdají být nesprávné nebo neúplné.

8.4.1 Ověřování dat s úřady DMV

Pokud se výsledky Monitoru aktivity zdají být podezřelé, ověřte je přímým dotazem na podkladové DMV. Pokud se například v podokně Procesy nezobrazuje žádné blokování, ale uživatelé jej hlásí, použijte dotaz:

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;

Pokud tento dotaz zobrazuje blokování, které Monitor aktivity přehlédl, potvrdili jste problém se zobrazením.

8.4.2 Principy načasování aktualizace dat

Nezapomeňte, že Sledování aktivity zobrazuje snímky. Dotaz, který byl spuštěn mezi intervaly aktualizace, se nezobrazí v sekci Nedávné drahé dotazy, pokud jeho plán provedení nezůstane v mezipaměti.

Podobně statistiky čekání v podokně Čekání na zdroje odrážejí akumulaci od posledního snímku. Rychle se měnící úlohy mohou při každé aktualizaci vykazovat odlišné vzorce.

9. Pokročilé techniky sledování aktivity

Zkušení správci databází používají Activity Monitor sofistikovanými způsoby k dosažení maximální diagnostické hodnoty.

9.1 Kombinování více panelů pro analýzu hlavní příčiny

Skutečná síla Monitoru aktivity se projeví, když propojíte informace napříč více panely, abyste pochopili složité problémy s výkonem.

9.1.1 Korelace čekání s procesy

Pokud podokno Čekání na zdroje zobrazuje v kategorii vysoké doby čekání, použijte podokno Procesy k identifikaci relací, u kterých k těmto čekáním dochází:

1. Všimněte si kategorie čekání s vysokou kumulativní dobou čekání (např. „Zámek“).
2. Přepněte do podokna Procesy.
3. Seřadit podle Typ čekání seskupit relace podle aktuálního čekání.
4. Hledejte relace zobrazující typy čekání v problematické kategorii.
5. Pro tyto lekce si prohlédněte Čekací zdroj sloupec, kde se zobrazí, kterých databázových objektů se to týká.
6. Klepněte pravým tlačítkem myši a vyberte Detaily zobrazit text dotazu.

Tato korelace vám pomůže přejít od „máme čekání na zámky“ k „tento konkrétní dotaz čeká na zámky v této tabulce“.

9.1.2 Propojení nákladných dotazů s problémy I/O

Pokud podokno datových souborů I/O zobrazuje vysokou aktivitu disku v konkrétní databázi:

1. Všimněte si, které databázové soubory mají vysokou rychlost čtení nebo zápisu MB/s.
2. Přepnout na Nedávné drahé dotazy.
3. Seřadit podle Fyzické čtení/s k identifikaci dotazů, které čtou hodně z disku.
4. Filtrujte nebo vizuálně identifikujte dotazy spuštěné v databázi s vysokým počtem operací I/O.
5. Prozkoumejte plány provádění těchto dotazů, zda v nich nejsou prohledány tabulky nebo zda chybí indexy, které by mohly způsobit nadměrné množství I/O operací.

Tato vícepanelová analýza propojuje symptomy (vysoký objem diskových operací) s příčinami (konkrétní neefektivní dotazy).

9.2 Použití monitoru aktivit pro plánování kapacity

I když Monitor aktivity neukládá historická data, můžete ho strategicky využít pro pozorování plánování kapacity.

9.2.1 Identifikace vzorců špičkového využití

Sledujte aktivitu serveru v různých denních dobách a identifikujte vzorce používání:

1. Otevřete Sledování aktivity během známé pracovní špičky.
2. Všimněte si maximálních hodnot grafu % času procesoru.
3. Zaznamenejte maximální počet čekajících úloh.
4. Sledujte počet požadavků na dávky/s ve špičce.
5. V podokně Procesy zdokumentujte nejrušnější databáze.
6. Pro srovnání opakujte mimo špičku.

Pokud vytížení procesoru ve špičce trvale přesahuje 80 %, blížíte se limitům kapacity procesoru. Podobně rostoucí počet čekání naznačuje rostoucí soupeření o zdroje.

9.2.2 Analýza trendů zdrojů

I když Monitor aktivity zobrazuje aktuální stav, můžete jej použít i pro namátkovou kontrolu trendů zaznamenáváním klíčových metrik v průběhu času:

• Pořizujte snímky obrazovky z podokna Přehled ve stejnou dobu každý den
• Zaznamenejte maximální hodnoty z každého grafu
• Porovnávejte týden po týdnu a identifikujte trendy růstu
• Sledujte postupné zvyšování průměrné doby procesoru nebo rychlosti I/O operací.

Toto manuální sledování trendů doplňuje sofistikovanější monitorovací řešení a pomáhá odůvodnit rozšíření kapacity.

9.3 Dokumentace základních hodnot výkonnosti

Stanovení základních metrik výkonu vám pomůže rozpoznat, kdy se výkon snižuje.

9.3.1 Zachycení základních metrik

Během období známého dobrého výkonu dokumentujte metriky Sledování aktivity:

1. Otevřete Sledování aktivity během běžného provozu (ne ve špičce ani mimo ni).
2. Hodnoty v podokně Přehled záznamů:
   • Typický rozsah % času procesoru
   • Průměrný počet čekajících úkolů
   • Normální rychlost databázového I/O
   • Typické dávkové požadavky/s
3. Kategorie v podokně Čekání na zdroje, které zobrazují nejdelší dobu čekání, si všimněte.
4. Počet aktivních procesů obvykle dokumentujte v podokně Procesy.
5. Zaznamenejte reprezentativní metriky provádění dotazů z Nedávných drahých dotazů.

Uschovejte si tuto základní dokumentaci pro budoucí použití při šetření problémů s výkonem.

9.3.2 Porovnání současného a základního výkonu

Pokud se vyskytnou problémy s výkonem, porovnejte aktuální hodnoty Monitoru aktivity se zdokumentovanými výchozími hodnotami:

• Je doba vytížení procesoru výrazně vyšší než základní hodnota? Zaměřte se na dotazy náročné na procesor.
• Jsou čekací úlohy 2–3krát vyšší než základní úrovně? Prozkoumejte čekání na zdroje.
• Je I/O výrazně vyšší? Zkontrolujte panel I/O datových souborů a náročné dotazy.
• Jsou dávkové požadavky během špičky nižší než základní hodnota? Hledejte problémy s blokováním nebo připojením.

Toto srovnání vám pomůže identifikovat, co se změnilo, a vhodně zaměřit úsilí o řešení problémů.

9.4 Vytváření vlastních monitorovacích pracovních postupů

Vypracujte systematické pracovní postupy pro běžné scénáře vyšetřování, abyste zajistili důkladnou a opakovatelnou analýzu.

9.4.1 Postupný proces vyšetřování

Když uživatelé nahlásí problémy s výkonem, dodržujte konzistentní pracovní postup:

1. Rychlá kontrola stavu: Otevřete Sledování aktivity a prohledejte grafy v podokně Přehled, zda nejsou zjevné anomálie.
2. Zkontrolujte blokování: Rozbalte podokno Procesy a ve sloupci Blokováno uživatelem vyfiltrujte položky Neprázdné.
3. Identifikujte soupeření o zdroje: Panel Zkontrolovat čekání na zdroje seřazený podle doby čekání.
4. Najděte drahé dotazy: Prozkoumejte nedávné nákladné dotazy seřazené podle CPU, poté podle provedení a nakonec podle čtení.
5. Korelace I/O vzorů: Křížové odkazy na náročné dotazy s aktivitou podokna I/O datových souborů.
6. Nálezy dokumentu: Pořiďte snímky obrazovky a zaznamenejte relevantní ID relací, typy čekání a podrobnosti dotazů.
7. Hluboký ponor: Pro podrobné prošetření identifikovaných problémů použijte trasování Profileru, analýzu plánu provedení a dotazy DMV.

9.4.2 Kritéria eskalace

Stanovte kritéria pro to, kdy eskalovat problémy oproti pokračování ve vyšetřování:

• Okamžitě eskalovat: Blokovací řetězce trvající >5 minut, doba provozu procesoru na 100 % po dobu >2 minut, kritické systémové procesy vykazující stav POZASTAVENO.
• Eskalace s analýzou: Opakující se nákladné dotazy spotřebovávající >50 % CPU, konzistentně vysoké doby odezvy I/O >50 ms, opakované selhávání paměťových grantů.
• Prozkoumejte dále: Dočasné čekání vyřešené během několika minut, dotazy s neoptimálními plány, ale s přijatelným výkonem, drobné blokování s dobou trvání <30 sekund.

10. Monitor aktivity v různých SQL Server verze

Monitor aktivity se vyvíjel v průběhu SQL Server verze, přičemž každé vydání přináší vylepšení a občas i nové problémy.

10.1 Monitor aktivity v SQL Server 2008 a později

SQL Server V roce 2008 byl představen moderní design monitoru aktivity, který se dodnes do značné míry nezměnil.

10.1.1 Nové funkce zavedené v SQL Server 2008

Jedno SQL Server Redesign Monitoru aktivity z roku 2008 přinesl významná vylepšení:

• Grafický dashboard s grafy v reálném čase v podokně Přehled
• Rozhraní rozbalitelného/sbalitelného panelu nahrazující staré zobrazení pouze v mřížce
• Panel Nedávné drahé dotazy zobrazující souhrnná data o výkonu dotazů
• Panel I/O datových souborů pro sledování aktivity disku pro jednotlivé soubory
• Vylepšený panel Čekání na zdroje s kategorizací čekání
• Kontextové nabídky pro akce procesu, jako je ukončení relací a spuštění Profileru, se zobrazí po kliknutí pravým tlačítkem myši.
• Nastavitelné intervaly obnovení od 1 sekundy do 1 hodiny

Díky těmto změnám se Monitor aktivity proměnil z jednoduchého seznamu procesů v komplexní monitorovací panel.

10.1.2 Změny oproti SQL Server 2005

SQL Server Monitor aktivity z roku 2005 byl mnohem omezenější:

• Přístup přes složku Správa v Průzkumníku objektů, nikoli přes panel nástrojů
• Jedna mřížka zobrazující seznam procesů se základními informacemi
• Žádné grafické diagramy ani více panelů
• Žádné drahé dotazy ani monitorování I/O
• Omezené informace o statistikách čekání

Redesign z roku 2008 představoval spíše kompletní přepracování než postupné vylepšení.

10.2 Monitor aktivity v SQL Server 2014/2016

SQL Server V letech 2014 a 2016 došlo k postupnému vylepšení základního sběru dat v Monitoru aktivity, ale k malým vizuálním změnám.

10.2.1 Vylepšení a vylepšení

Mezi klíčová vylepšení v těchto verzích patřilo:

• Lepší výkon při monitorování serverů s tisíci plánů uložených v mezipaměti
• Vylepšené možnosti filtrování v podokně Procesy
• Vylepšená přesnost agregace statistik čekání
• Lepší zpracování řazení a filtrování sloupců u velkých sad výsledků
• Efektivnější dotazy DMV snižující režijní náklady na monitorování

Základní rozhraní zůstalo konzistentní s SQL Server 2008, udržování povědomí pro administrátory.

10.3 Monitor aktivity v SQL Server 2019/2022

Nejnovější SQL Server Verze pokračují ve vývoji Activity Monitoru se zaměřením na výkon a stabilitu.

10.3.1 Nejnovější funkce a možnosti

SQL Server Monitor aktivit pro roky 2019 a 2022 zahrnuje:

• Podpora pro nové typy čekání zavedené v těchto verzích
• Vylepšený výkon vykreslování v SSMS pomocí technologie WPF
• Lepší zpracování velkého počtu aktivních relací
• Vylepšená kompatibilita s cloudovými platformami SQL
• Přesnější metriky CPU a I/O

10.3.2 Známé problémy v nedávných verzích

SQL Server Rok 2019 přinesl několik chyb v Monitoru aktivity:

• Trvalý pozastavený stav: Sledování aktivity se často pozastavuje a neobnovuje se, zejména v SSMS 18.0-18.3. Opraveno v novějších verzích SSMS.
• Chyby vzdáleného připojení: Některé konfigurace brání spuštění Monitoru aktivity na vzdálených instancích. Mezi alternativní řešení patří povolení konkrétních příznaků trasování nebo použití novějších sestavení SSMS.
• Problémy s oprávněním: Nové systémové pohledy vyžadují další oprávnění, která nejsou jasně zdokumentována, což způsobuje prázdné zobrazení i při použití VIEW SERVER STATE.

Při práci s SSMS vždy používejte nejnovější verzi. SQL Server v letech 2019 a 2022, aby se těmto problémům předešlo.

11. Praktické případy použití a příklady

Příklady z reálného světa ukazují, jak efektivně používat Sledování aktivity v běžných scénářích řešení problémů.

11.1 Případová studie: Diagnostika pomalé webové aplikace

Vývojový tým hlásí, že jejich webová aplikace se stala nepřijatelně pomalou, načítání stránky trvá 20–30 sekund místo obvyklých 2–3 sekund.

11.1.1 Počáteční prošetření s přehledem

Otevřete Sledování aktivity a prozkoumejte podokno Přehled:

1. Graf % času procesoru ukazuje využití CPU 85–95 %, což je výrazně více než běžná základní hodnota 30–40 %.
2. Počet čekajících úkolů kolísá mezi 10–20 úkoly, oproti normální základní hodnotě 0–3.
3. Databázové I/O operace vykazují mírnou aktivitu kolem 50 MB/s.
4. Počet dávkových požadavků/s je nižší než očekávaný, a to 100/s, oproti typickým 300–400/s během pracovní doby.

Tento vzorec naznačuje úzké hrdlo CPU s konfliktem zdrojů, což vede ke snížené propustnosti. Server pracuje intenzivně, ale nezpracovává mnoho požadavků.

11.1.2 Identifikace problematického dotazu

Rozbalte podokno Nedávné drahé dotazy a seřaďte je podle počtu spuštění/min:

1. Nejčastější dotaz ukazuje 15 000 spuštění za minutu.
2. Klepněte pravým tlačítkem myši a vyberte Upravit text dotazu prozkoumat dotaz.
3. Dotaz je jednoduchý příkaz SELECT, který načítá záznam jednoho uživatele: SELECT * FROM Users WHERE UserId = @UserId.
4. Tento dotaz by se při běžném používání aplikace neměl provádět 15 000krát za minutu.

Klikněte pravým tlačítkem myši na dotaz a vyberte Zobrazit plán provedeníPlán zobrazuje prohledání tabulky Users s upozorněním na chybějící index ve sloupci UserId.

Filtrujte podokno Procesy podle aplikace, aby se zobrazovala pouze připojení webové aplikace. Více relací zobrazuje opakovaně spouštěný stejný dotaz.

11.1.3 Řešení a ověření

Problém pramení ze dvou faktorů: nadměrného počtu spuštění dotazů a chybějícího indexu. Kroky řešení:

1. Vytvořte chybějící index:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Kontaktujte vývojový tým o nadměrném počtu spuštění. Vyšetřování odhalilo problém s dotazem N+1 v kódu aplikace, kde smyčka načítá uživatelské údaje pro každou položku v seznamu.
3. Upravte aplikaci dávkově seskupit vyhledávání uživatelů do jednoho dotazu pomocí klauzule IN nebo parametru s tabulkovou hodnotou.
4. Ověřte opravu monitorováním Monitoru aktivity po nasazení. Využití CPU klesne na 35–40 %, počet spuštění za minutu se sníží na 200–300 a doba odezvy aplikací se vrátí k normálu.

11.2 Případová studie: Řešení problému s blokováním

Uživatelé hlásí, že systém pro zadávání objednávek se periodicky na 30–60 sekund zasekává, než se vrátí k normálnímu provozu.

11.2.1 Detekce blokovacího řetězce

Během jedné z těchto událostí zamrznutí otevřete Sledování aktivity a rozbalte podokno Procesy:

1. Seřadit podle ID relace zobrazit všechny uspořádané lekce.
2. Více sezení zobrazuje hodnoty v Blokováno uživatelem sloupec, všechny ukazující na ID relace 73.
3. Sezení 73 ukazuje '1' v Blokátor hlavy sloupec, čímž se potvrdí, že se jedná o hlavní příčinu.
4. Jedno Typ čekání Pro blokované relace se zobrazuje LCK_M_X, což znamená, že čekají na exkluzivní zámky.
5. Jedno Čekací zdroj Sloupec ukazuje, že blokování je v tabulce Objednávky.

11.2.2 Analýza příčiny

Klikněte pravým tlačítkem myši na Sezení 73 a vyberte Detaily zobrazit příkaz:

UPDATE Orders 
SET Status = 'Processing', 
    LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);

Tato aktualizace je součástí dávkového zpracování, které probíhá každou hodinu. Kontrola Přihlášení Sloupec potvrzuje, že relace patří k účtu služby dávkového zpracování.

Dotaz drží zámky na tabulce Objednávky při zpracování tisíců objednávek. Čekací doba Počet blokovaných relací se neustále zvyšuje, což potvrzuje, že problémem je tato dlouhodobá operace.

11.2.3 Implementace opravy

Krátkodobé řešení:

1. Podrobnosti o relaci 73 dokumentu včetně textu dotazu a doby trvání.
2. Nechte aktualizaci dokončit přirozeně, protože se jedná o legitimní dávkové zpracování.
3. Po dokončení ověřte, zda jsou blokované relace vymazány a zda se obnoví normální provoz.

Implementovaná dlouhodobá řešení:

1. Znovu naplánovat dávkovou úlohu provozovat mimo špičku (2–4 hodiny ráno místo pracovní doby).
2. Úprava dávkového zpracování aktualizovat objednávky v menších dávkách po 100 záznamech najednou a uvolňovat zámky mezi dávkami.
3. Přidat index ve sloupci OrderId pro urychlení operace aktualizace.
4. Zvažte izolaci SNAPSHOT pro operace čtení, aby se snížil dopad blokování.

11.3 Případová studie: Identifikace nadměrného provádění dotazů

Monitorování databáze ukazuje, že využití CPU se v posledním měsíci postupně zvyšovalo, ale v kódu aplikace nedošlo k žádným zjevným změnám.

11.3.1 Zjištění abnormálního počtu spuštění

Otevřete Sledování aktivity a prohlédněte si podokno Nedávné drahé dotazy:

1. Seřadit podle Spuštění/min zobrazit nejčastěji prováděné dotazy.
2. Nejčastější dotaz ukazuje 37 000 spuštění za minutu – mnohem více než jakýkoli jiný dotaz.
3. Klepněte pravým tlačítkem myši a vyberte Upravit text dotazu.
4. Dotaz načte informace o kategorii produktu:

   SELECT CategoryId, CategoryName 
   FROM ProductCategories 
   WHERE CategoryId = @CategoryId;
   

5. Tento jednoduchý dotaz by měl být rychlý a ukládatelný do mezipaměti, přesto se provádí desítky tisíckrát za minutu.

11.3.2 Trasování k aplikačnímu kódu

V podokně Procesy vyhledejte relace, které provádějí tento dotaz:

1. Poznámka: editaci videa Ve sloupci je uvedena „ProductCatalogService“.
2. Klikněte pravým tlačítkem myši na jednu z těchto relací a vyberte Trasování procesu v SQL Server profil.
3. SQL Profiler odhaluje, že dotaz se opakovaně spouští v rychlém sledu s různými hodnotami CategoryId.
4. Pro kontrolu kódu kontaktujte vývojový tým spravující ProductCatalogService.

Revize kódu odhaluje problém: nedávná změna načítá seznamy produktů s kategoriemi. Pro každý produkt ve výsledné sadě (často více než 1 000 produktů) kód provádí samostatné volání databáze pro načtení informací o kategorii – klasický problém dotazu N+1.

11.3.3 Optimalizace aplikace

Implementujte správnou opravu:

1. Úprava dotazu aplikace Použití JOIN pro načtení produktů a jejich kategorií v jednom volání databáze:

   SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName
   FROM Products p
   INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
   WHERE p.Active = 1;
   

2. Nasazení aktualizovaného kódu a monitorujte Sledovač aktivity.
3. Ověřte opravu: Počet spuštění dotazu kategorie za minutu klesá z 37 000 na méně než 100 a celkové využití CPU se snižuje o 40 %.
4. Zdokumentujte získané poznatky a sdílejte s vývojovým týmem, abyste předešli podobným problémům v budoucích změnách kódu.

12. Detekce potenciálního poškození databáze

Přestože Monitor aktivity není určen speciálně k detekci poškození databáze, určité vzorce v jeho zobrazení mohou naznačovat skryté problémy s poškozením, které vyžadují další vyšetření.

12.1 Příznaky potenciálního poškození databáze

Pokud existuje poškození databáze a je k ní přistupováno, může se občas zobrazit:

1. V podokně Procesy:

• Relace uvízlé ve stavu SUSPENDED s neobvyklými typy čekání
• Procesy zobrazující chybové stavy
• Dotazy opakovaně selhávají

2. V podokně Čekání na zdroje:

• Neobvyklé typy čekání související s I/O operacemi, které by mohly naznačovat problémy s diskem (ačkoli to spíše naznačuje problémy s hardwarem než logické poškození)

3. V sekci Nedávné drahé dotazy:

• Dotazy s abnormálně vysokým počtem fyzických čtení, pokud se opakovaně pokoušejí číst poškozené stránky.

12.2 Další kontrola pomocí DBCC CHECKDB

Pokud nástroj Activity Monitor zobrazuje příznaky naznačující možné poškození, měli byste okamžitě spustit příkaz DBCC CHECKDB k ověření integrity databáze. Tento příkaz prohledá všechny stránky databáze, ověří kontrolní součty a zkontroluje chyby logické konzistence.

Chcete-li se dozvědět více o tom, jak používat příkaz DBCC CHECKDB ke kontrole a opravě poškození databáze, podívejte se na naše komplexní průvodce DBCC CHECKDB.

12.3 Oprava profesionálním nářadím

Pokud DBCC CHECKDB potvrdí poškození databáze, máte několik možností opravy:

• Preferovaným přístupem je obnovení ze známé funkční zálohy. Viz náš komplexní průvodce zálohováním a obnovou SQL Server databáze.
• V případě drobného poškození může být problém vyřešen příkazem DBCC CHECKDB s příkazem REPAIR_REBUILD.
• Pro kritické databáze bez nedávných záloh, profesionální Software pro obnovu SQL a služby často dokáží obnovit data, která vestavěné možnosti opravy nedokážou.

13. závěr

SQL Server Activity Monitor je neocenitelným nástrojem pro správce databází, který poskytuje okamžitý přehled o výkonu serveru a pomáhá rychle a efektivně diagnostikovat problémy.

13.1 Shrnutí klíčových bodů

V této příručce jsme prozkoumali, jak vám Sledování aktivity pomáhá pochopit a řešit problémy SQL Server výkon:

• Monitor aktivity poskytuje přehled o procesech, čekání, dotazech a I/O operacích v reálném čase prostřednictvím přehledného grafického rozhraní.
• Pět panelů – Přehled, Procesy, Čekání na zdroje, Vstupně-výstupní operace s datovými soubory a Nedávné nákladné dotazy – nabízí jedinečný pohled na aktivitu serveru.
• Běžné scénáře řešení problémů, jako je nadměrné provádění dotazů, blokovací řetězce a vysoké využití CPU, lze zvládnout systematickým šetřením nástrojem Activity Monitor.
• Přestože je Monitor aktivity výkonný, má svá omezení, včetně nedostatku historických dat, seskupování typů čekání a režijních nákladů na monitorování, která ovlivňují jeho použitelnost.
• Doplněním Monitoru aktivit o dotazy DMV, sp_WhoIsActive, rozšířené události a potenciálně nástroje třetích stran vytváříte komplexní strategii monitorování.
• Dodržování osvědčených postupů pro intervaly aktualizace, zavírání Monitoru aktivity, když se nepoužívá, a kombinování více panelů pro korelaci maximalizuje jeho hodnotu a zároveň minimalizuje dopad.

13.2 Monitor aktivity jako součást vaší sady nástrojů

Monitor aktivity by měl sloužit jako váš první nástroj pro vyšetřování výkonu, nikoli jako jediný. Jeho silná stránka spočívá v poskytování okamžitého přehledu během aktivního řešení problémů, což vám pomůže rychle určit, zda je databáze úzkým hrdlem, a identifikovat specifické aspekty vyžadující hlubší prozkoumání.

Představte si Monitor aktivity jako analogii s palubní deskou ve vašem autě – okamžitě vás upozorní, pokud je něco v nepořádku, a pomůže vám identifikovat obecnou oblast problému. Stejně jako vám palubní deska vašeho auta neřekne přesně, proč se rozsvítila kontrolka motoru, Monitor aktivity vás upozorní na problémy, aniž by vždy odhalil jejich úplnou příčinu. Tato hlubší analýza vyžaduje další nástroje a odborné znalosti.

Integrujte Activity Monitor do širší sady nástrojů, která zahrnuje analýzu plánu provádění, sledování statistik čekání, řešení historického monitorování a osvědčené postupy pro výkon. Používejte jej ve spojení se správnými strategiemi indexování, technikami optimalizace dotazů a plánováním kapacity.

13.3 Pokračování ve vašem učení

Zvládnutí Activity Monitoru je jen jedním krokem k tomu, abyste se stali efektivním správcem databáze. Pokračujte v rozvíjení svých dovedností:

• Naučit se interpretovat realizační plány a identifikovat neefektivní operace
• Porozumění SQL Server statistiky čekání a jejich důsledky
• Studium technik návrhu a optimalizace indexů
• Za poznáním SQL ServerArchitektura a způsob zpracování dotazů
• Procvičování systematických metod řešení problémů
• Získávání zkušeností s rozšířenými událostmi pro detailní trasování
• Pochopení úrovní izolace transakcí a jejich vlivu na výkon

Každé vyšetření výkonu pomocí Monitoru aktivity vás naučí něco nového o tom, jak SQL Server fungování a jak aplikace interagují s databázemi. Dokumentujte svá zjištění, sdílejte znalosti s kolegy a vytvářejte knihovnu řešení běžných problémů.

13.4 Další zdroje

Rozšiřte si znalosti s těmito cennými zdroji:

• Otevřete Activity Monitor v SQL Server Management Studio (SSMS) : Oficiální SQL Server dokumentace k otevření Monitoru aktivity v SQL Server Management Studio (SSMS).
• Activity Monitor : Oficiální SQL Server dokument o tom, jak používat Sledování aktivity.

14. Často kladené otázky (FAQ)

Co je SQL Server ActivityMonitor?

A: SQL Server Monitor aktivity je vestavěný nástroj v SQL Server Management Studio, které zobrazuje informace o procesech spuštěných na serveru v reálném čase. SQL Server instance a jejich dopad na serverové prostředky. Poskytuje grafický řídicí panel s pěti panely zobrazujícími různé aspekty aktivity serveru, včetně využití procesoru, čekajících úloh, rychlosti I/O, aktivních relací a náročných dotazů.

Otázka: Jak otevřu Sledování aktivity v SSMS?

A: Monitor aktivity můžete otevřít čtyřmi způsoby: (1) Kliknutím na ikonu Monitor aktivity na panelu nástrojů SSMS, (2) Kliknutím pravým tlačítkem myši na SQL Server název instance v Průzkumníku objektů a vyberte Activity Monitor, (3) Stiskněte Ctrl + Další + Anebo (4) Nakonfigurujte SSMS tak, aby se spouštěl automaticky prostřednictvím Tools -> možnosti -> životní prostředí -> Startup.

Otázka: Jaká oprávnění potřebuji k používání Sledování aktivity?

A: Potřebujete ZOBRAZIT STAV SERVERU oprávnění k zobrazení většiny informací z Monitoru aktivity. Pro podokno V/V datových souborů potřebujete také buď VYTVOŘTE DATABÁZE, ZMĚNA JAKÉKOLI DATABÁZEnebo ZOBRAZIT JAKOUKOLI DEFINICI oprávnění. Bez těchto oprávnění se může Sledování aktivity otevřít, ale zobrazit prázdné panely.

Otázka: Proč je můj Monitor aktivity pozastavený nebo nefunguje?

A: Sledování aktivity se obvykle pozastavuje kvůli problémům s oprávněními, zastaralým verzím SSMS nebo zakázaným vzdáleným připojením. Řešení: (1) Aktualizujte na nejnovější verzi SSMS, (2) Ověřte, zda máte oprávnění ZOBRAZIT STAV SERVERU, (3) Zkontrolujte, zda jsou na serveru povolena vzdálená připojení. SQL Server například, (4) Restartujte SSMS a (5) Zkuste se připojit s ověřováním Windows namísto ověřování SQL, pokud je to možné.

Otázka: Jaký je rozdíl mezi monitorem aktivity a sp_WhoIsActive?

A: Activity Monitor je grafický nástroj zabudovaný do SSMS, který poskytuje uspořádané panely pro různé aspekty monitorování. sp_WhoIsActive je bezplatná uložená procedura vytvořená komunitou, která vrací podrobné informace o relaci v jediné sadě výsledků s konkrétnějšími typy čekání, podrobnostmi blokování a možnostmi přizpůsobení než Activity Monitor. Activity Monitor je lepší pro vizuální prozkoumávání, zatímco sp_WhoIsActive vyniká ve skriptovaném monitorování a poskytuje podrobnější informace.

Otázka: Ovlivňuje Sledování aktivity výkon serveru?

A: Ano, Monitor aktivity má měřitelné režijní náklady, protože dotazuje systémové DMV v každém intervalu aktualizace. Dopad se zvyšuje s nižšími obnovovacími frekvencemi – společnost Microsoft varuje, že intervaly kratší než 10 sekund mohou ovlivnit výkon serveru. Monitor aktivity vždy zavřete, když jej aktivně nepoužíváte, a na produkčních serverech s vysokou zátěží zvažte intervaly aktualizace 30–60 sekund.

Otázka: Mohu získat data z monitoru aktivity pomocí T-SQL?

A: Ano, Sledování aktivity dotazuje zobrazení dynamické správy systému, jako jsou sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats a sys.dm_exec_query_stats. Tyto zobrazení dynamické správy systému můžete dotazovat přímo pomocí T-SQL a programově načíst ekvivalentní informace, což umožňuje vlastní monitorovací skripty a automatizovaný sběr dat.

Otázka: Jaký je výchozí interval aktualizace?

A: Výchozí interval aktualizace je 10 sekund. Můžete to změnit kliknutím pravým tlačítkem myši kamkoli v podokně Přehled a výběrem možnosti Interval obnovenía výběrem z předdefinovaných možností: 1 sekunda, 5 sekund, 10 sekund, 30 sekund, 1 minuta nebo 1 hodina. Kratší intervaly poskytují více zobrazení v reálném čase, ale zvyšují režijní náklady na monitorování.

Otázka: Jak mohu automaticky otevřít Monitor aktivity při spuštění SSMS?

A: Konfigurace automatického spouštění prostřednictvím možností SSMS: Přejděte na Tools -> možnosti -> životní prostředí -> Startup, Poté vyberte Otevřete Průzkumník objektů a Sledování aktivity z Při spuštění rozbalovací nabídka. Sledování aktivity se automaticky otevře při každém připojení k serveru v SSMS.

Otázka: Jaká jsou omezení Sledování aktivity?

A: Mezi klíčová omezení patří: (1) Žádné možnosti ukládání historických dat ani sledování trendů, (2) Typy čekání jsou seskupeny do kategorií, nikoli zobrazeny konkrétně, (3) Některé typy čekání, jako například CXPACKET, se nemusí zobrazit, (4) Snímky v čase mohou přehlížet přechodné problémy, (5) Režie monitorování může mít dopad na vytížené servery, (6) Žádný mechanismus upozornění pro proaktivní monitorování a (7) Nelze agregovat data z více serverů SQL Server instance. Pro tyto potřeby doplňte Sledování aktivity o rozšířené události, sady sběru dat nebo monitorovací nástroje třetích stran.

---

O autorovi

Yuan Sheng je seniorní správce databází (DBA) s více než 10 lety zkušeností v SQL Server prostředí a správu podnikových databází. Úspěšně vyřešil stovky scénářů obnovy databází ve finančních službách, zdravotnictví a výrobních organizacích.

Yuan se specializuje na SQL Server obnova databáze, řešení s vysokou dostupnostía optimalizaci výkonu. Jeho rozsáhlé praktické zkušenosti zahrnují správu databází o velikosti více terabajtů, implementaci skupin dostupnosti Always On a vývoj automatizovaných strategií zálohování a obnovy pro kritické podnikové systémy.

Díky svým technickým znalostem a praktickému přístupu se Yuan zaměřuje na vytváření komplexních průvodců, které pomáhají správcům databází a IT profesionálům řešit složité SQL Server efektivně zvládá výzvy. Udržuje si přehled o nejnovějších SQL Server vydání a vyvíjející se databázové technologie společnosti Microsoft a pravidelně testuje scénáře obnovy, aby zajistil, že jeho doporučení odrážejí osvědčené postupy z reálného světa.

Máte otázky ohledně SQL Server potřebujete další pokyny k odstraňování problémů s databází? Yuan vítá zpětnou vazbu a návrhy pro vylepšení těchto technických zdrojů.