Jedná se o softwarový produkt od Sybase, který pracuje ve spojení s SQL Serverem a poskytuje řadu informací o výkonu serveru v grafické podobě. Tyto informace jsou mimořádně užitečné při analýze důvodů poklesu jeho výkonu.

verze 11.0.1 má řadu nových důležitých funkcí, které výrazně odlišují novou verzi od všech předchozích. 11.0.1 může pracovat s jakoukoli verzí SQL Server od verze 4.9.2 po systém 11.

Některé z nejzajímavějších typů informací o vzorcích využití databázových objektů a interakci serveru se sítí jsou však poskytovány pouze při monitorování SQL Server System 10 a System 11. Data o výkonu pojmenovaných vyrovnávacích pamětí jsou samozřejmě poskytuje pouze při sledování výkonu SQL Server System 11.

Pro kompatibilitu s předchozími verzemi podporuje 11.0.1 také režim pro výstup statistických informací o výkonu serveru do souborů, které lze použít pro následné porovnání a analýzu. Tato funkce je v praxi velmi užitečná, její použití však komplikuje proces instalace.

se skládá ze dvou komponent: serverového modulu, který běží na stejném stroji se serverem SQL Server a poskytuje přístup do sdílené paměťové oblasti serveru, a klientského modulu, který lze spustit na libovolném počítači. Hlavním úkolem klientského modulu je číst informace nashromážděné serverovým modulem a prezentovat je uživateli v grafické podobě.

Při spuštění musíte zrušit kontrolu paměti serveru prováděnou příkazem dbcc memusage, protože tento příkaz výrazně zpomaluje server. Chcete-li to provést, musíte při spouštění sqlmon (klientského modulu) zadat parametr – nomem.

Výchozí konfigurace umožňuje současné připojení až pěti klientských modulů k jednomu serveru. Jinými slovy, jeden serverový modul může být připojen buď k pěti klientským modulům s jedním oknem na každém klientovi, nebo k jednomu klientovi s pěti otevřenými okny.

Maximální počet současně otevřených klientských oken je nastaven při spuštění modulu serveru.

Chcete-li tedy podporovat 20 oken v příkazovém souboru pro spouštění serverového modulu, musíte zadat parametr n2 0. V tomto případě budete muset změnit adresu začátku oblasti sdílené paměti serveru pomocí příkaz buildmaster a některé další akce. Tyto akce by nikdy neměly být prováděny, když je spuštěn SQL Server. (Podrobnosti o procesu rozšiřování počtu podporovaných souběžných klientů naleznete v příručce Server Supplement.)

má nějaké nevýhody. Například sloupcový graf zobrazující počet probíhajících I/O operací a další výkonnostní charakteristiky serverových zařízení může hlásit data pouze na omezeném počtu zařízení najednou.

To je nepohodlné při monitorování velkého serveru s velkým počtem serverových zařízení. Uživatel navíc nemůže vybrat zařízení, pro která budou informace zahrnuty do grafu, ani přepínat mezi různými sadami zařízení.

Textová tabulka, která se objeví na obrazovce současně s diagramem, obsahuje seznam všech serverových zařízení, ale obsahuje pouze celkový počet I/O operací pro každé z nich. To je zvláště obtížné při práci s velkým serverem, který má mnoho serverových zařízení podporujících segmenty uživatelských databází za účelem zlepšení výkonu. V tomto případě není možné analyzovat fungování všech existujících segmentů.

Neumožňuje také dlouhodobě zobrazovat na obrazovce dynamiku změn ukazatelů výkonu.

Je schopen zobrazit data pro 60 po sobě jdoucích intervalů měření výkonu. V závislosti na zvolené době trvání každého intervalu mohou takové statistiky pokrývat poměrně velké časové období. Tato technika však neumožňuje porovnávat aktuální data s ukazateli před měsícem nebo rokem.

Obrázky oken programu lze samozřejmě vytisknout na tiskárnu, ale pak budete muset uložit sady souborů nebo velké množství tiskových výstupů, abyste mohli vyhodnotit budoucí výkon serveru. V praxi bude správce serveru často muset znovu prozkoumat data shromážděná v různých obdobích obchodního cyklu společnosti a také křížové referenční informace v podobných obdobích v po sobě jdoucích obchodních cyklech, aby získal přehled o skutečném výkonu serveru.

Vzhledem k tomu, že spuštění vede k určitému zpomalení serveru, je před zahájením měření nutné určit velikost tohoto zpomalení pro konkrétní hardwarovou a softwarovou platformu. Dobrým způsobem měření je spuštění standardní sady testovacích transakcí.

Může být použit jak v případě, že je přítomen nebo není na serveru. I když neexistují žádné klientské moduly, serverový modul programu pokračuje v práci a musí být zastaven samostatným příkazem.

umožňuje zobrazit několik různých grafických oken, z nichž každé obsahuje informace o určitém aspektu fungování serveru.

Hlavní okno
Obsahuje seznam oken podporovaných programem. Pokud při spouštění sglmon, klientského modulu, nebyl zadán parametr – nomem, zobrazí se v tomto okně také koláčový graf využití paměti serverového stroje.

Mezipaměť (Cache)
Toto okno zobrazuje grafy charakterizující činnost procedur a vyrovnávacích pamětí dat. Řízením počtu fyzických a logických I/O operací ve vyrovnávací paměti datové mezipaměti může uživatel určit, jakou část přístupů datové stránky server provede pomocí stránek již ve vyrovnávací paměti. Tyto statistiky získané pro datovou vyrovnávací paměť a vyrovnávací paměť procedur nám umožňují určit celkové množství paměti požadované mezipamětí serveru a poměr mezi vyrovnávací pamětí dat a procedur.

Mezipaměť mezipaměti dat, pouze SQL Server System 11 (Data Cach)
Okno uvádí počet fyzických a logických I/O operací pro každou z pojmenovaných vyrovnávacích pamětí konfigurovaných na serveru.

Disk I/O
Zde naleznete grafy a souhrnné tabulky pro aktuální a celkový počet přístupů na disk. Pomáhají optimalizovat rozložení zátěže I/O mezi stávající serverová zařízení. Při analýze výstupních informací je užitečné použít standardní schéma pro výběr názvů serverových zařízení na základě názvů odpovídajících sekcí fyzických disků, protože při sledování směnného kurzu se serverovými zařízeními byste měli vědět, který diskový řadič každé z těchto zařízení je připojeno.

Práce se sítí, pouze pro SQL Server System 10 a 11 (síťová aktivita)
Okno hlásí statistické informace o síťovém vstupu a výstupu – velikosti paketů, objemy provozu atd.

Blokování přístupu k objektům, pouze pro SQL Server System 10 a 11 (stav uzamčení objektu)
Zobrazí se informace o zámcích přístupu k datové tabulce, včetně podrobného rozpisu typů použitých zámků, názvů procesů, které zámky drží atd.

I/O stránky objektu, pouze SQL Server System 10 a 11 (I/O stránky objektu)
Okno obsahuje informace o intenzitě I/O stránek jedné z datových tabulek serveru. Při sestavování seznamu nejčastěji používaných serverových tabulek věnujte pozornost efektivitě. Tento typ informací není vrácen sp_sysmon.

