Ale pojďme na to ...
Monitorovací nástroje
Monitor aktivity
Zdálo by se, že je to skvělá věc, dělá přesně to, co je potřeba - sleduje aktivitu. Spustím rozsáhlou účetní sestavu a uvidím, co mi Monitor aktivity ukáže.Na snímcích obrazovky Monitor aktivity ze serveru SQL Server 2005:
A ze serveru SQL Server Denali (2012) CTP 3. 
Hmmm. Co když takové zprávy spouští tucet lidí? A to není neobvyklé ... Pochopit to bude docela nepohodlné, i když pokrok je samozřejmě zřejmý. Monitor aktivity Denali ukazuje mnohem více užitečné informace(například na který konkrétní zdroj se čeká) a navíc můžeme například spustit profiler pro požadovanou relaci přímo z monitoru a sledovat jej již v profileru, ale zatraceně, navíc se načte již načten server. Kromě toho je již problém s brzdami a neuvidíme ty požadavky, které již byly spuštěny v době spuštění profileru.
A přesně tohle chci vidět - kdo a co právě dělá.
sp_who a sp_who2
Snímek obrazovky ukazuje výsledek spuštění sp_who (výše) a sp_who2 (níže), provedeného během vytváření stejné nešťastné zprávy:
To jo. Velmi informativní. Při pohledu na sp_who vidíme pouze, že se něco provádí. Samozřejmě se provádí - hledáme to a vidíme, že se provádí nějaký druh SELECT. Nebo pár SELECT s. Skvělé.
sp_who2 již zobrazuje více informací. Nyní vidíme, kolik času procesor strávil relací (a očividně sečte celkový čas ve sloupci), počet operací I / O, název databáze, ve které se toto vše provádí a kdo zablokoval tuto relaci (pokud je uzamčena).
Activity Monitor, jak vidíme, poskytuje více informací.
DMV
Počínaje SQL Serverem 2005 jsme dostali nová příležitost přijímat informace o stavu serveru - Dynamic Management Views. MSDN říká: „Zobrazení a funkce dynamické správy vracejí data o stavu serveru, která lze použít ke sledování stavu instance serveru, diagnostice problémů a vyladění výkonu.“Ve skutečnosti v roce 2005 SQL Server „nemá sadu zobrazení spojených s prováděním dotazů v aktuálním okamžiku (existují však i zobrazení pro prohlížení„ historie “): tady jsou. A jejich počet se od verze stále zvyšuje na verzi!
Zkušení administrátoři mají jistě připravenu spoustu skriptů, které získají informace o aktuálním stavu serveru, ale co když s DMV zatím nemáte žádné zkušenosti, ale již máte 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á právě na tyto DMV a je zatraceně snadno použitelná. Stažení Nejnovější verze sp_WhoIsActive je možné. Sám Adam má sérii článků věnovaných sp_WhoIsActive, která se skládá až z 30 (třiceti!) Kusů, můžete si ji přečíst, ale pokusím se vás zaujmout čtením tohoto materiálu :).Budeme tedy předpokládat, že jste si stáhli a spustili tento skript na jednom z testovacích serverů (na jakékoli verzi od roku 2005 do Denali). Adam radí ukládat do hlavní systémové databáze, aby ji bylo možné 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 v plném rozsahu - DB .schema.sp_whoIsActive.
Zkusme to tedy. Snímek obrazovky ukazuje výsledek jeho provedení při vytváření stejné sestavy:
Výsledek dotazu exec sp_whoIsActive se bohužel nevejde na jednu obrazovku, takže zde je textový popis výstupu uložené procedury nazvaný bez parametrů.
- - u aktivního požadavku ukazuje čas provedení, u relace „spící“ - čas „spánku“;
- - vlastně, spid;
- - zobrazuje text právě prováděného požadavku nebo text posledního spuštěného požadavku, pokud relace spí;
- - dobře, dostanete nápad;
- je velmi zajímavý sloupek. Výstup je ve formátu (Ax: Bms / Cms / Dms) E. A je počet čekajících úkolů na zdroji E. B / C / D je čekací doba v milisekundách. Pokud na uvolnění zdroje čeká pouze jedna relace (jako na snímku obrazovky), zobrazí se její časový limit, pokud 2 relace - jejich časové limity ve formátu B / C. Pokud se očekávají 3 nebo více, uvidíme minimální, průměrnou a maximální čekací dobu 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 pro „celý život“ této relace;
- - u aktivního požadavku je to počet zápisů do TempDB během provádění požadavku; 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 TempDB přidělených pro tento požadavek; pro spící relaci - celkový počet stránek TempDB přidělených po celou dobu trvání relace;
- - pokud nás najednou někdo zablokuje, zobrazí se spid (session_id) toho, kdo nás zablokoval;
- - pro aktivní požadavek - počet logických čtení provedených při provádění tohoto požadavku; pro spící relaci - počet přečtených stránek za celou dobu trvání této relace;
- - všechny stejné, ale o záznamu;
- - u aktivního požadavku 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 přečtení za celou dobu trvání relace;
- - pro aktivní požadavek - počet stránek 8 kB použitých při provádění tohoto požadavku; pro spící relaci - kolik stránek celkové paměti mu bylo přiděleno během celého jeho života;
- - stav relace - běh, spánek atd .;
- - ukazuje počet transakcí otevřených touto relací;
- - pokud je to možné, ukazuje proces provádění operace (například BACKUP, RESTORE), nikdy nezobrazí procento provedeného SELECT.
A co? Je to všechno?
Ne, to není vše. 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 nazvat a co z toho vzejde.- @help je hrozný užitečný parametr... Když zavoláme sp_whoIsActive @help = 1, získáme na obrazovce informace o VŠECH parametrech a výstupních sloupcích. Pokud tedy něco zůstane nejasné, můžete vždy vidět „pomoc“
- @filter_type a @filter - umožňují filtrovat výsledek provádění. @filter_type může být „relace“, „program“, „databáze“, „přihlášení“ a „hostitel“. V parametru uvedeme, o jaký typ objektu vybraného typu máme zájem. Chceme například vidět všechny relace spuštěné v hlavní databázi, proto tomu říkáme exec sp_whoIsActive @filter_type = "databáze", = "hlavní". Parametr může používat "%";
- @not_filter_type a @not_filter nám umožňují filtrovat „naopak“. Tj. 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 = „databáze“, @not_filter = „hlavní“. No, nebo chceme vidět, co dělají všichni uživatelé kromě uživatele sa ... Může existovat mnoho aplikací. Parametr @not_filter může používat "%";
- @show_system_spids = 1 - zobrazí informace o relacích systému;
- @get_full_inner_text = 1 - pole sql_text bude obsahovat nejen text aktuálního požadavku (příkazu) v balíčku (dávce), ale celý text dávky;
- @get_plans - přidá na výstup sloupec s plány provádění dotazu;
- @get_transaction_info = 1 - přidá na výstup počet a objem položek v protokolech transakcí a také čas zahájení poslední transakce;
- @get_locks = 1 - přidá na výstup informace o všech zámcích uložených během provádění požadavku;
- @find_block_leaders = 1 - bude sledovat blokující řetězec a zobrazí celkový počet relací čekajících na odblokování bloku aktuální relací;
- @output_column_list = "[%]" - co když nechcete vidět informace o tempDB ve výstupu sp_whoIsActive? Pomocí tohoto parametru můžete ovládat, co zobrazuje;
- @destination_table = "název_tabulky" - pokusí se vložit výsledek spuštění a zapsat do tabulky, ale nezkontroluje, zda tato tabulka existuje a zda je do ní vloženo dostatečné množství práv.
Nyní je to
V důsledku toho máme další extrémně pohodlný a flexibilní nástroj pro sledování aktuální aktivity na serveru SQL Server. Pro jeho normální provoz stačí oprávnění ZOBRAZIT SERVEROVÝ STAV a práva na přístup k dmv.Také stojí za to přidat v případě, že je možné se připojit k serveru pouze pomocí
to software od Sybase, pracující ve spojení se serverem SQL Server a vydávající grafická forma různé informace o výkonu serveru. Tyto informace jsou velmi užitečné při analýze důvodů jeho snížení výkonu.
verze 11.0.1 má řadu důležitých nových funkcí, které se výrazně liší nová verze ze všech předchozích. 11.0.1 může fungovat s jakoukoli verzí serveru SQL Server od 4.9.2 do systému 11.
Některé zajímavější typy informací o tom, jak se používají databázové objekty a jak server interaguje se sítí, jsou však hlášeny pouze při monitorování systému SQL Server System 10 a System 11. Samozřejmě, pojmenované vyrovnávací paměti mezipaměti jsou hlášeny pouze při sledování výkonu systému SQL Server 11.
Pro kompatibilitu s předchozí verze 11.0.1 také podporuje režim výstupu statistických informací o výkonu serveru do souborů, které lze použít pro následné srovnání a analýzu. Tato funkce je v praxi velmi užitečná, ale komplikuje proces instalace.
sestává ze dvou komponent: serverového modulu, který běží na stejném počítači se serverem SQL Server, aby poskytoval přístup do oblasti sdílené paměti serveru, a klientského modulu, který lze spustit na jakémkoli počítači. Hlavním úkolem klientského modulu je přečí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, při spuštění sqlmon (klientský modul) musíte zadat parametr - nomem.
Výchozí konfigurace umožňuje současné připojení až pěti klientských modulů k jednomu serveru. Jinými slovy, k jednomu modulu serveru se může připojit buď pět klientských modulů s jedním oknem na každém klientovi, nebo jeden klient s pěti otevřenými okny.
Maximální počet současně otevřených oken klienta je nastaven při spuštění modulu serveru.
Chcete -li tedy v příkazovém souboru pro spuštění modulu serveru podporovat 20 oken, musíte zadat parametr n2 0. V takovém případě budete muset změnit adresu začátku oblasti sdílené paměti serveru pomocí příkazu buildmaster a některých jiné akce. Tyto kroky by nikdy neměly být prováděny, pokud je spuštěn SQL Server. (Podrobnosti o procesu rozšiřování počtu souběžných klientů najdete v příručce Server Supplement.)
má nějaké nevýhody. Například sloupcový graf ukazující počet provedených I / O operací a další charakteristiky provozu serverových zařízení je schopen současně vykazovat data pouze na omezeném počtu zařízení.
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 do diagramu zahrnuty informace, a také přepínat mezi různými sadami zařízení.
Textová tabulka, která se zobrazí na obrazovce současně s diagramem, obsahuje seznam všech serverových zařízení, ale obsahuje pouze celkový počet operací I / O pro každé z nich. Díky tomu je obzvláště obtížné pracovat s velkým serverem, který má mnoho serverových zařízení, která podporují vlastní databázové střepy pro zlepšení výkonu. V tomto případě je analýza práce všech dostupných segmentů nemožná.
také neumožňuje dlouho zobrazit dynamiku změn v ukazatelích výkonu.
Je schopen zobrazovat data na 60 po sobě jdoucích intervalech měření výkonu na obrazovce. V závislosti na zvoleném trvání každého intervalu mohou takové statistiky pokrývat poměrně velké časové období. Tato technika však neumožňuje porovnat aktuální data s ukazateli před měsícem nebo rokem.
Obrázky z oken programu lze samozřejmě odeslat na tiskárnu, ale pak musíte uložit sady souborů nebo hory výtisků, abyste mohli posoudit budoucí výkon serveru. V praxi musí správce serveru často znovu přezkoumat data z různých období obchodního cyklu společnosti a porovnat informace v obdobných obdobích po sobě jdoucích hospodářských cyklů, aby získal představu o skutečném výkonu serveru.
Protož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á cesta měření - provedení standardní sada testovací transakce.
Lze jej použít v přítomnosti i v nepřítomnosti na serverovém počítači. I když neexistují žádné klientské moduly, serverový modul programu pokračuje ve své 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 konkrétním aspektu fungování serveru.
Hlavní okno
Zde je seznam oken podporovaných programem. Pokud nebyl při spuštění sglmon - klientského modulu zadán parametr - nomem - v tomto okně se také zobrazí výsečový graf využití paměti serveru.
Vyrovnávací paměti cache
Toto okno zobrazuje grafy charakterizující činnost procedur a vyrovnávací paměti mezipaměti dat. Řízením počtu fyzických a logických I / O operací v mezipaměti dat může uživatel určit, kolik datových stránek server vytvoří pomocí stránek, které jsou již ve vyrovnávací paměti. Tyto statistiky z vyrovnávací paměti dat a vyrovnávací paměti procedur lze použít k určení celkového množství paměti požadované mezipaměti serveru a vztahu mezi mezipaměti dat a procedur.
Mezipaměť datové vyrovnávací paměti, pouze SQL Server System 11 (Data Cach)
Okno hlásí počet fyzických a logických I / O operací pro každou z pojmenovaných vyrovnávacích pamětí mezipaměti nakonfigurovaných na serveru.
Disk I / O (Device I / O)
Zde najdete grafy a souhrnné tabulky pro aktuální a celkový počet přístupů na disk. Pomáhají optimalizovat rozdělení zátěže I / O mezi dostupná serverová zařízení. Při analýze výstupu informací je užitečné použít standardní schéma pro výběr názvů serverových zařízení podle názvů odpovídajících oddílů 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, jaký každý řadič disku k nim je připojeno.
Sítě, pouze pro SQL Server System 10 a 11 (síťová aktivita)
Okno říká statistické informace o výstupu síťového vstupu - velikosti paketů, objemy provozu atd.
Object Lock, pouze SQL Server System 10 a 11 (Object Lock Status)
Zobrazuje informace o zámcích o přístupu k datovým tabulkám, včetně podrobné distribuce typů použitých zámků, názvů procesů, které zámky drží atd.
Objektová stránka I / O, pouze pro SQL Server System 10 a 11 (objektová stránka I / O)
Okno obsahuje informace o rychlosti I / O stránek jedné z datových tabulek serveru. Všimněte si efektivity v seznamu nejčastěji používaných serverových tabulek. Sp_sysmon tyto informace nezobrazuje.
Souhrn výkonu
Zde je přehled toho, jak si SQL Server vede - využití CPU, transakce zpracované za sekundu, síťový provoz, I / O disku a využití zámku.
Trend výkonu
Okno vykresluje průběžné grafy časových ukazatelů výkonu serveru zobrazené v okně Souhrn výkonu.
Aktivita procesu serveru (Process Activit)
Okno vám umožňuje vybrat jeden nebo více serverových procesů a sledovat využití procesoru a svazky I / O pro každý z 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ávání příkazu sp_who server.
Používání zámků (Process Lock Activity)
Okno zobrazuje informace o použití zámků vybraným procesem serveru.
Aktivita uložené procedury
Okno obsahuje informace o provádění uložených procedur a době běhu každé procedury.
Zpracování transakcí
V okně vidíte sloupcový graf zobrazující počet zpracovaných transakcí s distribucí do odlišné typy transakcí. Můžete například vidět, kolik transakcí lze provést pomocí mechanismu aktualizace na místě.
26. 12. 2006 Kevin Kline
Jakou poslední otázku by si DBA chtěl položit? Pravděpodobně zpráva od uživatele o degradované aplikaci nebo otázka, co se stalo s databází. Musíme vše odložit a přejít do „nouzového režimu“ s otázkou, jak dlouho to bude trvat. Vzhledem k tomu, že jednou z hlavních povinností správce databází je zajistit vysoce kvalitní fungování průmyslových databází, zbývá pouze co nejrychleji odstranit poruchu. Zpravidla není čas zjistit příčinu selhání.
Už žádné spěchající úlohy - jen systematické pozorování
Je to ale jediná věc, kterou lze udělat? K dispozici je schopnost proaktivně monitorovat výkon, jednoduchý postup správy, který využívá základní výkon systému, benchmarking a kontinuální monitorování. V tomto článku vysvětlím, jak aplikovat proaktivní monitorování a jak pomocí něj vytvořit bezplatný monitorovací systém pomocí Windows Monitor systému.
Proaktivní sledování
Proaktivní sledování výkonu je jednoduchý systém, který vám umožní vyřešit problémy dříve, než se stanou kritickými. Někdo pravděpodobně již používá monitorování výjimek, kde se vytvářejí automatizované procesy, které zaznamenávají pouze odchylky od normy, ale neposkytují hloubkové informace a neposkytují příležitosti k předcházení problémům. Proaktivní sledování výkonu naopak poskytuje uživateli všechny druhy informací o pracovním prostředí a aplikacích, krátkodobých i dlouhodobých. Jsou převzaty čítače výkonu databáze, nastaveny referenční metriky a je udržován aktivní monitorovací režim.
Jak naznačuje název, proaktivní sledování výkonu vyžaduje akci. Nastavení zabere trochu času a pochopení fungování databází a aplikací. Aby bylo proaktivní sledování výkonu účinné, je třeba zkontrolovat zprávy, abyste mohli využít shromážděná rozsáhlá data.
Základní parametry, reference, monitor
Začněme definováním několika pojmů. Základní parametry je sada parametrů, které představují chování serveru a aplikace za normálních podmínek. Základní parametry jsou získány jako průměry na základě výsledků několika měření prováděných za stejných podmínek; jsou měřítky pro srovnání.
Srovnávací test ukazuje výkon systému na 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, kolik jsou nad nebo pod normou (tj. když server funguje špatně) . Stejně jako u základních linií jsou referenční hodnoty zachyceny v kontrolovaném prostředí, klíčové hodnoty jsou určeny ve vztahu k předdefinovaným metrikám. Pokud potřebujete zjistit, jak se server a aplikace chovají na několika úrovních nebo typech načítání, obvykle se získá několik referenčních hodnot (ve vztahu k základním parametrům)
Monitorování je plánované monitorování serveru v reálném čase za předem definovaných podmínek (sady podmínek definovaných pro další vyšetřování nebo varování). Pokud například potřebujete vědět, jak dlouho trvá úspěšné dokončení důležité obchodní aplikace, jak dlouho to trvá záloha nebo když jsou dosaženy určité hodnoty výkonu, jsou tyto konkrétní události monitorovány.
Nyní přejdeme k proaktivnímu monitorování. Můžete použít produkty třetích stran nebo bezplatné řešení, které používá Sledování systému. Řešení od jiných dodavatelů mohou zjednodušit proces nastavení proaktivního monitorování a mít jiné funkce, než může poskytnout bezplatné integrované řešení. Než ale začnu, ukážu vám, jak začít s proaktivním monitorováním pomocí nástroje Sledování systému.
Krok 1: Určete základní parametry výkonu.
V prvním kroku zajištění režimu proaktivního monitorování je vytvořena sada základních parametrů pro provoz databázového serveru. Tento agregát udává výkon serveru za normálních podmínek a pomáhá dokumentovat a porozumět všem relevantním procesy na pozadí, také pomáhá identifikovat situace, které „nevyžadují zásah“, aby je v budoucnu ignoroval. Jinými slovy, správci databází mohou určit možnosti ignorování systémových zpráv, protože jinak se generuje velký počet falešných oznámení.
Aby bylo možné vizualizovat kvalitu výkonu, používají nejlepší základní linie několik grafů (ideálně jeden), takže můžete na první pohled vidět, jak si server vede. Když jsou určeny základní parametry, musíte 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. Je ideální mít obojí: deníky vám umožňují kdykoli se vrátit ke čtení a analyzovat, jaký byl výkon, když systém nebyl přímo monitorován. Monitorování v reálném čase nezabírá místo na disku a prostředky serveru, ale vyžaduje 100 procent pozornosti vašeho systému. Za druhé, musíte určit interval, ve kterém budete monitorovat, s přihlédnutím k nákladům na výkon pro sběr dat a datové I / O a odhadnout náklady na požadovaný prostor. Čím větší je interval, tím vyšší je pravděpodobnost, že požadované údaje o výkonu nebudou získány. Nakonec zvolte místní nebo vzdálené monitorování. Lokální monitorování, při kterém monitorovací proces využívá monitorovaný server, zvyšuje režii procesoru a disku serveru. Vzdálené monitorování, které používá samostatný server, může tyto problémy odstranit, ale výrazně zvyšuje pracovní zátěž v síti.
Uvádí metriky nebo čítače sledování systému, které se doporučují použít k určení základní linie. Nemohu říci, jaký význam je v kontextu dané aplikace „správný“, protože se liší systém od systému. Pomocí průměru různých základních linií stanovte typický základní výkon a označte, že je to správná volba pro operační systém.
Definování základních parametrů pomocí nástroje Sledování systému
Nyní pro účely shromažďování základních parametrů zavoláme Sledování systému. Otevřeme Ovládací panely, Nástroje pro správu, Výkon. Poklepejte na protokoly výkonu a upozornění v levém podokně. Klikněte pravé tlačítko na Counter Logs a přejděte na New Log Settings. Zadejte název plánu a klikněte na OK. V dialogovém okně Vybrat čítače vyberte první čítač a poté klikněte na Přidat. Opakujte tyto kroky, dokud nebudou přidány všechny čítače, poté klikněte na Zavřít.
Chcete -li začít, zkuste výchozí 15sekundový interval. Nebo vyberte jiný interval kliknutím na Vlastnosti (nebo použijte klávesovou zkratku Ctrl + Q) a poté zadejte hodnotu do pole Ukázka automaticky každých: _ sekund. Delší intervaly zabírají méně místa, ale poskytují méně podrobná data.
Vyberte tabulku Protokoly a definujte umístění, kam budou data uložena. Data je možné zobrazit později pomocí zobrazení Zobrazit data souboru protokolu. Monitor systému bude při shromažďování údajů o výkonu podle výchozího stavu vypadat jako na obrázku 1. Je vidět, že mnoho dat lze shromáždit současným sledováním mnoha čítačů, takže byste měli pečlivě vybrat čítače pro hlavní řádek.
Krok 2: Nastavení referenčních hodnot
Jakmile nastavíte základní výkon serveru, můžete začít nastavovat měřítka, která vám pomohou porozumět výkonu vašeho serveru v několika předdefinovaných situacích.
Pro standardy se používá stejný režim monitorování jako pro stanovení základních parametrů. Můžete použít své vlastní řešení nebo jeden z nejběžnějších průmyslových nástrojů, jako je TPC-C nebo SAP, ale nejlepších výsledků benchmarku se dosahuje vývojem obvyklých vlastních scénářů, které jsou nakonfigurovány tak, aby používaly konkrétní databázový server a jeho aplikace.
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í. Sběr dat z provádění zátěžových testů a analýza získaných dat může trvat ještě déle.
Jakmile určíte základní výkon serveru v rámci předdefinovaných úloh, uvidíte, co od svého systému očekávat. Pomocí údajů shromážděných z referenčních hodnot vytvořte základ pro rutinní sledování. Například se ukázalo, že server je schopen až 249 transakcí za sekundu, než začne zpomalovat. V tomto případě můžete nastavit oznámení s nízkou prioritou, když server dosáhne zatížení přibližně 200 TPS, a oznámení s vysokou prioritou, když server dosáhne 235 TPS. Tato metoda umožní správci vědět o možných problémech se serverem a provést nezbytná opatření, než si uživatelé čehokoli všimnou. A žádné kritické situace. Nyní je to možné.
Krok 3: Běžné monitorování
Asi nejdůležitější součástí proaktivního monitorovacího režimu je rutinní monitorování. Bez něj nemůžete sledovat výkon databáze ani zjišťovat problémy s výkonem.
Můžete vytvořit levný nástroj pro sledování serveru SQL Server pomocí kombinace agenta serveru SQL a nástroje Sledování systému. SQL Server Agent vám umožňuje určit, která událost vyvolala chybu monitoru, určit, kdo přijímá oznámení o událostech, a automaticky odeslat oznámení, když dojde k chybové události.
Instalace serveru SQL Server Agent může být časově náročná a složitá, takže budete muset nahlédnout do části Výstrahy na serveru SQL Server Knihy online (BOL)... Agent serveru SQL Server obvykle monitoruje chybové zprávy databázového serveru a nesleduje provádění.
K monitorování výkonu serveru slouží Monitor systému k monitorování aktuálních čítačů (nastavte frekvenci dotazování s přesností 15 minut).
Paměťové stránky / s
Celkové bajty síťového rozhraní / s
Přenosy fyzického disku na disk / s
Procesor-% času procesoru
SQLServer: Přístupové metody-úplné skenování / s
SQLServer: Poměr přístupů do mezipaměti správce vyrovnávací paměti
SQLServer: Databáze Aplikace Databáze Transakce / s
SQLServer: Obecné statistiky-připojení uživatelů
SQLServer: Západky-průměrná čekací doba na západku
SQLServer: Zámky-průměrná čekací doba
SQLServer: Časové limity zámků / s
SQLServer: Zámky-počet zablokování / s
SQLServer: Memory Manager-Memory Grants Pending
Nastavte hodnotu pro každý čítač mezi základními hodnotami a referenčními hodnotami při testování. Můžete například nastavit upozornění, když čítač dosáhne 75 procent nejvyšší hodnoty zatížení, a varovnou zprávu, když projde 90 procent.
Chcete -li provést varování, můžete použít nástroje zdarma například výstrahy a oznámení serveru SQL Server, Sledování systému nebo nákup nástroje Microsoft Operations Manager (MOM) nebo jiných nástrojů. Doporučuji nastavit varová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 lze zasílat na upozornění administrátorů prostřednictvím E-mailem, pager nebo síť. Automatická upozornění můžete nastavit pro následující zdroje zpráv:
- Protokol SQL serveru
- Protokol agenta SQL
- časopis Windows aplikace, Zabezpečení a systém
- Protokol provádění úlohy serveru SQL
Nakonec se musíte ujistit, že vaše vlastní aplikace správně zaznamenávají chyby a také reagovat na chybové zprávy z jiných vyvinutých aplikací.
Proaktivně sledovat výkon serveru SQL Server znamená identifikovat základní parametry výkonu serveru i aplikace; nastavení referenčních hodnot, které simulují výkon serveru podle předem stanoveného použitého scénáře; a provádění plánovaného monitorování, ideálně spuštění výstrahy při zjištění problému. Ať už používáte bezplatné nebo vestavěné nástroje nebo volíte řešení třetích stran, kontrola zajišťuje, že získáte správné informace o svých aplikacích spuštěných na serveru SQL Server, kdykoli je potřebujete.
Tabulka 1. Objekty a čítače monitorování systému pro definování základních parametrů
| Objekt a počítadlo | Popis |
| Paměťové stránky / s | Počet stránek ke čtení nebo zápisu na disk za sekundu. Toto počítadlo je primárním indikátorem typů chyb způsobených zpoždění systému nebo problémy s výkonem |
| Celkové bajty síťového rozhraní / s | Počet bytů, které procházejí síťové rozhraní za sekundu. Když tento čítač klesá nebo je trendem, znamená to, že aplikaci mohou ovlivňovat problémy se sítí. |
| Přenosy fyzického disku na disk / s | 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í spuště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ý uživatel jsou pravděpodobně ignorovány |
| SQLServer: Přístupové metody-úplné skenování / s | Počet neomezených naplněných tabulek nebo indexových skenů za sekundu. Downgrade tohoto čítače k lepšímu, protože pohledy často způsobují problémy s mezipamětí pod prostředky |
| SQLServer: Poměr přístupů do mezipaměti správce vyrovnávací paměti | Procento stránek, které nevyžadovaly čtení z disku. Čím vyšší číslo, tím menší počet I / O disku. Na dobře vyladěném systému by tato hodnota měla být 80 nebo vyšší. |
| SQLServer: Růst databází-protokolů | Jak moc se pro konkrétní databázi zvýšil soubor transakcí. Na dobře vyladěném systému by měl být tento čítač nízký, pravděpodobně méně než jeden za několik dní. |
| SQLServer: Databáze Aplikace Použitý protokol procenta databáze | Procento volného místa v souboru protokolu. Tento čítač se liší podle plánu, ale neměl by dosáhnout 100 |
| SQLServer: Databáze Aplikace Databáze Transakce / s | Počet transakcí potvrzených do databáze. Tento čítač občas spadá do standardů. Sledujte, kdy se transakce začnou řadit do fronty, což znamená, že I / O disku může být pomalé |
| SQLServer: Západky-průměrná čekací doba na západku | Průměrná doba zpoždění požadavku před vyplněním. Tato hodnota čítače může být vysoká, pokud server čelí soupeření o prostředky, zejména paměť nebo I / O. |
| SQLServer: Locks-průměrná čekací doba, Lock Waits / s, počet zablokování / s | Dočasné zámky obsahují prostředky serveru SQL Server. Sledujte vzestupnou tendenci těchto blokování souvisejících čítačů, což naznačuje možný problém s výkonem |
| SQLServer: Obecná statistika-připojení uživatelů | Počet uživatelských připojení k databázovému serveru. Zkontrolujte, zda nedochází k výrazným posunům hodnoty tohoto čítače. Mohou naznačovat problémy se sítí a indikují zatížení a zpomalení |
| SQLServer: Memory Manager-Memory Grants Pending | Aktuální počet procesů čekajících na přidělení místa v paměti. Vysoká nebo rostoucí hodnota může znamenat nedostatečnou paměť |
| SQLServer: Uživatelsky nastavitelný dotaz (vyhledávací dotaz) | Specializovaný čítač, známý také jako ukazatel dotazu. Tento čítač je uživatelsky generovaný dotaz, který udává celkovou rychlost nebo účinnost systému. Chcete -li nastavit tuto hodnotu, aplikace zavolá sp_user_counter1 a vrátí číselnou hodnotu. |
Počínaje rokem 2008 byl do sestavy SQL Server přidán Performance Data Collector (PDC). Nová součást Management Studio navržená tak, aby koncovým uživatelům usnadnila sledování a ladění výkonu instancí serveru SQL Server.
Komponenty, které jsou ve výchozím nastavení nainstalovány, se nazývají sada systému sběru, konkrétně:
- Využití místa na disku. Shromažďování dat o využití místa na disku v databázi.
- Statistiky dotazů... Zprávy o statistiky dotazů, text individuální žádosti, plány požadavků a konkrétní požadavky.
- Monitorování aktivity serveru... Sbírá statistika využití zdrojů a produktivita data ze serveru, operační systém a SQL server.
Výhody:
- Snadná konfigurace. Konfigurace vyžaduje jen pár kliknutí.
- Snadno sledujte události, testujte a sledujte celkový stav systému.
- Centralizované ukládání dat.
- Citlivost. Zahrnuje možnost vytvořit si vlastní systém sběru dat
Omezení:
- Kompatibilní pouze s verzí SQL Server 2008.
- Systém shromažďování dat online nezobrazuje informace o místě na disku
Fáze přípravy:
- V prvním kroku přípravy musí být na serveru vytvořena složka pro čtení / zápis pro službu SQLSERVERAGENT. Všechno Technické informace budou shromážděny v této složce a poté načteny do databáze monitorovacího systému.
- Databáze monitorovacího systému musí být vytvořena před zahájením monitorování. Tato základna data jsou v podstatě běžnou databází SQL a obsahují všechna data získaná monitorovacím systémem.
- Předem se postarejte o množství místa na disku. Předpokládaný růst databáze je zhruba 250 - 350 MB za den.
- Data jsou ve výchozím nastavení vymazána každých 14 dní. Hloubku čištění lze změnit v závislosti na specifikovaných požadavcích.
- Sada kolekce Použité místo na disku sleduje růst databáze a souborů protokolu a poskytuje statistiky souborů, jako je průměrný růst (v megabajtech) za den. Stav disku je dotazován každých 5 sekund, data jsou každou hodinu zapsána do databáze a uložena po dobu 90 dnů. Tyto intervaly lze upravit.
- Sada kolekce Statistiky dotazů shromažďuje statistiky dotazů a také jednotlivé texty dotazů, plány dotazů a konkrétní dotazy. Tato data v kombinaci se systémovou statistikou a akcemi umožňují podrobnou analýzu jednotlivých dotazů pod úrovní relace. Plánovaná přenosová frekvence - každých 15 minut, ukládání dat po dobu 14 dnů. Tyto intervaly lze upravit.
- Sada kolekce aktivit serveru poskytuje obecná informace Aktivita serveru SQL Server, využití prostředků serveru SQL Server a konflikt mezi prostředky serveru SQL Server. Tato kolekce také poskytuje zapouzdřený pohled na využití všech systémové prostředky určit, jak se problémy s výkonem týkají aktivit mimo rozsah serveru SQL Server. Statistiky aktivity serveru se zaznamenávají každých 60 sekund, pro aktivní relace a požadavky je tento interval 10 sekund
- MSDB se používá k ukládání informací o konfiguraci, běhu, auditování a protokolování sbírek. Balíčky SSIS jsou uloženy v MSDB.
- Je nutné nainstalovat agenta serveru SQL Server.
- Služba integrace serveru SQL Server musí být spuštěna, protože Ke shromažďování dat se používají balíčky SSIS. Balíčky SSIS také generují události během shromažďování dat, které se používají k monitorování a odstraňování problémů s procesem shromažďování.
- Zabezpečení sběratelů dat. V průvodci „Konfigurovat Datový sklad Průvodce ", je třeba namapovat role pro sběratele dat a uživatelské účty. Patří sem: mdw_admin, mdw_reader a mdw_writer.
- mdw_reader - slouží k přihlášení uživatelů, kteří potřebují archivované zprávy;
- mdw_writer - Role může načítat a zapisovat data do úložiště dat. Proto každý SQLServerAgent použitý na vzdálených sběračích dat ukládá data do centrální databáze.
- mdw_admin - čtení, zápis, aktualizace a odstranění přístupu do databáze. Žádný Účet uživatel přiřazený k roli mdw_admin může změnit schéma na soubor mdw a spustit úlohy údržby.
Ladění výkonu sběrače dat
Nejprve vytvořme úložiště dat pro správu
Nyní nastavíme úložiště dat pro správu.
Na uvítací obrazovce klikněte na „Další“
Zadání názvu a umístění databáze
Přiřaďte uživateli roli mdw_admin.
Kontrola konfigurace. Pokud je vše v pořádku, klikněte na „Dokončit“ a pokračujte v procesu konfigurace.
Probíhá proces konfigurace ...
Konfigurace je dokončena.
Nyní, po provedení databázových dotazů na serveru, můžete zobrazit sestavy těchto spuštění. Chcete -li zobrazit přehledy, rozbalte kartu „Správa“ -> „Sběr dat“.
Níže uvedený snímek obrazovky ukazuje, jaká data o výkonu jsou uložena v místní mezipaměti před načtením dat.
Zde také můžete vidět souhrnnou zprávu o využití místa na disku.
Jak vidíte, využití místa na disku v databázi je znázorněno na obrázku níže.
Historie statistik dotazů.
Tato sestava zobrazuje dotazy náročné na prostředky podle kategorie.
Můžete kliknout na libovolný požadavek a získat podrobné informace o tomto požadavku.
Níže se nachází detailní informace na vybranou žádost.
Každý správce databáze se pravděpodobně musel vyrovnat s tím, že vše funguje pomalu, nebo nefunguje vůbec. První věc, kterou je třeba zjistit, je to, co se aktuálně děje na serveru SQL Server. Mohlo by se zdát, že v arzenálu správce je tolik užitečných věcí: chlap Activity Monitor, spousta Dynamic Management Views (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 ...
Monitorovací nástroje
Monitor aktivity
Zdálo by se, že je to skvělá věc, dělá přesně to, co je potřeba - sleduje aktivitu. Spustím rozsáhlou účetní sestavu a uvidím, co mi Monitor aktivity ukáže.
Na snímcích obrazovky Monitor aktivity ze serveru SQL Server 2005:
a ze serveru SQL Server Denali (2012) CTP 3. 
Hmmm. Co když takové zprávy spouští tucet lidí? A to není neobvyklé ... Pochopit to bude docela nepohodlné, i když pokrok je samozřejmě zřejmý. V Denali ukazuje Activity Monitor mnohem užitečnější informace (například o tom, na který konkrétní zdroj čeká čekání), a navíc můžeme například spustit profiler pro požadovanou relaci přímo z monitoru a sledovat jej již v profileru "Ale, sakra, to navíc načte a již načte server." Kromě toho je již problém s brzdami a neuvidíme ty požadavky, které již byly spuštěny v době spuštění profileru.
A přesně tohle chci vidět - kdo a co právě dělá.
sp_who a sp_who2
Snímek obrazovky ukazuje výsledek spuštění sp_who (výše) a sp_who2 (níže), provedeného během vytváření stejné nešťastné zprávy: 
To jo. Velmi informativní. Při pohledu na sp_who vidíme pouze, že se něco provádí. Samozřejmě se provádí - hledáme to a vidíme, že se provádí nějaký druh SELECT. Nebo pár SELECT s. Skvělé.
sp_who2 již zobrazuje více informací. Nyní vidíme, kolik času procesor strávil relací (a očividně sečte celkový čas ve sloupci), počet operací I / O, název databáze, ve které se toto vše provádí a kdo zablokoval tuto relaci (pokud je uzamčena).
Activity Monitor, jak vidíme, poskytuje více informací.
DMV
Počínaje SQL Serverem 2005 jsme dostali novou možnost získávat informace o stavu serveru - Dynamic Management Views. MSDN říká: „Zobrazení a funkce dynamické správy vracejí data o stavu serveru, která lze použít ke sledování stavu instance serveru, diagnostice problémů a vyladění výkonu.“
Ve skutečnosti v roce 2005 SQL Server „nemá sadu zobrazení spojených s prováděním dotazů v aktuálním okamžiku (existují však i zobrazení pro prohlížení„ historie “): tady jsou. A jejich počet se stále zvyšuje od verze na verzi!
Zkušení administrátoři mají jistě připravenu spoustu skriptů, které získají informace o aktuálním stavu serveru, ale co když s DMV zatím nemáte žádné zkušenosti, ale již máte 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á právě na tyto 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ěnovaných sp_WhoIsActive, která se skládá až z 30 (třiceti!) Kusů, můžete si ji přečíst, ale pokusím se vás zaujmout čtením tohoto materiálu :).
Budeme tedy předpokládat, že jste si stáhli a spustili tento skript na jednom z testovacích serverů (na jakékoli verzi od roku 2005 do Denali). Adam radí ukládat do hlavní systémové databáze, aby ji bylo možné 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 v plném rozsahu - DB .schema.sp_whoIsActive.
Zkusme to tedy. Snímek obrazovky ukazuje výsledek jeho provedení při vytváření stejné sestavy:
Výsledek dotazu exec sp_whoIsActive se bohužel nevejde na jednu obrazovku, takže zde je textový popis výstupu uložené procedury nazvaný bez parametrů.
- - u aktivního požadavku ukazuje čas provedení, u relace „spící“ - čas „spánku“;
- - vlastně, spid;
- - zobrazuje text právě prováděného požadavku nebo text posledního spuštěného požadavku, pokud relace spí;
- - dobře, dostanete nápad;
- je velmi zajímavý sloupek. Výstup je ve formátu (Ax: Bms / Cms / Dms) E. A je počet čekajících úkolů na zdroji E. B / C / D je čekací doba v milisekundách. Pokud na uvolnění zdroje čeká pouze jedna relace (jako na snímku obrazovky), zobrazí se její časový limit, pokud 2 relace - jejich časové limity ve formátu B / C. Pokud se očekávají 3 nebo více, uvidíme minimální, průměrnou a maximální čekací dobu 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 pro „celý život“ této relace;
- - u aktivního požadavku je to počet zápisů do TempDB během provádění požadavku; 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 TempDB přidělených pro tento požadavek; pro spící relaci - celkový počet stránek TempDB přidělených po celou dobu trvání relace;
- - pokud nás najednou někdo zablokuje, zobrazí se spid (session_id) toho, kdo nás zablokoval;
- - pro aktivní požadavek - počet logických čtení provedených při provádění tohoto požadavku; pro spící relaci - počet přečtených stránek za celou dobu trvání této relace;
- - všechny stejné, ale o záznamu;
- - u aktivního požadavku 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 přečtení za celou dobu trvání relace;
- - pro aktivní požadavek - počet stránek 8 kB použitých při provádění tohoto požadavku; pro spící relaci - kolik stránek celkové paměti mu bylo přiděleno během celého jeho života;
- - stav relace - běh, spánek atd .;
- - ukazuje počet transakcí otevřených touto relací;
- - pokud je to možné, ukazuje proces provádění operace (například BACKUP, RESTORE), nikdy nezobrazí procento provedeného SELECT.
Zbytek sloupců v standardní výstup sp_WhoIsActives jsou málo zajímavé a nebudu je popisovat - jejich účel, myslím, je každému jasný (název_hostitele, název_databáze, název_programu, počáteční_čas, přihlašovací_čas, žádací_id, sbírkový_čas).
A co? Je to všechno?
Ne, to není vše. 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 nazvat a co z toho vzejde.
- @help je strašně užitečná volba. Když zavoláme sp_whoIsActive @help = 1, získáme na obrazovce informace o VŠECH parametrech a výstupních sloupcích. Pokud tedy něco zůstane nejasné, můžete vždy vidět „pomoc“
- @filter_type a @filter - umožňují filtrovat výsledek provádění. @filter_type může být „relace“, „program“, „databáze“, „přihlášení“ a „hostitel“. V parametru @filter označujeme, o který objekt vybraného typu máme zájem. Chceme například vidět všechny relace spuštěné v hlavní databázi, proto nazýváme exec sp_whoIsActive @filter_type = "databáze", @filter = "hlavní". Parametr @filter může používat "%";
- @not_filter_type a @not_filter nám umožňují filtrovat naopak. Tj. 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 = „databáze“, @not_filter = „hlavní“. No, nebo chceme vidět, co dělají všichni uživatelé kromě uživatele sa ... Může existovat mnoho aplikací. Parametr @not_filter může používat "%";
- @show_system_spids = 1 - zobrazí informace o relacích systému;
- @get_full_inner_text = 1 - pole sql_text bude obsahovat nejen text aktuálního požadavku (příkazu) v balíčku (dávce), ale celý text dávky;
- @get_plans - přidá na výstup sloupec s plány provádění dotazu;
- @get_transaction_info = 1 - přidá na výstup počet a objem položek v protokolech transakcí a také čas zahájení poslední transakce;
- @get_locks = 1 - přidá na výstup informace o všech zámcích uložených během provádění požadavku;
- @find_block_leaders = 1 - bude sledovat blokující řetězec a zobrazí celkový počet relací čekajících na odblokování bloku aktuální relací;
- @output_column_list = "[%]" - co když nechcete vidět informace o tempDB ve výstupu sp_whoIsActive? Pomocí tohoto parametru můžete ovládat, co zobrazuje;
- @destination_table = "název_tabulky" - pokusí se vložit výsledek spuštění a zapsat do tabulky, ale nezkontroluje, zda tato tabulka existuje a zda je do ní vloženo dostatečné množství práv.
Nyní je to
V důsledku toho máme další extrémně pohodlný a flexibilní nástroj pro sledování aktuální aktivity na serveru SQL Server. Pro jeho normální provoz stačí oprávnění ZOBRAZIT SERVEROVÝ STAV a práva na přístup k dmv.
Také stojí za to přidat v případě, že je možné se připojit k serveru pouze pomocí