Úrovně kompatibility a primer pro odhad mohutnosti

Úvod

Mezi rokem 1998 a začátkem roku 2014 používal SQL Server jeden estimátor mohutnosti (CE), ale zavedl novou úroveň kompatibility databáze s každou novou hlavní verzí SQL Server (s výjimkou SQL Server 2008 R2). Nativní úrovně kompatibility pro SQL Server jsou uvedeny podle hlavní verze SQL Serveru v tabulce 1:

Tabulka 1:Verze serveru SQL a nativní úrovně kompatibility

Mezi SQL Server 7.0 a SQL Server 2012 neexistovalo žádné spojení mezi úrovní kompatibility databáze a odhadem mohutnosti, který by dotazy v této databázi používaly. Důvodem je, že existoval pouze jeden estimátor mohutnosti, který prošel významnou aktualizací v roce 1998. Úroveň kompatibility databáze byla použita pouze pro zpětnou funkční kompatibilitu a pro povolení/zakázaní některých nových funkcí v každé nové verzi SQL Server (viz toto Odpověď Stack Exchange pro příklady, jak se chování změnilo mezi 80 a 90, což je pravděpodobně nejrušivější změna). Na rozdíl od verze souboru databáze SQL Server můžete kdykoli změnit úroveň kompatibility databáze na jakoukoli podporovanou úroveň kompatibility pomocí jednoduchého příkazu ALTER DATABASE.

Ve výchozím nastavení, pokud jste vytvořili nové databáze v SQL Server 2012 by byla úroveň kompatibility nastavena na 110, ale pokud si to přejete, můžete ji změnit na dřívější úroveň. Pokud jste obnovili záloha databáze z instance SQL Server 2008 do instance SQL Server 2012 by upgradovala verzi souboru databáze, ale ponechala by úroveň kompatibility tam, kde byla na instanci SQL Server 2008 (pokud by to nebylo 80, což by upgradujte na 90, minimální verzi podporovanou SQL Serverem 2012). Kromě znalosti zásadního rozdílu mezi verzí souboru databáze a úrovní kompatibility databáze se většina správců databází a vývojářů nemusela před vydáním SQL Server 2014 příliš starat o úrovně kompatibility databáze. V mnoha případech se u většiny databází po migraci na novou verzi SQL Server nikdy nezměnily úrovně kompatibility. To obvykle nezpůsobovalo žádné problémy, pokud jste ve skutečnosti nepotřebovali novou funkci nebo chování, které se změnilo v nejnovější úrovni kompatibility databáze.

Změny SQL Server 2014

Tento starý stav věcí se radikálně změnil s vydáním SQL Server 2014. SQL Server 2014 zavedl „nový“ estimátor mohutnosti, který byl povolen ve výchozím nastavení když byla databáze na úrovni kompatibility 120. V klasickém dokumentu „Optimalizace plánů dotazů pomocí nástroje SQL Server 2014 Cardinality Estimator“ vysvětluje Joe Sack pozadí a chování této změny v dubnu 2014. V mnoha případech běžela většina vašich dotazů rychleji při použití nové mohutnosti. estimator, ale bylo docela běžné narazit na některé dotazy, které měly velké regrese výkonu s novým estimátorem mohutnosti. Pokud by k tomu došlo, SQL Server 2014 neměl tolik možností pro zmírnění problémů s výkonem způsobených novým CE. Joeův whitepaper pokrývá tyto možnosti velmi podrobně, ale v podstatě jste byli omezeni na příznaky trasování na úrovni instance nebo tipy dotazu na úrovni dotazu, abyste mohli řídit, který estimátor mohutnosti byl použit optimalizátorem dotazů, pokud jste se nechtěli vrátit na úroveň kompatibility 110 nebo nižší. .

Změny SQL Server 2016

SQL Server 2016 zavedl možnosti konfigurace v rozsahu databáze, které vám dávají možnost ovládat některá chování, která byla dříve konfigurována na úrovni instance, pomocí příkazu ALTER DATABASE SCOPED CONFIGURATION. V SQL Server 2016 tyto možnosti zahrnovaly MAXDOP, LEGACY_CARDINALITY ESTIMATION, PARAMETER_SNIFFING a QUERY_OPTIMIZER_HOTFIXES. K dispozici byla také možnost CLEAR PROCEDURE_CACHE, která vám umožní vymazat celou mezipaměť plánu pro jednu databázi.

Nejrelevantnější v tomto kontextu jsou možnosti konfigurace v rozsahu databáze LEGACY_CARDINALITY ESTIMATION a QUERY_OPTIMIZER_HOTFIXES. LEGACY_CARDINALITY ESTIMATION umožňuje starší CE bez ohledu na nastavení úrovně kompatibility databáze. Je ekvivalentní příznaku trasování 9481, ale ovlivňuje pouze příslušnou databázi, nikoli celou instanci. Umožňuje vám nastavit úroveň kompatibility databáze na 130, abyste získali řadu funkčních a výkonnostních výhod, ale stále používali starší databázi CE v celé šíři (pokud není přepsána nápovědou k dotazu na úrovni dotazu).