Souhrn výkonu
To poskytuje celkový obrázek o výkonu SQL Serveru – procento využití CPU, počet transakcí zpracovaných za sekundu, objem síťového provozu, diskové vstupy a výstupy a využití uzamčení.

Trend výkonu
Okno zobrazuje spojité grafy ukazatelů výkonu serveru zobrazených v okně Přehled výkonu v závislosti na čase.

Aktivita procesu serveru (aktivita procesu)
Toto okno vám umožňuje vybrat jeden nebo více serverových procesů a sledovat využití CPU a I/O svazky pro každý proces.

Detail procesu
Okno obsahuje podrobné informace o vybraném procesu serveru.

Seznam procesů
Okno obsahuje seznam všech aktuálně dostupných serverových procesů s uvedením jejich stavu. Velmi podobné vydání příkazu serveru sp_who.

Použití aktivity Zámek procesu
Okno poskytuje informace o použití zámků procesem serveru, který jste vybrali.

Použití aktivity uložené procedury
Okno obsahuje informace o provádění uložených procedur a době běhu každé procedury.

Transakční činnost
V okně můžete vidět sloupcový graf zobrazující počet zpracovávaných transakcí, rozdělený podle různých typů transakcí. Můžete se například podívat, jakou část transakcí lze dokončit pomocí mechanismu aktualizace na místě.

26.12.2006 Kevin Kline

Jaká je poslední otázka, kterou by chtěl DBA položit? Pravděpodobně zpráva od uživatele o zhoršení stavu aplikace nebo dotaz, co se stalo s databází. Musíme dát všechno stranou a přejít do „nouzového režimu“ a přemýšlet, jak dlouho to bude trvat. Protože jednou z hlavních povinností správce databáze je zajistit kvalitní fungování průmyslových databází, nezbývá než poruchu co nejrychleji odstranit. Zpravidla není čas zjišťovat příčinu poruchy.

Už žádné uspěchané práce – jen systematické pozorování

Ale je to jediná věc, kterou lze udělat? Je zde možnost provádět proaktivní monitorování výkonu, jednoduchý postup správy, který využívá základní linie systému, benchmarking a průběžné monitorování. V tomto článku budu hovořit o tom, jak používat proaktivní monitorování a jak vytvořit bezplatný monitorovací systém pomocí Windows System Monitor.

Proaktivní monitorování

Proaktivní monitorování výkonu je jednoduchý systém, který vám pomůže vyřešit problémy dříve, než se stanou kritickými. Někteří lidé pravděpodobně již používají sledování výjimek, kdy vytvářejí automatizované procesy, které pouze zaznamenávají anomálie, ale neposkytují podrobné informace ani schopnost předcházet problémům. Proaktivní sledování výkonu na druhou stranu poskytuje uživateli nejrůznější informace o pracovním prostředí a aplikacích, a to jak krátkodobé, tak dlouhodobé. Provádějí se čítače výkonu databáze, stanovují se srovnávací metriky a je udržováno aktivní monitorování.

Jak název napovídá, proaktivní sledování výkonu vyžaduje akci. Instalace zabere trochu času a trochu času pochopíte, jak databáze a aplikace fungují. Aby bylo proaktivní monitorování výkonu účinné, musí být zprávy přezkoumány, aby bylo možné využít shromážděná bohatá data.

Základní parametry, standard, monitor

Začněme definováním několika pojmů. Základní parametry (výchozí) je sada parametrů, které odrážejí chování serveru a aplikace za normálních podmínek. Základní parametry byly získány jako průměry na základě výsledků několika měření provedených za stejných podmínek; jsou to měřítka pro srovnání.

Benchmark ukazuje výkon systému při určité úrovni zatížení serveru, což vám umožňuje porovnat výkon průmyslového serveru na této úrovni a určit výkon serveru, o kolik vyšší nebo nižší je než normálně (to znamená, kdy server funguje špatně). Stejně jako základní parametry jsou referenční hodnoty odebírány v kontrolovaném prostředí, klíčové hodnoty jsou určeny ve vztahu k předem definovaným ukazatelům. Pokud potřebujete vidět, jak se server a aplikace chovají na několika úrovních nebo typech zatížení, pak obvykle získáte několik referenčních hodnot (ve vztahu k základním parametrům)

Sledování- jedná se o plánované monitorování serveru v reálném čase za předem definovaných podmínek (soubory podmínek definovaných pro další vyšetřování nebo varování). Pokud například chcete vědět, jak dlouho trvá úspěšné spuštění kritické obchodní aplikace, jak dlouho trvá zálohování nebo kdy je dosaženo určitých milníků výkonu, tyto konkrétní události jsou monitorovány.

Nyní přejděme k proaktivnímu sledování. Můžete použít produkty třetích stran nebo bezplatné řešení, které používá System Monitor. Řešení třetích stran mohou zjednodušit proces nastavení proaktivního monitorování a mohou mít jiné funkce, než jaké může poskytovat bezplatné vestavěné řešení. Ale než začneme, ukážu vám, jak začít s proaktivním monitorováním pomocí Sledování systému.

Krok 1: Definujte základní linie výkonu.

V prvním kroku zajištění režimu proaktivního monitorování je stanovena sada základních parametrů pro provoz databázového serveru. Tento agregát ukazuje výkon serveru za normálních podmínek, pomáhá dokumentovat a porozumět všem důležitým procesům na pozadí a také pomáhá identifikovat situace, které nevyžadují zásah, aby mohly být v budoucnu ignorovány. Jinými slovy, správci databází mohou definovat možnosti ignorování systémových zpráv, protože jinak je generováno velké množství falešných oznámení.

Aby bylo možné jasně ukázat kvalitu provozu, nejlepší základní linie používají několik grafů (ideálně jeden), abyste na první pohled viděli, jak si server vede. Po určení základních parametrů je třeba provést následující. Nejprve vyberte možnost uložit data o výkonu do systémového protokolu nebo je zobrazit v reálném čase. Ideální je mít obojí: protokoly vám umožňují kdykoli se podívat zpět na naměřené hodnoty a analyzovat, jaký byl výkon, když jste systém přímo nesledovali. Monitorování v reálném čase nezabírá místo na disku ani prostředky serveru, ale vyžaduje 100 procent vaší pozornosti k systému. Zadruhé musíte určit interval, ve kterém bude monitorování prováděno, s ohledem na výkonnostní náklady na sběr dat a datové I/O operace a odhadnout náklady na požadovaný prostor. Čím delší je interval, tím vyšší je pravděpodobnost, že nebudou získána požadovaná data o výkonu. Nakonec zvolte místní nebo vzdálené monitorování. Lokální monitorování, ve kterém proces monitorování využívá monitorovaný server, přidává serveru režii CPU a disku. Vzdálené monitorování, které využívá samostatný server, může tyto problémy odstranit, ale značně zvyšuje zátěž sítě.

