Mnoho let jsem učil a psal o běžných chybách SQL Serveru. Před lety jsem o tom také napsal blog, ale jak čas šel, vedení se trochu změnilo. Tento článek rozšíří můj předchozí článek a poukáže na to, jak se tyto vztahují na SQL Server, Azure SQL Database a Azure SQL Managed Instance.
Po mnoho let jsem zjistil, že uživatelé dělají stejné chyby. Nazývám je chybami, ale ve většině případů jde spíše o to, že se věci nedělají správně, protože lidé, kteří řídí prostředí, nic lepšího neznají. Zde jsou některé z důležitějších položek, o kterých by měl vědět každý, kdo instaluje a podporuje SQL Server:
- Zálohy
- DBCC CHECKDB
- Nastavení paměti
- Statistiky
- Údržba indexu
- MAXDOP a prahová hodnota nákladů pro paralelismus
- Upozornění SQL Server Agent
Zálohy
Při pohledu na nový systém vždy nejprve zkontroluji zálohy. Mít správné zálohy pro splnění cílů obnovy je zásadní. Ztráta dat může být pro organizaci škodlivá. Při prohlížení záloh zkontroluji model obnovy a aktuální historii záloh pro každou databázi. Obvykle najdu kombinaci následujícího:
- Žádná záloha – žádný záznam o zálohování databáze
- Chybějící zálohy – žádné zálohy protokolů pro databázi využívající model úplné obnovy
- Žádné poslední zálohy – poslední záloha byla stará týdny/měsíce/roky
Špatně nakonfigurované zálohy jsou pro organizaci škodlivé, když nastane situace obnovy. Práce se zákazníky a nutnost sdělovat jim, že přišli o data, není nikdy zábavné ani snadné. Správné zálohy splňující smlouvy SLA by měly být hlavní prioritou každé organizace, kromě toho, že jsou kopie těchto záloh uloženy v sekundárním umístění mimo pracoviště.
Tato situace platí pro místní SQL Server a IaaS. Azure SQL Database a Azure Managed Instance mají spravované zálohy.
DBCC CHECKDB
Bohužel dochází k poškození databáze. Bez pravidelné kontroly poškození se mohou zákazníci ocitnout na špatném místě, protože nebudou mít zálohy, aby je mohli obnovit, když poškození postihne fyzická data. Chcete-li zkontrolovat poškození, měl by být DBCC CHECKDB pravidelně spouštěn proti každé databázi. Zjistil jsem, že je velmi podobné zálohám:
- Nebyly provedeny žádné DBCC CHECKDB
- DBCC CHECKDB se provádějí pouze ve vybraných databázích
- DBCC CHECKDB byly naposledy provedeny před měsíci nebo lety
Nejhorším případem je selhání naplánované úlohy hlášení DBCC CHECKDBs
Není nikdy příjemné najít korupci nebo mít zákazníka oslovit problém s korupcí, když korupce je hromada nebo seskupený index a před korupcí neexistují žádné zálohy. V těchto případech je poškození skutečnými daty a zahájení obnovy z doby před poškozením je ve většině případů jedinou možností. V případech, kdy je poškození indexem bez klastrů, opravou je opětovné sestavení indexu.
V několika situacích jsem musel pracovat se zákazníky, kteří mají ošklivou korupci bez řádných záloh, kdy jsem mohl skriptovat databázi a ručně zkopírovat všechna použitelná data do nově vytvořené databáze. Těmto nákladným situacím lze snadno předejít spuštěním DBCC CHECKDB a správným uchováním záloh.
Zákazníkům doporučuji, aby spouštěli místní DBCC CHECKDB, IaaS, Azure SQL Database a Azure SQL Managed Instance. Azure odvádí skvělou práci při kontrole fyzického poškození; nicméně mám pocit, že spotřebitelé musí kontrolovat logickou korupci.
Nastavení paměti
Výchozí instalace Microsoft SQL Server má minimální hodnotu paměti nastavenou na 0 a maximální hodnotu paměti serveru nastavenou na 2147483647 MB, což jsou 2 petabajty. Před verzí SQL Server 2012 se maximální hodnota paměti serveru vztahovala pouze na fond vyrovnávacích pamětí, takže zákazníci museli omezit množství paměti, které by fond vyrovnávacích pamětí mohl použít k úspoře paměti pro operační systém a další procesy. SQL Server 2012 zavedl přepis správce paměti tak, aby se maximální hodnota paměti serveru vztahovala na všechna přidělení paměti serveru SQL Server.
Je velmi vhodné nastavit maximální hodnotu pro vaši instanci SQL Server. Jonathan Kehayias napsal blogový příspěvek Kolik paměti skutečně potřebuje můj SQL Server, se vzorcem, který pomáhá stanovit základní linii pro maximální hodnotu paměti. V případě sdíleného SQL Serveru doporučuji svým klientům nastavit minimální hodnotu na 30 % paměti na serveru.
V situacích s více instancemi nebo kde se server používá pro SQL Server, SSIS, SSAS nebo SSRS, musíte vyhodnotit, kolik paměti tyto ostatní systémy potřebují, a snížit maximální hodnotu paměti serveru, aby byla zajištěna dostatečná paměť pro OS a další služby.
Tento problém je platný pro místní, IaaS a částečně pro Azure SQL Managed Instance. Spravovaná instance nastavuje maximální hodnotu paměti serveru na základě nasazené vrstvy, ale když jsem testoval změnu velikosti prostředí, maximální hodnota paměti se dynamicky nezměnila. V takovém případě byste museli ručně aktualizovat hodnotu. Tento problém se netýká Azure SQL Database.
Statistiky
Optimalizátor dotazů používá statistiky k vytváření plánů provádění. To znamená, že SQL Server potřebuje, aby byly statistiky aktuální, aby měl optimalizátor dotazů větší šanci vytvořit dobrý plán provádění. Ve výchozím nastavení se statistiky aktualizují po úpravě 20 % + 500 řádků dat. To může na větších stolech trvat dlouho. Počínaje úrovní kompatibility 130 byla prahová hodnota pro aktualizace statistik pro velké tabulky snížena. Pro SQL Server 2008R – 2014 můžete tento práh snížit pomocí příznaku trasování 2371.
Pravidelně zjišťuji, že zákazníci ručně neaktualizují statistiky, a dokonce i při nižším prahu jsem zjistil, že ruční aktualizace dělá prostředí stabilnější.
Zákazníkům doporučuji, aby k aktualizaci statistik používali skript třetí strany. Ola Hallengren zveřejnil široce používané řešení údržby pro SQL Server. Součástí tohoto procesu je jeho procedura Optimalizace indexu, která může vyžadovat další parametry pro aktualizaci statistik.
@UpdateStatistics
ALL = update index and column statistics
INDEX = update index statistics
COLUMNS = update column statistics
NULL = Do not perform statistics maintenance (this is the default)
@OnlyModifiedStatistics
Y = Update statistics only if rows have been modified since most recent stats update
N = Update statistics regardless of whether any rows have been modified
Zjistil jsem, že zákazníci, kteří používají produkty nebo skripty třetích stran k provádění údržby indexu na základě úrovně fragmentace indexu, neberou v úvahu, že reorganizace neaktualizují statistiky jako přestavby. Mnoho z těchto aplikací třetích stran má možnosti aktualizace statistik stejně jako Olaův postup Optimalizace indexu, stačí jej zapnout.
Aktualizace statistik se vztahuje na místní, IaaS, Azure SQL Database a Azure SQL Managed Instance.
Údržba indexu
Provádění údržby indexu odstraněním fragmentace z indexů je stále důležité. Některá vyřazená dokumentace od společnosti Microsoft uváděla, že fragmentace indexu může mít negativní dopad od 13 do 460 % v závislosti na velikosti prostředí a úrovni fragmentace. Zatímco hardware, jako jsou inteligentní SAN, Solid State Disk a další vylepšení, pomohly věci urychlit, plýtvání místem v indexu se může promítnout do plýtvání místem ve fondu vyrovnávacích pamětí a také plýtváním více I/O.
K fragmentaci dochází prostřednictvím pravidelných operací, jako jsou vkládání, aktualizace a mazání. K nápravě je nutná správná údržba indexů při opětovném sestavení nebo reorganizaci vašich indexů. Znovu se obracím na Ola Hallengrena pro jeho skript Optimalizace indexu. Olaův skript poskytuje možnost specifikovat přestavbu nebo reorganizaci na základě úrovně fragmentace a minimálního počtu stránek. Mnoho nástrojů třetích stran nabízí stejnou logiku. Plány údržby databáze SQL Server před verzí SQL Server 2016 umožňovaly pouze opětovné sestavení nebo reorganizaci všech indexů. Počínaje SQL Serverem 2016 můžete nyní určit podobnou logiku na základě úrovní fragmentace. Nezapomeňte na tyto statistiky, pokud používáte chytrou logiku založenou na úrovních fragmentace.
Líbí se mi Olaův skript a nástroje třetích stran, které se přihlašují do tabulky. Poté se mohu dotázat na tabulku, abych zjistil, zda mám nějaké aktivní body indexu, kde neustále dochází k fragmentaci na vysokých úrovních, a odstraňovat problémy, proč je fragmentace tak rozšířená, a lze s tím něco dělat.
Z každého pravidla nebo osvědčeného postupu existují výjimky. Některé vzorce přístupu k datům vedou k neustálé fragmentaci. Náklady na neustálé přestavování/reorganizaci těchto stolů se nemusí vyplatit a mohou být vyloučeny z údržby. Tyto situace by měly být vyhodnoceny případ od případu.
To platí pro místní, IaaS, Azure SQL Database a Azure SQL Managed Instance.
MAXDOP
Zjistil jsem, že maximální stupeň paralelismu a prahová hodnota nákladů pro paralelismus jsou na klientských serverech obvykle ponechány na výchozích hodnotách. Pro MAXDOP je výchozí hodnota nula, což znamená, že k provedení paralelní oblasti dotazu lze použít „neomezený“ počet CPU. Technicky až 64 procesorů, pokud nepovolíte příznak trasování pro použití více.
Před deseti lety, kdy měly procesory nižší počet jader, byla tato hodnota přijatelná. Dnes, s vysokou hustotou jádra a vícesoketovými servery, není neomezený počet procesorů pro paralelismus tak dobrý. Společnost Microsoft poskytla pokyny, jaké hodnoty použít pro MAXDOP.
Pokud používáte SQL Server 2008 – SQL Server 2014, pro jeden uzel NUMA s méně než 8 logickými procesory ponechte MAXDOP na nebo pod počtem logických procesorů. Máte-li více než 8 logických procesorů, ponechte hodnotu MAXDOP na hodnotě 8. Pokud máte více uzlů NUMA s méně než 8 logickými procesory na uzel NUMA, ponechte hodnotu MAXDOP na hodnotě nebo nižší než počet logických procesorů na uzel NUMA. Větší než 8, ponechte MAXDOP na 8.
SQL Server 2016 představil soft-NUMA uzly. Pokud během spouštění služby Database Engine detekuje více než 8 fyzických jader na uzel nebo soket NUMA, automaticky se vytvoří uzly soft-NUMA. Engine se stará o umístění logických procesorů ze stejného fyzického jádra do různých soft-NUMA uzlů. Z tohoto důvodu máme mírně odlišné pokyny pro MAXDOP pro SQL Server 2016 a novější.
Pokud používáte SQL Server 2016 a vyšší, pro jeden uzel NUMA s méně než 16 logickými procesory ponechte MAXDOP na nebo pod počtem logických procesorů. Máte-li více než 16 logických procesorů, ponechte hodnotu MAXDOP na hodnotě 16. Pokud máte více uzlů NUMA s méně než 16 logickými procesory na uzel NUMA, ponechte hodnotu MAXDOP na nebo nižší než počet logických procesorů na uzel NUMA. Větší než 16, udržujte MAXDOP na polovičním počtu logických procesorů na uzel NUMA s hodnotou MAX 16.
Pokud jste většinou virtualizováni na počítačích s 8 nebo méně logickými procesory s výchozím MAXDOP, pravděpodobně jste v pořádku. Pokud máte velký fyzický hardware s výchozími nastaveními, měli byste se podívat na optimalizaci MAXDOP.
Všechna výše uvedená čísla jsou vodítka, nikoli tvrdé pravdy. Vaše pracovní vytížení se liší a měli byste zvážit, jaká hodnota je pro vaši pracovní zátěž nejoptimálnější.
Konfigurace MAXDOP se vztahuje na místní, IaaS a Azure SQL Managed Instance. Existuje však konfigurace v rozsahu databáze, kterou lze použít pro každou databázi počínaje SQL Serverem 2016, a to platí pro Azure SQL Database.
Práh nákladů pro paralelismus
Prahová hodnota nákladů pro paralelismus má výchozí hodnotu 5. Historie tohoto čísla sahá až do počátků SQL Serveru a pracovní stanice, na které bylo prováděno testování zátěže. S moderním hardwarem je odhad nákladů 5 zastaralý. Testování ukázalo, že zvýšením čísla z 5 na vyšší hodnotu zabráníte tomu, aby dotazy s kratší dobou běhu neměly paralelní plán. Po prozkoumání mezipaměti plánu doporučuji zvýšit tuto hodnotu na vyšší číslo. V mnoha případech začnu s hodnotou 25 a pak sleduji dále a v případě potřeby upravuji. Pro více informací o ladění prahu nákladů pro paralelismus napsal Jonathan Kehayias:Ladění ‚prahů nákladů pro paralelismus‘ z mezipaměti plánu.
To platí pro místní, IaaS a spravovanou instanci Azure SQL.
Výstrahy SQL Server Agent
Výstrahy SQL Agent by měli využívat všichni, pokud nemají aplikaci třetí strany, která monitoruje stejné chybové stavy. Konfigurace výstrah je snadná a bezplatná a pokud je nakonfigurujete, získáte důležité informace, když budou mít vaše servery problémy.
Napsal jsem článek s názvem SQL Server Agent Alerts, který poskytuje podrobné pokyny, jak vytvořit upozornění na chyby závažnosti 19-25 a chybu 825. Povolení těchto upozornění je snadné:povolte databázovou poštu, vytvořte poštovního operátora a poté vytvořte upozornění. To lze provést pomocí GUI nebo pomocí T-SQL. Doporučuji všem, aby tento proces naskriptovali pomocí T-SQL a učinili jej součástí vašeho standardního sestavení serveru.
To platí pro místní, IaaS a spravovanou instanci Azure SQL.
Shrnutí
Jak vidíte, existuje mnoho nastavení, která by měla být po instalaci SQL Server změněna z výchozích hodnot. Toto není úplný seznam; nicméně pokrývá mnoho závažnějších problémů a problémů ovlivňujících výkon, které jsem našel, a které jsem zařadil do své kategorie „chyby na serveru SQL“.