Volba QUERY_OPTIMIZER_HOTFIXES je ekvivalentní příznaku trasování 4199 na úrovni databáze. SQL Server 2016 povolí všechny opravy hotfix optimalizátoru dotazů před SQL Server 2016 RTM, když používáte úroveň kompatibility databáze 130 (bez povolení příznaku trasování 4199). Pokud povolíte TF 4199 nebo povolíte QUERY_OPTIMIZER_HOTFIXES, získáte také všechny opravy hotfix optimalizátoru dotazů, které byly vydány po SQL Server 2016 RTM.

SQL Server 2016 SP1 také zavedl tipy pro dotazy USE HINT, které se snáze používají, srozumitelné a zapamatovatelné než starší tipy pro dotazy QUERYTRACEON. To vám dává ještě jemnější kontrolu nad chováním optimalizátoru, které souvisí s úrovní kompatibility databáze a verzí použitého estimátoru mohutnosti. Seznam platných názvů USE HINT pro přesné sestavení SQL Serveru, který používáte, můžete získat dotazem sys.dm_exec_valid_use_hints.

Změny SQL Server 2017

Nová funkce adaptivního zpracování dotazů byla přidána do SQL Server 2017 a je ve výchozím nastavení povolena, když používáte databázovou úroveň kompatibility 140.

Microsoft se snaží opustit starou terminologii „Nové CE“ a „Staré CE“, protože ve skutečnosti dochází ke změnám a opravám optimalizace dotazů v každé nové hlavní verzi SQL Serveru. Z tohoto důvodu již neexistuje jediné „nové CE“. Místo toho chce Microsoft odkazovat na CE70 (výchozí CE pro SQL Server 7.0 až SQL Server 2012), CE120 pro SQL Server 2014, CE130 pro SQL Server 2016, CE140 pro SQL Server 2017 a CE150 pro SQL Server 2019. Počínaje SQL Serverem 2017 CU10, můžete použít funkci USE HINT k ovládání pomocí tipů pro dotazy. Například:

/*...query...*/ OPTION (USE HINT('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_130'));

… by byl platným tipem pro dotaz, který by vynutil odhad mohutnosti CE130 pro konkrétní dotaz.

Změny SQL Server 2019

SQL Server 2019 přidává ještě další vylepšení výkonu a změny chování, které jsou standardně povoleny, když databáze používá režim kompatibility 150. Ukázkovým příkladem je skalární vkládání UDF. Dalším příkladem je funkce inteligentního zpracování dotazů, která je nadmnožinou adaptivního zpracování dotazů v SQL Server 2017.

Existuje pět nových možností USE HINT, včetně způsobů, jak deaktivovat dávkový režim nebo deaktivovat zpětnou vazbu adaptivního přidělení paměti, jak ukazuje Tabulka 2:

Tabulka 2 :Nové možnosti USE HINT

A existuje také šestnáct nových možností konfigurace v rozsahu databáze (od CTP 2.2), které vám na úrovni databáze poskytují kontrolu nad více položkami, které jsou rovněž ovlivněny příznaky trasování nebo úrovní kompatibility databáze. Poskytuje vám jemnější kontrolu nad změnami vyšší úrovně, které jsou ve výchozím nastavení povoleny s úrovní kompatibility databáze 150. Ty jsou uvedeny v tabulce 3:

Tabulka 3 :Nové možnosti konfigurace v rozsahu databáze

Závěr

Migrace na moderní verzi SQL Server (tj. SQL Server 2016 nebo novější) je podstatně složitější než u starších verzí SQL Serveru. Vzhledem ke změnám souvisejícím s různými úrovněmi kompatibility databází a různými verzemi odhadu mohutnosti je ve skutečnosti velmi důležité zamyslet se, naplánovat a skutečně otestovat, jakou úroveň kompatibility databáze chcete použít na nové verzi SQL Server, kterou chcete použít. migrují vaše stávající databáze na.

Společnost Microsoft doporučuje upgradovat na nejnovější verzi SQL Server, ale zachovat úroveň kompatibility zdrojové databáze. Poté povolte úložiště dotazů v každé databázi a shromážděte základní data o pracovní zátěži. Dále nastavíte úroveň kompatibility databáze na nejnovější verzi a poté pomocí Query Store opravíte regrese výkonu vynucením posledního známého dobrého plánu.

Opravdu se chcete vyhnout náhodné „slepé“ migraci, kdy si blaženě neuvědomujete, jak to funguje a jak na tyto změny zareaguje vaše pracovní zátěž. Změna úrovně kompatibility databáze na vhodnou verzi a použití vhodných možností konfigurace v rozsahu databáze spolu s vhodnými radami pro dotazy tam, kde je to naprosto nezbytné, je u moderních verzí SQL Serveru extrémně důležité.