Uvádí metriky nebo počítadla sledování systému, které doporučujeme použít k určení vaší základní linie. Nemohu říci, jaká je „správná“ hodnota v kontextu konkrétní aplikace, protože se systém od systému liší. Použijte průměr různých základních linií k nastavení normálního základního výkonu a označte, že se jedná o správnou volbu pro používaný systém.

Definování základních nastavení pomocí sledování systému

Nyní, pro účely sběru základních parametrů, zavolejte System Monitor. Otevřeme Ovládací panely, Nástroje pro správu, Výkon. Poklepejte na Performance Logs and Alerts v levém podokně. Klikneme pravým tlačítkem na Protokoly čítače a vybereme možnost Nastavení nového protokolu. Zadejte název grafu a klikněte na OK. V dialogovém okně Vybrat čítače vyberte první čítač a klepněte na Přidat. Opakujte tyto kroky, dokud nebudou přidány všechny čítače, a potom klikněte na Zavřít.

Nejprve vyzkoušejte výchozí 15sekundový interval. Nebo vyberte jiný interval kliknutím na Vlastnosti (nebo použijte klávesovou zkratku Ctrl + Q) a poté zadejte hodnotu označenou Sample automaticky každých: _ sekund. Delší intervaly zabírají méně místa, ale poskytují méně podrobná data.

Vyberte tabulku Soubory protokolů a určete, kam budou data uložena. Data můžete zobrazit později pomocí zobrazení dat souboru protokolu. Sledování systému bude vypadat jako na obrázku 1, když shromažďuje základní údaje o výkonu. Je vidět, že mnoho dat lze shromáždit sledováním mnoha měřičů současně, proto byste měli pečlivě vybírat měřiče pro hlavní vedení.

Krok 2: Nastavení referenčních hodnot

Jakmile je stanovena základní výkonnost serveru, můžete začít nastavovat benchmarky, což usnadňuje pochopení výkonu serveru při běhu v několika předem definovaných situacích.

Pro standardy se používá stejný režim sledování jako pro stanovení základních parametrů. Můžete použít své vlastní řešení nebo některý z běžných průmyslových nástrojů, jako je TPC-C nebo SAP, ale nejlepších výsledků pro výpočet hodnot benchmarků získáte vývojem běžných vlastních skriptů, které jsou nakonfigurovány pro použití konkrétního databázového serveru a jeho aplikací. .

Svůj vlastní skript můžete vytvořit pomocí sady skriptů T-SQL, obslužných programů osql nebo Query Analyzer, SQL Profiler a System Monitor. Vývoj skriptů zátěžového testu v T-SQL obvykle trvá několik dní. Shromáždění dat o provedení zátěžového testu a analýza výsledných dat může vyžadovat ještě více času.

Jakmile vytvoříte základní linii výkonu serveru při předdefinovaném zatížení, můžete vědět, co od systému očekávat. Použijte data shromážděná při získávání referenčních hodnot jako základ pro rutinní monitorování. Například bylo zjištěno, že server je schopen doručit až 249 transakcí za sekundu, než se začal zpomalovat. V tomto případě můžete nastavit upozornění s nízkou prioritou, když server dosáhne přibližně 200 TPS a upozornění s vysokou prioritou, když server dosáhne 235 TPS. Tato metoda umožní správci zjistit možné problémy se serverem a přijmout nezbytná opatření dříve, než si uživatelé něčeho všimnou. A žádné kritické situace. Nyní je to možné.

Krok 3: Plánované monitorování

Snad nejdůležitější složkou proaktivního monitorovacího režimu je plánované monitorování. Bez něj nemůžete monitorovat výkon databáze ani odhalovat problémy s výkonem.

Můžete vytvořit levný nástroj pro monitorování SQL Server pomocí kombinace SQL Server Agent a System Monitor. SQL Server Agent vám umožňuje určit, která událost způsobila, že se chyba objevila na monitoru, určit, kdo přijímá oznámení o událostech, a automaticky odeslat upozornění, když dojde k chybě.

Instalace SQL Server Agent může být časově náročná a složitá, takže další informace najdete v části Výstrahy v SQL Server. Knihy online (BOL). SQL Server Agent obvykle monitoruje chybové zprávy databázového serveru a nesleduje provádění.

Chcete-li sledovat výkon serveru, použijte nástroj Sledování systému ke sledování aktuálních čítačů (frekvenci dotazování nastavte na 15 minut).

Paměť-Stránky/sec

Síťové rozhraní – bajty celkem/s

Přenosy mezi fyzickým diskem a diskem/sec

Procesor-% času procesoru

SQLServer: Přístupové metody - Úplné skenování/s

SQLServer: Poměr přístupů mezi správcem vyrovnávací paměti a mezipamětí

SQLServer: Databáze aplikací databáze-Transakce/sec

SQLServer: Obecná statistika-připojení uživatelů

SQLServer:Latches-průměrná doba čekání na blokování

SQLServer: Zámky – průměrná čekací doba

SQLServer: Časové limity uzamčení-uzamčení/s

SQLServer:Zámky-počet zablokování/s

SQLServer: Správce paměti – čeká se na přidělení paměti

Nastavte hodnotu pro každý čítač mezi základními hodnotami a referenčními hodnotami zobrazenými při testování. Můžete si například nastavit upozornění, když měřič dosáhne 75 procent nejvyšší hodnoty zatížení, a varovnou zprávu, když překročí 90 procent.

K provádění výstrah můžete použít bezplatné nástroje, jako jsou SQL Server Alerts & Notifications, System Monitor nebo si zakoupit Microsoft Operations Manager (MOM) či jiné nástroje. Doporučuji nastavit upozornění alespoň pro následující situace:

• chyby ovlivňující provoz, zejména chyby se skóre závažnosti 19 až 25
• blokování
• využití procesoru
• využití disku
• skenování (SQLServer: Přístupové metody)

Alarmy mohou být zasílány za účelem upozornění správcům prostřednictvím e-mailu, pageru nebo sítě. Automatická upozornění můžete nastavit pro následující zdroje zpráv:

• Protokol serveru SQL
• Protokol agenta SQL
• Protokol aplikací Windows, Zabezpečení a Systém
• Protokol provádění úlohy SQL Server

Nakonec musíte zajistit, aby vaše vlastní aplikace správně zaznamenávaly chyby a také reagovaly na chybové zprávy z jiných vyvinutých aplikací.

Proaktivní monitorování výkonu SQL Server znamená stanovení základních výkonových parametrů pro server i aplikaci; nastavení benchmarků, které simulují chování serveru podle předem určeného scénáře při používání, a provádění plánovaného monitorování, v ideálním případě spouštění výstrah při zjištění problému. Ať už používáte bezplatné nebo vestavěné nástroje nebo zvolíte řešení třetích stran, kontrola zajistí, že dostanete potřebné informace, když je potřebujete o tom, jak vaše aplikace běží na serveru SQL Server.

Tabulka 1. Objekty a čítače System Monitor pro stanovení základních parametrů

