Jako DBA je řešení problémů s výkonem často reaktivní událostí; nastane problém, musíte reagovat. Někdy se díváte na instanci SQL Serveru, kterou dobře znáte, jindy to může být vaše první setkání s prostředím. K tomu dochází i v poradenském světě. Při pomoci dlouhodobému zákazníkovi už mám detaily o prostředí zaevidované. Když však dostaneme e-mail od někoho, s kým jsme dosud nepracovali, a jde o nouzovou situaci, kdy chce okamžitou pomoc, nemáme žádné znalosti o prostředí a netušíme, do čeho jdeme. Poskytujeme asistenci, aniž bychom museli procházet rozsáhlým procesem shromažďování a analýzy dat, který začíná s každým novým zákazníkem.
Z tohoto důvodu mám sadu pěti položek, které okamžitě zkontroluji, když se střetnu s novým prostředím. Informace, které shromažďuji, určují podmínky pro to, jak v budoucnu přistupuji k řešení problémů, a i když jen zřídka ukazují TO konkrétní problém, pomáhá mi to vyloučit, co NE problém, který je někdy stejně důležitý.
Metody sběru dat
Uznávám, že každý má jiný přístup k řešení nového prostředí. Existuje několik bezplatných, široce dostupných skriptů, které si můžete stáhnout a spustit, aby vám poskytly „lay of the land“ pro instanci serveru SQL (napadají mě skripty DMV od Glenna Berryho). Zde není kladen důraz na jak shromažďujete data, je to co data, která shromažďujete, a to, co nejprve analyzujete .
Vlastnosti serveru
Úplně první věc, kterou chci vědět, když se podívám na instanci, je verze a vydání SQL Server. Nejrychlejší způsob, jak získat tyto informace, je provést:
SELECT @@VERSION;
Pomocí tohoto výstupu mohu zkontrolovat sestavení a určit použité aktualizace service Pack, kumulativní aktualizace a opravy hotfix a vím, jaké vydání se používá. Také bych rád věděl, zda je instance shlukovaná, takže také provádím:
SELECT SERVERPROPERTY('IsClustered'); Někdy mám tyto informace od zákazníka, ale nikdy není na škodu si je ověřit, protože verze a edice mohou ovlivnit následné kroky pro řešení problémů a doporučení. Klient nás například nedávno kontaktoval ohledně občasného problému s výkonem, který zaznamenal u SQL Server 2008. Rychlá kontrola verze odhalila, že používají SQL Server 2008 SP3 a po SP3 bylo vydáno několik kumulativních aktualizací, které řešily řadu problémy s výkonem. I když jsem před doporučením, aby použili nejnovější CU, shromáždil více informací, bylo to okamžitě varovné upozornění na to, co může být příčinou problému.
sys.configurations
Toto zobrazení katalogu pomáhá stavět na základech započatých vlastnostmi serveru a pomáhá nám pochopit, jak je instance nakonfigurována. V tomto zobrazení hledám nastavení, která byla změněna oproti výchozím, ale neměla být, a ta, která není byl upraven, ale měl by.
SELECT [name], [value], [value_in_use], [description] FROM [sys].[configurations] ORDER BY [name];
Zvažte nastavení maximální paměti serveru (MB), které omezuje množství paměti dostupné pro fond vyrovnávacích pamětí. Výchozí hodnota je 2147483647, ale měla by být změněna na hodnotu menší, než je celková paměť na serveru, aby bylo zajištěno, že bude dostatek paměti pro operační systém, další aplikace a další úlohy SQL Serveru, které vyžadují paměť, která není odebrána z fondu vyrovnávacích pamětí. . Pro návod k nastavení vhodné hodnoty pro maximální paměť serveru (MB) doporučuji Jonathanův příspěvek Kolik paměti skutečně potřebuje můj SQL Server?
Naopak nastavení zesílení priority má výchozí hodnotu nula a mělo by být vždy ponecháno. Společnost Microsoft ve skutečnosti doporučuje neměnit ji a tato možnost bude v budoucí verzi serveru SQL Server odstraněna.
sys.databases
Poté, co pochopím, jak je instance nakonfigurována, se dále podívám, co existuje na úrovni databáze.
SELECT * FROM [sys].[databases] ORDER BY [database_id];
Když zkontroluji výstup tohoto katalogového pohledu, hledám v datech anti-vzory – cokoli, co vyskočí jako neočekávané nebo atypické. Výstup je vhodný pro rychlou analýzu – mnoho nastavení uvádí hodnotu 0 nebo 1 (vypnuto nebo zapnuto) a já si v duchu poznamenám, co se liší. Očekávám, že bude povoleno automatické vytváření statistik a automatické aktualizace statistik (nastaveno na 1). Očekávám, že automatické zavírání a automatické zmenšování bude zakázáno (nastaveno na 0). Podívám se, jaké je řazení pro uživatelské databáze, konkrétně zda mají všechny stejné řazení a zda je toto řazení stejné jako tempdb. Zaznamenal jsem také možnosti zabezpečení, jako je řetězení mezi databázemi a možnost is_trustworthy, obě ve výchozím nastavení zakázány (0). Pokud zjistím, že se některé z těchto nastavení odchyluje od toho, co očekávám, poznamenám si to a pokračuji dál. V žádném okamžiku nezastavuji shromažďování nebo analýzu, abych provedl změnu, protože jednoduše shromažďuji informace tak rychle, jak mohu, abych dobře porozuměl prostředí.
Kromě kontroly nastavení u databází beru na vědomí i počet uživatelských databází. Neexistuje žádný „správný počet“ uživatelských databází pro instanci – instance může fungovat špatně s jednou databází a může fungovat skvěle se 100. Ve hře je nespočet faktorů a počet databází je prostě datový bod. stojí za zmínku.
Protokoly chyb
Přiznám se, že jsem zanedbával SQL Server ERRORLOG; bylo to jako dodatečná myšlenka, když jsem zkoumal problém se serverem SQL. Pak jsem si uvědomil chybu svých cest a od té doby to neberu jako samozřejmost. Mám tendenci procházet přes Management Studio, abych se dostal k protokolu (v rámci Management | SQL Server Logs), i když můžete použít uloženou proceduru sp_readerrorlog nebo vyhledat soubor a otevřít jej ve svém oblíbeném textovém editoru.
V ERRORLOG hledám nedávné chyby – například cokoli související s pamětí – a také se dívám, jaké příznaky trasování se používají, pokud existují. Také zkontroluji, zda je povoleno zamknout stránky v paměti, zda se vyrovnávací paměť vyplachuje (ať už záměrně, nebo ne) a zda pravidelně dochází k nějaké jiné neobvyklé činnosti. V závislosti na tom, jak naléhavý je problém, se také podívám do protokolů Windows (Událost, Aplikace a Zabezpečení), opět nehledám pouze chyby, ale také neočekávané vzory zpráv.
Statistika čekání
Poslední oblastí SQL Serveru, kterou přezkoumávám při pohledu na problém s výkonem na neznámé instanci, je statistika čekání. Každá instance SQL Server bude mít čekání – bez ohledu na to, jak dobře je kód vyladěn, bez ohledu na to, kolik hardwaru je za ním. Jako DBA chcete vědět, jaká jsou vaše typická čekání na instanci, a když se dívám na nové prostředí, okamžitě nevím, zda jsou čekání, která vidím, typická, nebo kvůli problému s výkonem. Ptám se zákazníka, zda má základní statistiky čekání, a pokud ne, ptám se, zda je mohu vymazat a nechat je začít hromadit, dokud se vyskytne problém s výkonem. Chcete-li zkontrolovat statistiky čekání, můžete použít skript v často odkazovaném příspěvku Paula Randala nebo verzi v dotazech Glenna DMV.
Jakmile zkontrolujete nashromážděné statistiky čekání, budete mít poslední část, která poskytuje „velký obrázek“ instance SQL Server a informace, které potřebujete k zahájení odstraňování problémů. Při odstraňování problémů není neobvyklé nejprve zkontrolovat statistiky čekání, ale samotné čekání nestačí k tomu, abyste určili, co je třeba dále prozkoumat, pokud také nerozumíte základní konfiguraci serveru SQL.
Další kroky
Jak jsem již uvedl dříve, obvykle neexistuje jediný údaj, který by vám řekl, kde je problém s výkonem, je to několik získaných datových bodů, které vás nasměrují správným směrem. Je na vás, jak tyto informace zachytíte, ale jakmile zkontrolujete výstup, měli byste dobře rozumět tomu, jak je nakonfigurováno prostředí SQL Server, a tyto znalosti vám v kombinaci se statistikami čekání mohou pomoci rozhodnout, co dále zkoumat. Odstraňování problémů funguje nejlépe s metodickým přístupem, takže začněte se základy a propracujte se, a až si budete myslet, že jste určili hlavní příčinu, hrabejte trochu víc a najděte jeden nebo dva další důkazy, které vaše zjištění podpoří. Jakmile budete mít tato data, můžete navrhnout doporučení, jak problém zlepšit nebo vyřešit.