Ale pojďme na to ...
Monitorovací nástroje
Monitor aktivity
Zdá se, že je to skvělá věc, dělá přesně to, co je potřeba - sleduje aktivitu. Spustím těžkou účetní zprávu a uvidím, co mi Activity Monitor ukazuje.Na obrazovkách 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í neobvyklé ... Bude to docela nepohodlné pochopit, i když je samozřejmě zřejmý pokrok. V Denali zobrazuje Activity Monitor mnohem užitečnější informace (například o tom, na který konkrétní prostředek se čeká), plus můžeme například spustit profiler pro požadovanou relaci přímo z monitoru a sledovat jej již v profileru , ale sakra, navíc načte a již načtený server. Kromě toho již existuje problém s brzdami a neuvidíme ty požadavky, které již začaly běžet v době spuštění profilovače.
A já chci vidět přesně tohle - kdo dělá co právě teď.
sp_who a sp_who2
Screenshot ukazuje výsledek provádění sp_who (nahoře) a sp_who2 (níže), provedeného během konstrukce stejné nešťastné zprávy:
To jo. Velmi informativní. Při pohledu na sp_who vidíme jen to, že se něco provádí. Samozřejmě je to provedeno - hledáme to a vidíme, že se provádí nějaký SELECT. Nebo pár SELECT s. Skvělé.
sp_who2 již zobrazuje více informací. Nyní můžeme vidět, kolik času procesor strávil relací (a očividně sečíst 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).
Sledování aktivity, jak vidíme, poskytuje více informací.
DMV
Počínaje serverem SQL Server 2005 máme nová příležitost přijímat informace o stavu serveru - Dynamic Management Views. MSDN říká: „Dynamické pohledy a funkce pro správu 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 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 “): tady jsou. A jejich počet se stále zvyšuje z verze na verzi!
Zkušení administrátoři jistě mají spoustu skriptů připravených získat informace o aktuálním stavu serveru, ale co když ještě nemáte zkušenosti s DMV, ale už 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á na tyto velmi DMV a je zatraceně snadno použitelná. Stažení nejnovější verze sp_WhoIsActive je možný. Sám Adam má řadu článků věnovaných sp_WhoIsActive, které se skládají až z 30 (třiceti!) Kusů, můžete si je přečíst, ale pokusím se vás při čtení tohoto materiálu zaujmout :).Předpokládáme tedy, že jste tento skript stáhli a spustili na jednom z testovacích serverů (v jakékoli verzi od roku 2005 do Denali). Adam doporučuje uložit jej do hlavní systémové databáze, aby jej bylo možné volat v kontextu jakékoli databáze, ale není to nutné, stačí jej při volání v kontextu jiné databáze zadat celé jméno - DB.schema.sp_whoIsActive.
Zkusme to. Snímek obrazovky ukazuje výsledek jeho provedení při vytváření stejné zprávy:
Výsledek dotazu exec sp_whoIsActive se bohužel nevejde na jednu obrazovku, takže zde je textový popis výstupu uložené procedury nazývané bez parametrů.
- - u aktivního požadavku zobrazuje čas provedení, u „spánkové“ relace - čas „spánku“;
- - vlastně spid;
- - zobrazuje text právě prováděného požadavku nebo text posledního provedeného požadavku, pokud relace spí;
- - no, máš nápad;
- je velmi zajímavý sloupec. Je vydáván ve formátu (Ax: Bms / Cms / Dms) E. A je počet nevyřízený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 TENTO zdroj ve formátu B / C / D;
- - pro aktivní požadavek - celková doba CPU strávená tímto požadavkem, pro spací relaci - celková doba CPU pro „celou dobu životnosti“ této relace;
- - u aktivního požadavku je to počet zápisů do TempDB během doby provedení dotazu; pro spící relaci - celkový počet záznamů v TempDB po celou dobu trvání relace;
- - pro aktivní požadavek - počet stránek TempDB přidělených tomuto požadavku; pro spací relaci - celkový počet stránek TempDB přidělených na celou dobu trvání relace;
- - pokud nás někdo náhle 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ánkovou relaci - počet stránek přečtených po celou dobu životnosti této relace;
- - všechny stejné, ale o nahrávání;
- - 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 čtení za celou dobu trvání relace;
- - pro aktivní požadavek - počet 8K stránek použitých při provádění tohoto požadavku; pro spící relaci - kolik stránek paměti 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, je-li to možné, proces provádění operace (například ZÁLOHOVÁNÍ, OBNOVENÍ), nikdy neukáže procento provedeného VÝBĚRU.
A co? Je to všechno?
Ne, to není vše. Budu také hovořit o tom, jaké (z mého pohledu nejzajímavější a nejužitečnější) parametry můžete nazvat sp_WhoIsActive a co z toho vzejde.- @help je hrozný užitečný parametr... Když zavoláme sp_whoIsActive @help \u003d 1, dostaneme 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 „session“, „program“, „databáze“, „přihlášení“ a „hostitel“. V parametru označíme, o jaký druh objektu vybraného typu máme zájem. Například chceme vidět všechny relace spuštěné v hlavní databázi, proto voláme exec sp_whoIsActive @filter_type \u003d "databáze", \u003d "hlavní". Parametr může používat "%";
- @not_filter_type a @not_filter - dovolte nám filtrovat „obráceně“. Například chceme vidět vše kromě těch relací, které mají v poli „databáze“ „master“, proto provedeme exec sp_WhoIsActive @not_filter_type \u003d "database", @not_filter \u003d "master". 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 \u003d 1 - zobrazí informace o relacích systému;
- @get_full_inner_text \u003d 1 - pole sql_text nebude obsahovat pouze text aktuálního požadavku (příkazu) v balíčku (dávce), ale celý text dávky;
- @get_plans - do výstupu přidá sloupec s plány provedení dotazu;
- @get_transaction_info \u003d 1 - přidá na výstup počet a objem záznamů v protokolech transakcí, stejně jako čas zahájení poslední transakce;
- @get_locks \u003d 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 \u003d 1 - bude sledovat blokovací řetězec a zobrazí celkový počet relací čekajících na uvolnění bloku aktuální relací;
- @output_column_list \u003d "[%]" - co když nechcete vidět informace o tempDB ve výstupu sp_whoIsActive? Pomocí tohoto parametru můžete ovládat, co se zobrazí;
- @destination_table \u003d "název_tabulky" - pokusí se vložit výsledek spuštění a zapsat do tabulky, ale nebude kontrolovat, zda tato tabulka existuje a zda má dostatečná práva k vložení do ní.
A to je vše
Ve výsledku máme další extrémně pohodlný a flexibilní nástroj pro sledování aktuální aktivity na serveru SQL Server. Pro normální provoz stačí oprávnění VIEW SERVER STATE a práva na přístup k dmv.Také stojí za přidání, v případě, že je možné se k serveru připojit pouze pomocí
to software od Sybase, pracuje ve spojení se serverem SQL Server a vydává grafická forma různé informace o výkonu serveru. Tyto informace jsou nesmírně užitečné při analýze důvodů pro 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 pracovat 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í, se však hlásí pouze při monitorování systému SQL Server System 10 a systému 11. Přirozeně se pojmenované vyrovnávací paměti vyrovnávací paměti hlásí pouze při sledování výkonu Systém serveru SQL 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.
skládá se 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 provedenou příkazem dbcc memusage, protože tento příkaz výrazně zpomaluje server. Chcete-li to provést, musíte při spuštění serveru sqlmon (klientský modul) zadat parametr - nomem.
Výchozí konfigurace umožňuje připojení až pěti klientských modulů k jednomu modulu serveru současně. 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 podporovat 20 oken v příkazovém souboru pro spuštění modulu serveru, 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říkazu buildmaster a některých jiné akce. Tyto kroky 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 souběžných klientů najdete v příručce Server Supplement.)
má některé nevýhody. Například sloupcový graf zobrazující počet provedených I / O operací a další charakteristiky provozu serverových zařízení je schopen vykazovat data současně 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 informace zahrnuty do diagramu, ani přepínat mezi různými sadami zařízení.
Textová tabulka, která se zobrazí na obrazovce, spolu s diagramem obsahuje seznam všech serverových zařízení, ale zahrnuje pouze celkový počet I / O operací 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í fragmenty databáze 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 zobrazit data po dobu 60 po sobě jdoucích intervalů měření výkonu. 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.
Obrazy oken programu lze samozřejmě odeslat na tiskárnu, ale pak musíte uložit sady souborů nebo kopii výtisků, abyste mohli posoudit budoucí výkon serveru. V praxi musí správce serveru často znovu zobrazit data z různých období obchodního cyklu společnosti a korelovat informace za podobná období po sobě jdoucích obchodní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í sady testovacích transakcí.
Lze jej použít v přítomnosti i v nepřítomnosti na serveru. 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
Obsahuje seznam oken podporovaných programem. Pokud parametr - nomem nebyl zadán při spuštění klientského modulu sglmon, zobrazí toto okno také výsečový graf využití paměti serveru.
Vyrovnávací paměti mezipaměti
Toto okno zobrazuje grafy charakterizující fungování vyrovnávacích pamětí procedury a datové mezipaměti. Monitorováním počtu fyzických a logických I / O operací v datové mezipaměti může uživatel určit, kolik datových stránek server provede pomocí stránek, které jsou již ve vyrovnávací paměti. Tyto statistiky z datové vyrovnávací paměti 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 daty a mezipamětí procedur.
Mezipaměť dat Buffer, 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 (zařízení I / O)
Zde najdete grafy a souhrnné tabulky pro aktuální a celkový počet přístupů na disk. Pomáhají optimalizovat distribuci zátěže I / O mezi dostupnými zařízeními serveru. 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, který diskový řadič každý těchto zařízení je připojeno.
Networking, SQL Server System 10 and 11 only (Network Activity)
Okno říká statistické informace o výstupu síťového vstupu - velikosti paketů, objemy provozu atd.
Zámek objektů, pouze systém SQL Server 10 a 11 (stav zámku objektu)
Zobrazuje informace o zámcích při 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.
Pouze objektová stránka I / O, SQL Server System 10 a 11 (objektová stránka I / O)
Okno obsahuje informace o rychlosti vstupu a výstupu stránky jedné z datových tabulek serveru. Při uvádění nejčastěji používaných tabulek serveru si všimněte efektivity. Sp_sysmon tyto informace nezobrazuje.
Shrnutí výkonu
Tady je přehled výkonu SQL Serveru - využití CPU, transakce zpracované za sekundu, síťový provoz, I / O disku a využití zámku.
Trend výkonu
Okno zobrazuje průběžné průběžné grafy ukazatelů výkonu serveru zobrazených v okně Souhrn výkonu.
Aktivita procesu serveru (Process Activit)
Okno umožňuje vybrat jeden nebo více procesů serveru a sledovat využití procesoru a I / O svazky pro každý z procesů.
Podrobnosti procesu
Okno obsahuje podrobné informace o vybraném procesu serveru.
Seznam procesů
Okno obsahuje seznam všech aktuálně dostupných procesů serveru s uvedením jejich stavu. Velmi podobné vydání příkazu sp_who server.
Používání zámků (Aktivace procesu zámku)
V okně se zobrazují 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í transakce
V okně vidíte sloupcový graf zobrazující počet zpracovaných transakcí s distribucí podle odlišné typy transakce. Je například vidět, kolik transakcí lze provést pomocí mechanismu aktualizace na místě.
26.12.2006 Kevin Kline
Jaká je poslední otázka, kterou by se chtěla DBA zeptat? Pravděpodobně zpráva od uživatele o degradované aplikaci nebo otázka, co se stalo s databází. Musíme všechno odložit a přejít do „nouzového režimu“ a uvažovat, jak dlouho to bude. Jelikož jednou z hlavních povinností správce databáze je zajistit vysoce kvalitní fungování průmyslových databází, zbývá už jen co nejrychleji problém odstranit. Obvykle není čas zjistit příčinu poruchy.
Už žádné spěšné práce - jen systematické pozorování
Ale je to jediná věc, kterou lze udělat? Existuje schopnost proaktivně sledovat výkon, jednoduchý postup správy, který využívá základní výkon systému, srovnávací testy a nepřetržité monitorování. V tomto článku vám ukážu, jak použít proaktivní monitorování a jak vytvořit bezplatný monitorovací systém pomocí Windows Monitor systému.
Proaktivní monitorování
Proaktivní sledování výkonu je nekomplikovaný systém, který umožňuje řešit problémy dříve, než se stanou kritickými. Někdo pravděpodobně již používá monitorování výjimek, kdy se vytvářejí automatizované procesy, které si všimnou pouze odchylek od normy, ale neposkytují podrobné informace a neposkytují příležitosti k prevenci problémů. Naproti tomu proaktivní monitorování výkonu poskytuje uživateli nejrůznější informace o pracovním prostředí a aplikacích, krátkodobých i dlouhodobých. Budou odebírány čítače výkonu databáze, nastaveny referenční metriky a bude udržován aktivní režim monitorování.
Jak název napovídá, proaktivní sledování výkonu vyžaduje akci. Nastavení trvá trochu času a nějaký čas pochopíte, jak fungují databáze a aplikace. Aby bylo proaktivní sledování výkonu účinné, musíte zkontrolovat zprávy, abyste mohli použít shromážděná obrovská 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 z výsledků několika měření prováděných za stejných podmínek; jsou to měřítka pro srovnání.
Měřítko zobrazuje výkon systému na určité úrovni zátěže 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 jsou vyšší nebo nižší než obvykle (tj. když server pracuje špatně) . Stejně jako u výchozích hodnot se referenční hodnoty zachycují v kontrolovaném prostředí, klíčové hodnoty se určují podle předdefinovaných metrik. Pokud potřebujete zjistit, jak se server a aplikace chovají na několika úrovních nebo typech načítání, pak se obvykle 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 stanovených podmínek (sady podmínek definovaných pro další vyšetřování nebo varování). Například pokud 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 sledovány tyto konkrétní události.
Pojďme nyní k proaktivnímu monitorová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 mají jiné funkce, než jaké může poskytnout bezplatné integrované řešení. Ale než začnu, ukážu vám, jak začít s proaktivním sledováním pomocí nástroje System Monitor.
Krok 1: Určete základní výkonnostní parametry.
V prvním kroku zajištění proaktivního monitorovacího režimu je vytvořena sada základních parametrů provozu databázového serveru. Tento agregát označuje výkon serveru za normálních podmínek a pomáhá dokumentovat a porozumět všem důležitým procesy na pozadí, také pomáhá identifikovat situace, které „nevyžadují zásah“, aby je bylo možné v budoucnu ignorovat. Jinými slovy, správci databází mohou definovat možnosti ignorování systémových zpráv, protože jinak se generuje velké množství falešných oznámení.
K vizualizaci kvality výkonu používají nejlepší základní linie několik grafů (ideálně jeden), takže na první pohled uvidíte, jak si server vede. Když jsou určeny základní parametry, musíte provést následující. Nejprve vyberte možnost uložit údaje o výkonu do systémového protokolu nebo je zobrazit v reálném čase. Je ideální mít obě funkce: deníky vám umožňují kdykoli se vrátit ke čtení a analyzovat, jaký byl výkon, když systém nebyl přímo pozorová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ých I / O a odhadnout náklady na požadovaný prostor. Čím větší je interval, tím vyšší je pravděpodobnost, že nebudou získána sledovaná výkonnostní data. Nakonec zvolte místní nebo vzdálené monitorování. Místní monitorování, kde proces monitorování použí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 Monitoru systému, které se doporučují k určení základní úrovně. Nemohu říci, která hodnota je „správná“ v kontextu dané aplikace, protože se liší od systému k systému. Použijte průměr různých základních linií k určení typického základního výkonu a označte, že se jedná o správnou volbu pro operační systém.
Definování základních parametrů pomocí Monitoru systému
Nyní pro účely shromažďování základních parametrů nazýváme System Monitor. Otevřeme Ovládací panely, Nástroje pro správu, Výkon. Poklepejte na protokoly výkonu a výstrahy v levém podokně. lis pravé tlačítko do 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í počítadlo a klikněte na Přidat. Tyto kroky opakujte, dokud nebudou přidány všechny čítače, a poté klikněte na Zavřít.
Nejprve 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 pod Sample automaticky každých: _ sekund. Delší intervaly zabírají méně místa, ale poskytují méně podrobná data.
Vyberte tabulku Log Files a definujte umístění, kde budou data uložena. Data je možné zobrazit později pomocí zobrazení Zobrazit data souboru protokolu. Když systémový monitor shromažďuje základní údaje o výkonu, bude vypadat jako obrázek 1. Je vidět, že mnoho dat lze sbírat současným sledováním mnoha měřičů, proto byste měli pečlivě vybírat měřiče pro hlavní linku.
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 pochopit výkon vašeho serveru v několika předdefinovaných situacích.
U standardů se používá stejný monitorovací režim jako pro stanovení základních parametrů. Můžete použít 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ů srovnávání se dosáhne vývojem obvyklých vlastních scénářů, 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í. Sbírání 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 při předdefinovaných zatíženích, uvidíte, co můžete od svého systému očekávat. Data shromážděná z referenčních hodnot slouží jako základ pro rutinní sledování. Bylo například zjištěno, že server je schopen až 249 transakcí za sekundu, než začne zpomalovat. V tomto případě můžete nastavit upozornění s nízkou prioritou, když server dosáhne zatížení přibližně 200 TPS, a upozornění 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 přijmout nezbytná opatření, než si uživatelé cokoli všimnou. A žádné kritické situace. Nyní je to možné.
Krok 3: Rutinní monitorování
Snad 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 detekovat problémy s výkonem.
Můžete vytvořit nízkonákladový nástroj pro monitorování serveru SQL Server pomocí kombinace agenta serveru SQL Server a monitoru systému. Agent serveru SQL Server umožňuje určit, která událost vyvolala na monitoru chybu, určit, kdo přijímá oznámení o událostech, a automaticky odeslat oznámení, když dojde k chybové události.
Instalace agenta SQL Server může být časově náročná a složitá, takže si budete muset přečíst část Výstrahy serveru SQL Knihy online (BOL)... Agent serveru SQL Server obvykle sleduje chybové zprávy databázového serveru a nesleduje provádění.
K monitorování výkonu serveru se System Monitor používá ke sledování aktuálních čítačů (frekvenci dotazování nastavte do 15 minut).
Paměťové stránky / s
Síťové rozhraní - bajty celkem / s
Přenosy fyzického disku na disk / s
Procesor -% času procesoru
SQLServer: Přístupové metody - plné skenování / s
SQLServer: Buffer Manager-Buffer Cache Hit Ratio
SQLServer: Databáze Aplikace Databáze Transakce / s
SQLServer: Obecné statistiky - připojení uživatelů
SQLServer: Průměrná doba západky západky
SQLServer: Průměrná doba čekání na uzamčení
SQLServer: Locks-Lock Timeouts / sec
SQLServer: Locks-Number of Deadlocks / sec
SQLServer: Memory Manager-Memory Grants Pending
Nastavte hodnotu každého čítače mezi základními hodnotami a referenčními hodnotami, které byly testovány. Můžete například nastavit oznámení, když čítač dosáhne 75 procent své nejvyšší hodnoty načtení, a varovnou zprávu, když projde 90 procent.
Chcete-li provést varování, můžete použít nástroje zdarmajako jsou výstrahy a oznámení serveru SQL, sledování systému nebo nákup nástrojů Microsoft Operations Manager (MOM) nebo jiných nástrojů. 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 lze zasílat a informovat správce prostřednictvím e-mailem, pager nebo síť. Můžete nastavit automatická upozornění pro následující zdroje zpráv:
- protokol serveru SQL Server
- protokol agenta SQL
- protokol aplikací Windows, Zabezpečení a Systém
- protokol provádění úloh serveru SQL Server
Nakonec se musíte ujistit, že vaše interně vyvinuté aplikace správně zaznamenávají chyby a také reagují na chybové zprávy z jiných vyvinutých aplikací.
Proaktivní sledování výkonu serveru SQL Server znamená identifikaci základních parametrů 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í, v ideálním případě spuštění výstrahy při zjištění problému. Ať už používáte bezplatné nebo integrované nástroje, nebo si volíte řešení třetích stran, ovládání vám zajistí správný přehled o vašich aplikacích běžících na serveru SQL Server, když je potřebujete.
Tabulka 1. Objekty a čítače System Monitor 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. 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 procházejících bytů síťové rozhraní za sekundu. Když toto počítadlo klesá nebo je trendy, znamená to, že problémy se sítí mohou ovlivňovat aplikaci. |
| Přenosy na fyzický disk / s | Posouzení 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ý uživatelbudou pravděpodobně ignorovány |
| SQLServer: Přístupové metody - plné skenování / s | Neomezený počet tabulek nebo indexů za sekundu. Downgrading this counter for the better, because views often cause under-resource caching problems |
| SQLServer: Buffer Manager-Buffer Cache Hit Ratio | Procento stránek, které nevyžadovaly čtení z disku. Čím vyšší číslo, tím méně diskového I / O se provádí. V dobře vyladěném systému by tato hodnota měla být 80 nebo vyšší. |
| SQLServer: Databáze - růst logů | Kolik pro konkrétní databázi narostl 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 pár dní. |
| SQLServer: Použitá databáze Databáze Procentuální využití protokolu | 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 pult občas spadá do standardů. Sledujte, kdy se transakce začnou zařazovat do fronty, což znamená, že I / O disku může být pomalý |
| SQLServer: Průměrná doba čekání na západku | Průměrná doba pro zpoždění požadavku před vyplněním. Tato hodnota čítače může být vysoká, když server čelí sporům o prostředky, zejména paměť nebo I / O |
| SQLServer: Průměrná doba čekání na zámek, Čekání na zámek / s, Počet zablokování / s | Dočasné zámky obsahují prostředky serveru SQL. Sledujte vzestupný trend v těchto blokování souvisejících čítačů, což naznačuje možný problém s výkonem |
| SQLServer: Obecné statistiky - připojení uživatelů | Počet připojení uživatelů k databázovému serveru. Zkontrolujte jakékoli znatelné posuny v hodnotě tohoto čítače. Mohou naznačovat problémy se sítí a označte zatížení a zpomalení |
| SQLServer: Memory Manager-Memory Grants Pending | Aktuální počet procesů čekajících na přidělení paměťového prostoru. Vysoká nebo rostoucí hodnota může indikovat nedostatek paměti |
| SQLServer: Uživatelský nastavitelný dotaz (sledovací dotaz) | Specializovaný čítač, známý také jako ukazatel dotazu. Toto počítadlo je dotaz generovaný uživatelem, který udává celkovou rychlost nebo účinnost systému. Chcete-li nastavit tuto hodnotu, aplikace volá sp_user_counter1 a vrátí číselnou hodnotu. |
Počínaje rokem 2008 byl do sestavení serveru SQL Server přidán Performance Data Collector (PDC). Nová funkce 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 nainstalovány ve výchozím nastavení, se označují jako sada systému kolekce, a to:
- 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 statistika dotazů, jednotlivý text dotazu, plány dotazů a konkrétní dotazy.
- Monitorování aktivity serveru... Sbírá statistiky využití zdrojůa produktivitadata ze serveru, operační systém a SQLserveru.
Výhody:
- Snadná konfigurace. Konfigurace vyžadujejen pár kliknutí.
- Snadné sledování událostí, testování a sledování celkového stavu systému.
- Centralizované ukládání dat.
- Přizpůsobivost. Zahrnuje možnost vytvořit si vlastní systém sběru dat
Omezení:
- Kompatibilní pouze s verzí serveru SQL Server 2008.
- Systém sběru dat nezobrazuje online informace o diskovém prostoru
Přípravné fáze:
- V první fázi přípravy musí být na serveru vytvořena složka pro čtení a 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.
- Před zahájením monitorování musí být vytvořena databáze monitorovacího systému. Tato základna data jsou v podstatě běžná databáze SQL a obsahují všechna data získaná monitorovacím systémem.
- Předem se postarejte o velikost místa na disku. Očekávaný růst databáze je přibližně 250 - 350 MB denně.
- Ve výchozím nastavení jsou data mazá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ý prostor 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, každou hodinu jsou data zapisována do databáze a ukládána po dobu 90 dnů. Tyto intervaly lze upravit.
- Sada kolekce Statistiky dotazů shromažďuje statistiky dotazů i jednotlivé texty dotazů, plány dotazů a konkrétní dotazy. Tato data v kombinaci se statistikami systému a akcemi umožňují u jednotlivých dotazů rozbalení pod úroveň relace. Naplánovaná přenosová frekvence - každých 15 minut, ukládání dat na 14 dní. Tyto intervaly lze upravit.
- Sada kolekce aktivity serveru poskytuje obecná informace Činnost serveru SQL Server, využití prostředků serveru SQL Server a konflikt mezi prostředky serveru SQL Server. Tato sada kolekce také poskytuje zapouzdřený pohled na použití všech systémové prostředkyk určení, jak problémy s výkonem souvisejí s aktivitami mimo rámec serveru SQL Server. Statistiky aktivity serveru se zaznamenávají každých 60 sekund, u aktivních relací a požadavků je tento interval 10 sekund
- MSDB se používá k ukládání informací o protokolování konfigurace, běhového prostředí, auditu a shromažďování informací. Balíčky SSIS jsou uloženy v MSDB.
- Musí být nainstalován agent serveru SQL Server.
- Musí být spuštěna služba SQL Server Integration Service SSIS balíčky se používají ke sběru dat. SSIS balíčky také generují události během shromažďování dat, které se používají k monitorování a řešení problémů s procesem shromažďování.
- Zabezpečení sběrače dat. V průvodci „Konfigurovat Datový sklad Wizard ", musíte mapovat role pro datový kolektor a uživatelské účty. Patří mezi ně 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číst a zapsat 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 mazá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 zprávy o těchto popravách. Chcete-li zobrazit přehledy, rozbalte kartu „Správa“ -\u003e „Sběr dat“.
Snímek obrazovky níže ukazuje, jaká data o výkonu jsou uložena v místní mezipaměti před načtením dat.
Zde můžete také zobrazit 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 zdroje podle kategorie.
Můžete kliknout na libovolný požadavek a získat o něm podrobné informace.
Níže je umístěn detailní informace na vybranou žádost.
Každý správce databáze se pravděpodobně musel vypořádat s tím, že je vše pomalé nebo nefunguje vůbec. První věc, kterou je třeba zjistit, je to, co se ve skutečnosti aktuálně děje na serveru SQL Server. Zdálo by se, že ve správcově arzenálu je tolik užitečných věcí: chlapský monitor aktivity, spousta zobrazení dynamické správy (dmv), uložené procedury sp_who a sp_who2, zděděné z doby SQL Server 7 a SQL Server 2000.
Ale pojďme na to ...
Monitorovací nástroje
Monitor aktivity
Zdá se, že je to skvělá věc, dělá přesně to, co je potřeba - sleduje aktivitu. Spustím těžkou účetní zprávu a uvidím, co mi Activity Monitor ukazuje.
Na obrazovkách 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í neobvyklé ... Bude to docela nepohodlné pochopit, i když je samozřejmě zřejmý pokrok. V Denali zobrazuje Monitor aktivity mnohem užitečnější informace (například o tom, u kterého konkrétního zdroje se čeká), plus můžeme například spustit profiler pro požadovanou relaci přímo z monitoru a sledovat jej již v profilu , ale sakra, navíc načte a již načtený server. Kromě toho již existuje problém s brzdami a neuvidíme ty požadavky, které byly v době spuštění profilovače.
A já chci vidět přesně tohle - kdo dělá co právě teď.
sp_who a sp_who2
Screenshot ukazuje výsledek provádění sp_who (nahoře) a sp_who2 (níže), provedeného během výstavby stejné nešťastné zprávy: 
To jo. Velmi informativní. Při pohledu na sp_who vidíme jen to, že se něco provádí. Samozřejmě je to provedeno - hledáme to a vidíme, že se provádí nějaký SELECT. Nebo pár SELECT s. Skvělé.
sp_who2 již zobrazuje více informací. Nyní můžeme vidět, kolik času procesor strávil relací (a očividně sečíst 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).
Sledování aktivity, jak vidíme, poskytuje více informací.
DMV
Počínaje serverem SQL Server 2005 jsme dostali novou schopnost získávat informace o stavu serveru - zobrazení dynamické správy. MSDN říká: „Dynamické pohledy a funkce pro správu 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 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 “): tady jsou. A jejich počet se od verze stále zvyšuje do verze!
Zkušení administrátoři mají jistě spoustu skriptů připravených získat informace o aktuálním stavu serveru, ale co když ještě nemáte zkušenosti s DMV, ale už 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á na tyto velmi DMV a je zatraceně snadno použitelná. Můžete si stáhnout nejnovější verzi sp_WhoIsActive. Sám Adam má řadu článků věnovaných sp_WhoIsActive, které se skládají až z 30 (třiceti!) Kusů, můžete si je přečíst, ale pokusím se vás při čtení tohoto materiálu zaujmout :).
Předpokládáme tedy, že jste tento skript stáhli a spustili na jednom z testovacích serverů (v jakékoli verzi od roku 2005 do Denali). Adam doporučuje uložit jej do hlavní systémové databáze, aby jej bylo možné volat v kontextu jakékoli databáze, ale není to nutné, stačí jej při volání v kontextu jiné databáze zadat celé jméno - DB.schema.sp_whoIsActive.
Zkusme to. Snímek obrazovky ukazuje výsledek jeho provedení při vytváření stejné zprávy:
Výsledek dotazu exec sp_whoIsActive se bohužel nevejde na jednu obrazovku, takže zde je textový popis výstupu uložené procedury nazývané bez parametrů.
- - u aktivního požadavku se zobrazuje čas provedení, u „spánkové“ relace - čas „spánku“;
- - vlastně spid;
- - zobrazuje text právě prováděného požadavku nebo text posledního provedeného požadavku, pokud relace spí;
- - no, máš nápad;
- je velmi zajímavý sloupec. Je vydáván ve formátu (Ax: Bms / Cms / Dms) E. A je počet nevyřízený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 TENTO zdroj ve formátu B / C / D;
- - pro aktivní požadavek - celková doba CPU strávená tímto požadavkem, pro spací relaci - celková doba CPU pro „celou dobu životnosti“ této relace;
- - u aktivního požadavku je to počet zápisů do TempDB během doby provedení dotazu; pro spící relaci - celkový počet záznamů v TempDB po celou dobu trvání relace;
- - pro aktivní požadavek - počet stránek TempDB přidělených tomuto požadavku; pro spací relaci - celkový počet stránek TempDB přidělených na celou dobu trvání relace;
- - pokud nás někdo náhle 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ánkovou relaci - počet stránek přečtených po celou dobu životnosti této relace;
- - všechny stejné, ale o nahrávání;
- - 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 čtení za celou dobu trvání relace;
- - pro aktivní požadavek - počet 8K stránek použitých při provádění tohoto požadavku; pro spící relaci - kolik stránek paměti 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, je-li to možné, proces provádění operace (například ZÁLOHOVÁNÍ, OBNOVENÍ), nikdy neukáže procento provedeného VÝBĚRU.
Zbytek sloupců v standardní výstup sp_WhoIsActives jsou málo zajímavé a nebudu je popisovat - myslím, že jejich účel je každému jasný (host_name, database_name, program_name, start_time, login_time, request_id, collection_time).
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 volat a co z toho bude.
- @help je strašně užitečná volba. Když se volá sp_whoIsActive @help \u003d 1, získáme informace o VŠECH parametrech a výstupních sloupcích na obrazovce. 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 „session“, „program“, „databáze“, „přihlášení“ a „hostitel“. V parametru @filter označujeme, o který objekt vybraného typu máme zájem. Například chceme vidět všechny relace spuštěné v hlavní databázi, k tomu voláme exec sp_whoIsActive @filter_type \u003d "database", @filter \u003d "master". Parametr @filter může používat "%";
- @not_filter_type a @not_filter - dovolte nám filtrovat „obráceně“. Například chceme vidět vše kromě těch relací, které mají v poli „databáze“ „master“, proto provedeme exec sp_WhoIsActive @not_filter_type \u003d "database", @not_filter \u003d "master". 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 \u003d 1 - zobrazí informace o relacích systému;
- @get_full_inner_text \u003d 1 - pole sql_text nebude obsahovat pouze text aktuálního požadavku (příkazu) v balíčku (dávce), ale celý text dávky;
- @get_plans - do výstupu přidá sloupec s plány provedení dotazu;
- @get_transaction_info \u003d 1 - přidá na výstup počet a objem záznamů v protokolech transakcí, stejně jako čas zahájení poslední transakce;
- @get_locks \u003d 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 \u003d 1 - bude sledovat blokovací řetězec a zobrazí celkový počet relací čekajících na uvolnění bloku aktuální relací;
- @output_column_list \u003d "[%]" - co když nechcete vidět informace o tempDB ve výstupu sp_whoIsActive? Pomocí tohoto parametru můžete ovládat, co se zobrazí;
- @destination_table \u003d "název_tabulky" - pokusí se vložit výsledek spuštění a zapsat do tabulky, ale nebude kontrolovat, zda tato tabulka existuje a zda má dostatečná práva k vložení do ní.
A to je vše
Ve výsledku máme další extrémně pohodlný a flexibilní nástroj pro sledování aktuální aktivity na serveru SQL Server. Pro normální provoz stačí oprávnění VIEW SERVER STATE a práva na přístup k dmv.
Také stojí za přidání, v případě, že je možné se k serveru připojit pouze pomocí