Objekt a počítadlo	Popis
Paměť-Stránky/sec	Počet stránek přečtených nebo zapsaných na disk za sekundu. Tento čítač je primárním indikátorem typů chyb způsobených zpožděním systému nebo problémy s výkonem
Síťové rozhraní – bajty celkem/s	Počet bajtů procházejících síťovým rozhraním za sekundu. Když tento čítač klesá nebo se vyvíjí tímto způsobem, znamená to, že aplikaci mohou ovlivňovat problémy se sítí
Přenosy fyzického disku/sec	Odhad operací čtení/zápisu na disk. Nastavte čítač pro každý fyzický disk na serveru
Procesor-% času procesoru	Procento času, který procesor stráví prováděním pracovního vlákna. Tento čítač funguje jako primární indikátor aktivity procesoru. Pokud všechny procesory běžící na serveru SQL Server vykazují 100% využití, dotazy koncových uživatelů budou pravděpodobně ignorovány
SQLServer: Přístupové metody - Úplné skenování/s	Neomezené prohledávání tabulek nebo indexů za sekundu. Snížení tohoto počítadla je lepší, protože zobrazení často způsobují nedostatek zdrojů a problémy s ukládáním do mezipaměti
SQLServer: Poměr přístupů mezi správcem vyrovnávací paměti a mezipamětí	Procento stránek, které nevyžadovaly čtení disku. Čím vyšší je jejich počet, tím méně diskových I/O se provádí. Na dobře vyladěném systému by tato hodnota měla být 80 nebo vyšší.
SQLServer: Databáze-Log Růst	Jak moc se zvětšil transakční soubor pro konkrétní databázi? Na dobře vyladěném systému by měl být tento čítač nízký, pravděpodobně méně než jeden každých pár dní
SQLServer: Databázová aplikační databáze – použitý protokol procent	Procento volného místa v souboru protokolu. Tento čítač se mění podle plánu, ale neměl by dosáhnout 100
SQLServer: Databáze aplikací databáze-Transakce/sec	Počet transakcí potvrzených v databázi. Tento čítač je občas ze standardů vynechán. Sledujte, kdy se transakce začnou zařazovat do fronty, což znamená, že vstup/výstup na disku může být pomalý
SQLServer:Latches-průměrná doba čekání na blokování	Průměrná doba, po kterou žádost trvá, než bude vyřízena. Tato hodnota čítače může být vysoká, když server zažívá konflikt o prostředky, zejména paměť nebo I/O
SQLServer: Zámky-průměrná čekací doba, Zámek čeká/s, Počet uváznutí/s	Dočasné zámky drží prostředky SQL Server. Sledujte vzestupný trend těchto čítačů souvisejících se zámkem, což naznačuje možný problém s výkonem
SQLServer: Obecná statistika-uživatelská připojení	Počet uživatelských připojení k databázovému serveru. Zkontrolujte, zda nedošlo k znatelným posunům hodnoty tohoto počítadla. Mohou indikovat problémy se sítí a indikovat zatížení a zpomalení
SQLServer: Správce paměti – čeká se na přidělení paměti	Aktuální počet procesů čekajících na přidělení paměťového prostoru. Vysoká nebo rostoucí hodnota může znamenat nedostatečnou kapacitu paměti
SQLServer: User Settable-Query (sledovací dotaz)	Specializovaný čítač, známý také jako index dotazů. Tento čítač je uživatelsky generovaný dotaz, který udává celkovou rychlost nebo efektivitu systému. Chcete-li nastavit tuto hodnotu, aplikace zavolá sp_user_counter1 a vrátí číselnou hodnotu.

Každý správce databáze se pravděpodobně musel vypořádat s tím, že vše funguje pomalu nebo nefunguje vůbec. První věc, kterou musíte zjistit, je, co se na SQL Serveru aktuálně děje. Zdálo by se, že administrátor má ve svém arzenálu tolik užitečných věcí: praštěný Activity Monitor, hromadu dynamických pohledů správy (dmv), uložené procedury sp_who a sp_who2, zděděné z dob SQL Server 7 a SQL Server 2000.
Ale pojďme na to přijít...

Monitorovací nástroje

Monitor aktivity

Zdálo by se to jako skvělá věc, dělá přesně to, co má – sleduje aktivitu. Spustím těžký účetní report a uvidím, co mi Activity Monitor ukáže.
Snímky obrazovky ukazují monitor aktivity ze serveru SQL Server 2005:

a ze serveru SQL Server Denali (2012) CTP 3.


Hmmm. Co když takové zprávy spustí tucet lidí? A to není nic neobvyklého... Bude docela nepohodlné na to přijít, i když pokrok je samozřejmě zřejmý. V Denali Activity Monitor ukazuje mnohem užitečnější informace (například na jakém konkrétním zdroji čekání probíhá), navíc můžeme například přímo z monitoru spustit profiler pro požadovanou relaci a sledovat ji již v profileru. , ale sakra, navíc se to načte a už tak přetížený server. Navíc už je problém s brzdami a neuvidíme ty požadavky, které se v době spuštění profileru již začaly vyřizovat.
A to je přesně to, co chci vidět – kdo co právě teď dělá.

sp_who a sp_who2

Snímek obrazovky ukazuje výsledek provádění sp_who (nahoře) a sp_who2 (dole), které byly provedeny při vytváření stejné nešťastné zprávy:


To jo. Velmi informativní. Při pohledu na sp_who vidíme pouze to, že něco běží. Samozřejmě se provádí – proto se díváme, ale vidíme, že se provádí nějaký druh SELECT. Nebo několik SELECTů.
sp_who2 zobrazuje další informace. Nyní můžeme vidět, kolik času procesoru strávila relace (a celkový čas zřejmě sečíst ve sloupci), počet I/O operací, název databáze, ve které se to všechno provádí a kým relace je blokována (pokud je blokována).
Activity Monitor, jak vidíme, poskytuje více informací.

DMV

Počínaje SQL Serverem 2005 máme novou možnost získávat informace o stavu serveru – Dynamic Management Views. MSDN říká toto: "Pohledy a funkce dynamické správy vracejí data o stavu serveru, která lze použít ke sledování stavu instance serveru, diagnostice problémů a ladění výkonu."
V SQL Server 2005 skutečně existuje sada pohledů souvisejících s prováděním dotazů v aktuálním okamžiku (existují však také pohledy pro prohlížení „historie“): zde jsou a jejich počet se verze od verze stále zvyšuje!
Zkušení administrátoři mají jistě připravenou spoustu skriptů, aby získali informace o aktuálním stavu serveru, ale co dělat, když ještě nemáte zkušenosti s prací s DMV, ale už se vyskytly problémy?

sp_WhoIsActive

Adam Machanic (SQL Server MVP a MCITP) vyvinul a neustále vylepšuje uloženou proceduru sp_WhoIsActive, která se spoléhá na stejné DMV a je zatraceně snadno použitelná. Můžete si stáhnout nejnovější verzi sp_WhoIsActive. Sám Adam má sérii článků věnovanou sp_WhoIsActive, skládající se až z 30 (třiceti!) kousků, můžete si to přečíst, ale pokusím se vás zaujmout čtením tohoto materiálu :).
Budeme tedy předpokládat, že jste si tento skript stáhli a spustili na jednom z testovacích serverů (na libovolné verzi, od roku 2005 po Denali). Adam radí uložit jej do databáze hlavního systému, aby se dal volat v kontextu jakékoli databáze, ale není to nutné, jen při volání v kontextu jiné databáze budete muset napsat název celý - DB .schema.sp_whoIsActive.
Tak to zkusíme. Snímek obrazovky ukazuje výsledek jeho provádění při vytváření stejného přehledu:

Výsledek dotazu exec sp_whoIsActive se bohužel nevejde na jednu obrazovku, takže zde je textový popis výstupu uložené procedury volané bez parametrů.

• - pro aktivní požadavek ukazuje čas provedení, pro „spící“ relaci - čas „spící“;
• - vlastně spid;
• - zobrazuje text aktuálně prováděného požadavku nebo text posledního dokončeného požadavku, pokud relace spí;
• - no, rozumíš;
• - velmi zajímavá rubrika. Výstup je ve formátu (Ax: Bms/Cms/Dms)E. A je počet úkolů čekajících na zdroj E. B/C/D je doba čekání v milisekundách. Pokud na uvolnění zdroje čeká pouze jedna relace (jako na snímku obrazovky), zobrazí se její čekací doba, pokud jsou 2 relace, jejich čekací doby se zobrazí ve formátu B/C. Pokud čekají 3 nebo více, uvidíme minimální, průměrnou a maximální dobu čekání na TOMTO zdroji ve formátu B/C/D;
• - pro aktivní požadavek - celkový čas CPU strávený tímto požadavkem, pro spící relaci - celkový čas CPU za „celou životnost“ této relace;
• - pro aktivní dotaz je to počet operací zápisu v TempDB během provádění dotazu; pro spící relaci - celkový počet záznamů v TempDB za celou dobu trvání relace;
• - pro aktivní požadavek - počet stránek v TempDB přidělených pro tento požadavek; pro spící relaci - celkový počet stránek v TempDB přidělených během celé doby trvání relace;
• - pokud jsme náhle někým zablokováni, zobrazí se spid (session_id) osoby, která nás zablokovala;
• - pro aktivní požadavek - počet logických čtení provedených při provádění tohoto požadavku; pro spací relaci - počet stránek přečtených za celou dobu trvání této relace;
• - vše je stejné, ale o nahrávání;
• - pro aktivní požadavek - počet fyzických čtení provedených při provádění tohoto požadavku; pro spací relaci - tradičně celkový počet fyzických čtení za celou dobu trvání relace;
• - pro aktivní požadavek - počet osmikilobajtových stránek použitých při provádění tohoto požadavku; pro spící relaci - kolik celkových paměťových stránek jí bylo přiděleno během celé její životnosti;
• - stav relace - běh, spánek atd.;
• - zobrazuje počet transakcí otevřených touto relací;
• - zobrazuje, pokud je to možné, průběh operace (například ZÁLOHA, OBNOVENÍ), nikdy neukáže, kolik procent SELECT je dokončeno.

Zbývající sloupce v standardní výstup sp_WhoIsActive jsou málo zajímavé a nebudu je popisovat - jejich účel je myslím každému jasný (název_hostitele, název_databáze, název_programu, čas_přihlášení, čas_přihlášení, ID_požadavku, čas_kolekce).

a co? To je vše?

Ne, to není všechno. Budu také mluvit o tom, s jakými (z mého pohledu nejzajímavějšími a nejužitečnějšími) parametry můžete sp_WhoIsActive volat a co z toho vzejde.

• @help je strašně užitečná možnost. Když zavoláme sp_whoIsActive @help = 1 , získáme informace o VŠECH parametrech a výstupních sloupcích na obrazovce. Takže pokud něco zůstane nejasné, můžete se vždy podívat na „nápovědu“
• @filter_type a @filter - umožňují filtrovat výsledek provedení. @filter_type může nabývat hodnot „session“, „program“, „database“, „login“ a „host“. V parametru @filter označujeme, který objekt zvoleného typu nás zajímá. Například chceme vidět všechny relace běžící v hlavní databázi, k tomu zavoláme exec sp_whoIsActive @filter_type = "databáze", @filter = "master" . Parametr @filter umožňuje použití "%";
• @not_filter_type a @not_filter – umožňují nám filtrovat „naopak“. To znamená, že například chceme vidět vše kromě těch relací, které mají v poli „databáze“ „master“, k tomu spustíme exec sp_WhoIsActive @not_filter_type = „database“, @not_filter = „master“ . No, nebo, chceme vidět, co dělají všichni uživatelé kromě uživatele sa... Může být mnoho aplikací. Parametr @not_filter umožňuje použití "%";
• @show_system_spids = 1 - zobrazí informace o systémových relacích;
• @get_full_inner_text = 1 - pole sql_text bude obsahovat nejen text aktuálního požadavku (výpisu) v dávce (dávce), ale text celé dávky;
• @get_plans - přidá na výstup sloupec s plány provádění dotazů;
• @get_transaction_info = 1 - přidá na výstup počet a objem záznamů v transakčním protokolu a také čas zahájení poslední transakce;
• @get_locks = 1 - doplní na výstup informace o všech zámcích použitých během provádění požadavku;
• @find_block_leaders = 1 – bude sledovat řetězec blokování a zobrazí celkový počet relací čekajících na aktuální relaci k odstranění bloku;
• @output_column_list = "[%]" - co když nechcete vidět informace tempDB ve výstupu sp_whoIsActive? Tato volba vám umožňuje řídit, co bude výstupem;
• @destination_table = "název_tabulky" - pokusí se vložit výsledek spuštění do tabulky, ale nezkontroluje, zda tato tabulka existuje a zda je do ní dostatek práv pro vložení.

To je teď vše

Výsledkem je další mimořádně pohodlný a flexibilní nástroj pro sledování aktuální aktivity na SQL Serveru. Pro jeho normální provoz stačí oprávnění VIEW SERVER STATE a práva pro přístup k dmv.
Také stojí za to přidat v případě, kdy lze server připojit pouze přes

Kontrolní seznam auditu výkonu

Zadejte své výsledky do tabulky výše.

Použití nástroje Performance Monutor k identifikaci hardwarových překážek serveru SQL Server

Nejlepším místem pro zahájení auditování výkonu serveru SQL je nástroj Sledování výkonu (Monitor systému). Sledování několika klíčových čítačů v průběhu 24 hodin vám poskytne docela dobrou představu o všech hlavních problémech s hardwarem, které ovlivňují výkon SQL Serveru.

V ideálním případě byste měli pomocí monitoru výkonu vytvořit soubor protokolu klíčových odečtů měřiče po dobu 24 hodin. Zvolíte "typické" 24hodinové období pro vytvoření souboru protokolu. Vyberte si například typický všední den, nikoli konec týdne nebo svátek.

Jakmile zaznamenáte 24 hodin dat sledování výkonu do souboru protokolu, zobrazte doporučené čítače v režimu grafu sledování výkonu a poté zaznamenejte průměrné, minimální a maximální hodnoty do výše uvedené tabulky. Jakmile to uděláte, porovnejte své výsledky s výsledky analýzy níže. Toto srovnání vám dá příležitost identifikovat případná hardwarová úzká hrdla, která ovlivňují váš SQL Server.

Jak interpretovat klíčové čítače sledování výkonu

Níže probereme některé základní čítače sledování výkonu, jejich doporučené hodnoty a některé možnosti, které by měly pomoci identifikovat a vyřešit problémy s hardwarem. Je třeba poznamenat, že jsem omezil počet uvažovaných čítačů sledování výkonu. Je tomu tak proto, že účelem tohoto článku je odhalit jednoduché a zjevné problémy ztráty produktivity. Diskusi o mnoha dalších počítadlech sledování výkonu lze nalézt jinde na tomto webu.

Paměť: Stránky/sekundy

Tento čítač měří počet stránek za sekundu, které jsou vyprázdněny z paměti RAM na disk nebo načteny do paměti RAM z disku. Čím více dochází k odkládání stránek, tím více I/O zatěžuje váš server, což může negativně ovlivnit výkon SQL Serveru. Vaším cílem je pokusit se omezit swapování stránek na minimum, aniž byste ho eliminovali.

Za předpokladu, že SQL Server je jedinou hlavní aplikací běžící na vašem serveru, toto číslo by mělo být ideálně mezi nulou a 20. Je velmi pravděpodobné, že uvidíte odlehlé hodnoty výrazně nad 20, což je zcela normální. Zde je klíčové udržet průměrný směnný kurz stránky pod 20.

Pokud váš server generuje průměrně více než 20 stránek za sekundu, jedním z nejpravděpodobnějších důvodů je nedostatek požadované paměti RAM. Obecně řečeno, čím více paměti RAM je k dispozici, tím méně by se mělo provádět výměny stránek.

Ve většině případů na fyzickém serveru vyhrazeném pro SQL Server s adekvátní RAM bude průměrná swap stránky menší než 20. Adekvátní RAM pro SQL Server lze určit podle následujícího kritéria: server musí mít poměr zásahů do mezipaměti (Buffer Hit Cache Ratio) 99 % nebo vyšší. Tento čítač je popsán dále v tomto článku. Pokud máte SQL Server, který má tento poměr 99 % nebo vyšší za 24 hodin, ale průměrný směnný kurz stránek za stejnou dobu je vyšší než 20, může to znamenat, že používáte jiné aplikace jiný fyzický server než SQL Server. V takovém případě byste měli v ideálním případě tyto aplikace odebrat, aby SQL Server mohl být jedinou hlavní aplikací na fyzickém serveru.

Pokud na vašem SQL Serveru nejsou spuštěny žádné jiné aplikace a výměny stránek překročí 20 v průměru za 24 hodin, může to znamenat, že jste změnili nastavení paměti SQL Serveru. SQL Server musí být nakonfigurován tak, aby byla nastavena možnost "Dynamicky konfigurovat paměť serveru SQL" a nastavení "Maximální paměť" musí být nastaveno na nejvyšší hodnotu. Aby SQL Server fungoval optimálně, měl by mít povoleno zabírat tolik paměti RAM, kolik potřebuje pro své vlastní potřeby, aniž by musel soupeřit o RAM s jinými aplikacemi.

Paměť: Dostupné místo

Dalším způsobem, jak zjistit, zda má váš SQL Server dostatek fyzické paměti RAM, je zkontrolovat čítač Paměťový objekt: Dostupné bajty. Jeho hodnota musí být větší než 5 MB. Jinak váš SQL Server potřebuje více fyzické paměti RAM. Na serveru specializovaném na SQL Server se SQL Server snaží ponechat 4–10 MB volné fyzické paměti. Zbývající fyzickou paměť RAM používá operační systém a SQL Server. Když se velikost dostupné paměti blíží 5 MB nebo méně, je nejpravděpodobnější, že SQL Server dochází k přetížení kvůli nedostatku paměti. V takovém případě musíte zvýšit množství fyzické paměti RAM na serveru, snížit zatížení serveru nebo odpovídajícím způsobem změnit nastavení konfigurace paměti SQL Server.

Fyzický disk: Doba provozu disku %

Tento čítač ukazuje vytížení fyzického diskového pole (nikoli logického oddílu nebo jednotlivého disku v poli). Poskytuje dobré relativní měřítko toho, jak jsou vaše disková pole vytížená.

Obecně platí, že počítadlo času disku by mělo číst méně než 55 %. Pokud hodnoty čítače překročí 55 % za nepřetržité období (více než 10 minut během 24 hodin sledování), může mít váš SQL Server problémy se vstupem a výstupem. Pokud toto chování vidíte jen příležitostně během 24 hodin sledování, příliš bych si nedělal starosti, ale pokud by se to stávalo často (řekněme několikrát za hodinu), pak bych začal hledat způsoby, jak zvýšit výkon I/O na serveru nebo snížit zatížení serveru. Některé způsoby, jak zvýšit I/O disku, jsou přidání nových disků do pole (pokud je to možné), výměna disků za rychlejší, přidání mezipaměti na desce řadiče (pokud je to možné), použití různých verzí RAID nebo instalace rychlejšího řadiče. .

Před použitím tohoto čítače pod NT 4.0 jej musíte ručně povolit zadáním následujícího do příkazového řádku: "diskperf-y". Poté budete muset restartovat server. Proto musíte okamžitě povolit čítače disků pod Windows NT 4.0. Pokud používáte systém Windows 2000, je tento čítač ve výchozím nastavení povolen.

Fyzický disk: Průměrná délka diskové fronty

Kromě sledování hodnoty čítače "Physical Disk: Disk Uptime" je vhodné sledovat i hodnotu čítače průměrné délky diskové fronty (Avg. Disk Queue Length). Pokud tato hodnota překročí 2 pro nepřetržité periody (více než 10 minut během 24hodinového sledování) pro každý disk v poli, může pole představovat problémové místo výkonu systému. Podobně jako u diskového časovače, pokud k tomu občas dojde během 24hodinového sledování, nedělal bych si velké starosti, ale pokud se to děje často, pak bych začal hledat způsoby, jak zvýšit I/O výkon serveru, jak je popsáno výše.

Toto číslo budete muset vypočítat, protože nástroj Sledování výkonu neví, kolik fyzických disků je ve vašem poli. Pokud máte například pole 6 fyzických disků a průměrná délka fronty pro toto pole je 10, pak je skutečná průměrná disková fronta na disk 1,66 (10/6=1,66), což dobře spadá do doporučených 2- o-1 fyzický disk.

Před použitím tohoto čítače pod NT 4.0 se ujistěte, že jste jej ručně povolili zadáním "diskperf-y" do příkazového řádku NT a poté restartováním serveru. Proto je nutné ihned po instalaci Windows NT 4.0 povolit čítače disků. Pokud používáte Windows 2000, bude tento čítač ve výchozím nastavení povolen.

Pomocí obou výše popsaných čítačů přesně zjistěte, zda na vašem serveru dochází k problémům se vstupem a výstupem. Pokud například vidíte mnoho časových období, kdy je doba provozuschopnosti disku větší než 55 % a průměrná délka diskové fronty je větší než 2 na fyzický disk, můžete si být jisti, že má server problém se vstupem a výstupem.

Procesor: CPU čas %

Čítač Processor Object: % Processor Time je dostupný pro každý CPU a odhaduje využití každého jednotlivého CPU. Podobné počítadlo je k dispozici také pro celou sadu centrálních procesorů (celkový počet). Toto je klíčové počítadlo pro sledování využití procesoru. Pokud celková doba zatížení procesoru pro tento čítač překročí 80 % za nepřetržitá období (více než 10 minut během 24hodinového sledování), můžete CPU považovat za problémové místo systému. Pokud se tato období velké zátěže občas objeví a vy si myslíte, že se s tím dá žít, pak je vše v pořádku. Pokud se však vyskytují často, měli byste zvážit možnosti snížení zatížení serveru, jako je nákup rychlejších procesorů, instalace více procesorů nebo nákup procesorů, které mají větší vestavěnou mezipaměť L2.

Systém: Délka fronty CPU

Spolu s čítačem času CPU byste měli sledovat také čítač délky fronty procesoru. Pokud tato frekvence překročí 2 na CPU po nepřetržité období (více než 10 minut během 24hodinového sledování), pak se pravděpodobně jedná o úzké hrdlo systému. Pokud má váš server například 4 CPU, neměla by délka fronty CPU přesáhnout celkem 8.

Pokud délka fronty CPU pravidelně překračuje doporučené maximum, ale využití CPU není tak vysoké (což je typický případ), zvažte snížení hodnoty konfiguračního parametru SQL Server „max. počet pracovních vláken“. Možným důvodem vysoké délky fronty procesoru je přítomnost nadměrného počtu pracovních vláken čekajících, až na ně přijde řada. Snížení jejich počtu, což je to, co uděláte s tímto parametrem, vás nutí používat sdružování vláken (pokud tomu tak již není), nebo zvýšit jeho roli.

Použijte oba popsané čítače společně, abyste přesně určili, zda je problém s CPU. Pokud oba indikátory překračují doporučené hodnoty po stejné nepřetržité časové úseky, můžete si být jisti, že CPU je slabým místem systému.

Vyrovnávací paměť serveru SQL: Míra přístupu do mezipaměti vyrovnávací paměti

Tento čítač (Vyrovnávací paměť serveru SQL: Poměr přístupů mezipaměti vyrovnávací paměti) ukazuje, jak často SQL Server přistupuje k vyrovnávací paměti, nikoli k pevnému disku, aby načetl data. V aplikacích OLTP by tento poměr měl přesáhnout 90 % a v ideálním případě by měl být větší než 99 %. Pokud je četnost zásahů do mezipaměti nižší než 90 %, měli byste jít a koupit více RAM ještě dnes. Pokud je tento poměr mezi 90 % a 99 %, pak byste měli vážně uvažovat o nákupu další paměti RAM, protože čím více se blížíte 99 %, tím rychleji váš SQL Server poběží. V některých případech, pokud je vaše databáze velmi velká, nebudete schopni se přiblížit k 99 %, i když na server vložíte maximální množství paměti RAM. Pak už jen můžete přidat co nejvíce paměti a přijmout status quo.

V aplikacích OLAP může být poměr mnohem nižší kvůli povaze aplikace OLAP. V každém případě by zvýšení RAM mělo urychlit SQL Server.

SQL Server: Uživatelská připojení

Vzhledem k tomu, že počet uživatelů serveru SQL Server ovlivňuje jeho výkon, doporučuje se sledovat čítač připojení uživatelů (Objekt obecných statistik serveru SQL Server: Čítač připojení uživatelů). Zobrazuje počet uživatelských připojení, nikoli počet uživatelů, kteří jsou v daném čase připojeni k serveru SQL.

Pokud je tento čítač větší než 255, měli byste zvýšit konfigurační parametr "Maximum Worker Threads", jehož výchozí hodnota je 255. Pokud počet připojení překročí počet dostupných pracovních vláken, pak SQL Server začne sdílet pracovní vlákna, což může negativně ovlivnit dopadový výkon. Nastavení tohoto parametru by mělo být vyšší než maximální počet připojení, kterých lze dosáhnout na vašem serveru.

Co bude dál

Přestože existuje mnohem více čítačů než těch, které jsme popsali, poslední jmenované jsou klíčové pro monitorování, ke kterému dochází během procesu auditu výkonnosti. Jakmile dokončíte analýzu sledování výkonu, použijte doporučení uvedená v této sérii článků k provedení nezbytných změn, díky kterým bude váš SQL Server fungovat tak, jak má.

Každý správce databáze se pravděpodobně musel vypořádat s tím, že vše funguje pomalu nebo nefunguje vůbec. První věc, kterou musíte zjistit, je, co se na SQL Serveru aktuálně děje. Zdálo by se, že administrátor má ve svém arzenálu tolik užitečných věcí: praštěný Activity Monitor, hromadu dynamických pohledů správy (dmv), uložené procedury sp_who a sp_who2, zděděné z dob SQL Server 7 a SQL Server 2000.
Ale pojďme na to přijít...

Monitorovací nástroje

Monitor aktivity

Zdálo by se to jako skvělá věc, dělá přesně to, co má – sleduje aktivitu. Spustím těžký účetní report a uvidím, co mi Activity Monitor ukáže.
Snímky obrazovky ukazují monitor aktivity ze serveru SQL Server 2005:

A z SQL Server Denali (2012) CTP 3.


Hmmm. Co když takové zprávy spustí tucet lidí? A to není nic neobvyklého... Bude docela nepohodlné na to přijít, i když pokrok je samozřejmě zřejmý. V Denali Activity Monitor ukazuje mnohem užitečnější informace (například na jakém konkrétním zdroji čekání probíhá), navíc můžeme například přímo z monitoru spustit profiler pro požadovanou relaci a sledovat ji již v profileru. , ale sakra, navíc se to načte a už tak přetížený server. Navíc už je problém s brzdami a neuvidíme ty požadavky, které se v době spuštění profileru již začaly vyřizovat.
A to je přesně to, co chci vidět – kdo co právě teď dělá.

sp_who a sp_who2

Snímek obrazovky ukazuje výsledek provádění sp_who (nahoře) a sp_who2 (dole), které byly provedeny při vytváření stejné nešťastné zprávy:


To jo. Velmi informativní. Při pohledu na sp_who vidíme pouze to, že něco běží. Samozřejmě se provádí – proto se díváme, ale vidíme, že se provádí nějaký druh SELECT. Nebo několik SELECTů.
sp_who2 zobrazuje další informace. Nyní můžeme vidět, kolik času procesoru strávila relace (a celkový čas zřejmě sečíst ve sloupci), počet I/O operací, název databáze, ve které se to všechno provádí a kým relace je blokována (pokud je blokována).
Activity Monitor, jak vidíme, poskytuje více informací.

DMV

Počínaje SQL Serverem 2005 máme novou možnost získávat informace o stavu serveru – Dynamic Management Views. MSDN říká toto: "Pohledy a funkce dynamické správy vracejí data o stavu serveru, která lze použít ke sledování stavu instance serveru, diagnostice problémů a ladění výkonu."
V SQL Server 2005 skutečně existuje sada pohledů souvisejících s prováděním dotazů v aktuálním okamžiku (existují však také pohledy pro prohlížení „historie“): zde jsou a jejich počet se verze od verze stále zvyšuje!
Zkušení administrátoři mají jistě připravenou spoustu skriptů, aby získali informace o aktuálním stavu serveru, ale co dělat, když ještě nemáte zkušenosti s prací s DMV, ale už se vyskytly problémy?

sp_WhoIsActive

Adam Machanic (SQL Server MVP a MCITP) vyvinul a neustále vylepšuje uloženou proceduru sp_WhoIsActive, která se spoléhá na stejné DMV a je zatraceně snadno použitelná. Můžete si stáhnout nejnovější verzi sp_WhoIsActive. Sám Adam má sérii článků věnovanou sp_WhoIsActive, skládající se až z 30 (třiceti!) kousků, můžete si to přečíst, ale pokusím se vás zaujmout čtením tohoto materiálu :).
Budeme tedy předpokládat, že jste si tento skript stáhli a spustili na jednom z testovacích serverů (na libovolné verzi, od roku 2005 po Denali). Adam radí uložit jej do databáze hlavního systému, aby se dal volat v kontextu jakékoli databáze, ale není to nutné, jen při volání v kontextu jiné databáze budete muset napsat název celý - DB .schema.sp_whoIsActive.
Tak to zkusíme. Snímek obrazovky ukazuje výsledek jeho provádění při vytváření stejného přehledu:

Výsledek dotazu exec sp_whoIsActive se bohužel nevejde na jednu obrazovku, takže zde je textový popis výstupu uložené procedury volané bez parametrů.

• - pro aktivní požadavek ukazuje čas provedení, pro „spící“ relaci - čas „spící“;
• - vlastně spid;
• - zobrazuje text aktuálně prováděného požadavku nebo text posledního dokončeného požadavku, pokud relace spí;
• - no, rozumíš;
• - velmi zajímavá rubrika. Výstup je ve formátu (Ax: Bms/Cms/Dms)E. A je počet úkolů čekajících na zdroj E. B/C/D je doba čekání v milisekundách. Pokud na uvolnění zdroje čeká pouze jedna relace (jako na snímku obrazovky), zobrazí se její čekací doba, pokud jsou 2 relace, jejich čekací doby se zobrazí ve formátu B/C. Pokud čekají 3 nebo více, uvidíme minimální, průměrnou a maximální dobu čekání na TOMTO zdroji ve formátu B/C/D;
• - pro aktivní požadavek - celkový čas CPU strávený tímto požadavkem, pro spící relaci - celkový čas CPU za „celou životnost“ této relace;
• - pro aktivní dotaz je to počet operací zápisu v TempDB během provádění dotazu; pro spící relaci - celkový počet záznamů v TempDB za celou dobu trvání relace;
• - pro aktivní požadavek - počet stránek v TempDB přidělených pro tento požadavek; pro spící relaci - celkový počet stránek v TempDB přidělených během celé doby trvání relace;
• - pokud jsme náhle někým zablokováni, zobrazí se spid (session_id) osoby, která nás zablokovala;
• - pro aktivní požadavek - počet logických čtení provedených při provádění tohoto požadavku; pro spací relaci - počet stránek přečtených za celou dobu trvání této relace;
• - vše je stejné, ale o nahrávání;
• - pro aktivní požadavek - počet fyzických čtení provedených při provádění tohoto požadavku; pro spací relaci - tradičně celkový počet fyzických čtení za celou dobu trvání relace;
• - pro aktivní požadavek - počet osmikilobajtových stránek použitých při provádění tohoto požadavku; pro spící relaci - kolik celkových paměťových stránek jí bylo přiděleno během celé její životnosti;
• - stav relace - běh, spánek atd.;
• - zobrazuje počet transakcí otevřených touto relací;
• - zobrazuje, pokud je to možné, průběh operace (například ZÁLOHA, OBNOVENÍ), nikdy neukáže, kolik procent SELECT je dokončeno.

Zbývající sloupce v standardní výstup sp_WhoIsActive jsou málo zajímavé a nebudu je popisovat - jejich účel je myslím každému jasný (název_hostitele, název_databáze, název_programu, čas_přihlášení, čas_přihlášení, ID_požadavku, čas_kolekce).

a co? To je vše?

Ne, to není všechno. Budu také mluvit o tom, s jakými (z mého pohledu nejzajímavějšími a nejužitečnějšími) parametry můžete sp_WhoIsActive volat a co z toho vzejde.

• @help je strašně užitečná možnost. Když zavoláme sp_whoIsActive @help = 1 , získáme informace o VŠECH parametrech a výstupních sloupcích na obrazovce. Takže pokud něco zůstane nejasné, můžete se vždy podívat na „nápovědu“
• @filter_type a @filter - umožňují filtrovat výsledek provedení. @filter_type může nabývat hodnot „session“, „program“, „database“, „login“ a „host“. V parametru udáváme, který objekt zvoleného typu nás zajímá. Například chceme vidět všechny relace běžící v hlavní databázi, k tomu zavoláme exec sp_whoIsActive @filter_type = "database", = "master" . V parametru můžete použít "%";
• @not_filter_type a @not_filter – umožňují nám filtrovat „obráceným způsobem“. To znamená, že například chceme vidět vše kromě těch relací, které mají v poli „databáze“ „master“, k tomu spustíme exec sp_WhoIsActive @not_filter_type = „database“, @not_filter = „master“ . No, nebo, chceme vidět, co dělají všichni uživatelé kromě uživatele sa... Může být mnoho aplikací. Parametr @not_filter umožňuje použití "%";
• @show_system_spids = 1 - zobrazí informace o systémových relacích;
• @get_full_inner_text = 1 - pole sql_text bude obsahovat nejen text aktuálního požadavku (výpisu) v dávce (dávce), ale text celé dávky;
• @get_plans - přidá na výstup sloupec s plány provádění dotazů;
• @get_transaction_info = 1 - přidá na výstup počet a objem záznamů v transakčním protokolu a také čas zahájení poslední transakce;
• @get_locks = 1 - doplní na výstup informace o všech zámcích použitých během provádění požadavku;
• @find_block_leaders = 1 – bude sledovat řetězec blokování a zobrazí celkový počet relací čekajících na aktuální relaci k odstranění bloku;
• @output_column_list = "[%]" - co když nechcete vidět informace tempDB ve výstupu sp_whoIsActive? Tato volba vám umožňuje řídit, co bude výstupem;
• @destination_table = "název_tabulky" - pokusí se vložit výsledek spuštění do tabulky, ale nezkontroluje, zda tato tabulka existuje a zda je do ní dostatek práv pro vložení.

To je teď vše

Výsledkem je další mimořádně pohodlný a flexibilní nástroj pro sledování aktuální aktivity na SQL Serveru. Pro jeho normální provoz stačí oprávnění VIEW SERVER STATE a práva pro přístup k dmv.
Také stojí za to přidat v případě, kdy lze server připojit pouze přes