Kompatibilitetsnivåer och Cardinality Estimation Primer

Introduktion

Mellan 1998 och början av 2014 använde SQL Server en kardinalitetskalkylator (CE), men skulle introducera en ny databaskompatibilitetsnivå med varje ny större version av SQL Server (med undantag för SQL Server 2008 R2). De inbyggda kompatibilitetsnivåerna för SQL Server visas efter huvudversionen av SQL Server i Tabell 1:

Tabell 1:SQL Server-versioner och inbyggda kompatibilitetsnivåer

Mellan SQL Server 7.0 och SQL Server 2012 fanns det ingen koppling mellan kompatibilitetsnivån för en databas och kardinalitetskalkylatorn som frågor i den databasen skulle använda. Detta beror på att det bara fanns en kardinalitetsuppskattare, som fick en stor uppdatering 1998. Kompatibilitetsnivån för en databas användes endast för bakåtfunktionell kompatibilitet och för att aktivera/avaktivera några nya funktioner i varje ny version av SQL Server (se denna Stack Exchange-svar för exempel på hur beteendet förändrades mellan 80 och 90, förmodligen den mest störande förändringen). Till skillnad från filversionen av en SQL Server-databas kan du ändra kompatibilitetsnivån för en databas när som helst, till vilken kompatibilitetsnivå som helst, med ett enkelt ALTER DATABASE-kommando.

Som standard, om du skapade en ny databas i SQL Server 2012, skulle kompatibilitetsnivån vara inställd på 110, men du kan ändra den till en tidigare nivå om du så önskar. Om du återställt en databassäkerhetskopiering från en SQL Server 2008-instans till en SQL Server 2012-instans skulle den uppgradera filversionen av databasen, men skulle lämna kompatibilitetsnivån där den hade varit på SQL Server 2008-instansen (om det inte var 80, vilket skulle uppgraderas till 90, den lägsta versionen som stöds av SQL Server 2012). Förutom att känna till den grundläggande skillnaden mellan filversionen av en databas och kompatibilitetsnivån för en databas, behövde de flesta DBA:er och utvecklare inte oroa sig särskilt mycket för databaskompatibilitetsnivåer innan SQL Server 2014 släpptes. I många fall har de flesta databaser aldrig fått sina kompatibilitetsnivåer ändrade efter en migrering till en ny version av SQL Server. Detta orsakade vanligtvis inga problem om du inte faktiskt behövde en ny funktion eller beteende som ändrades i den senaste databaskompatibilitetsnivån.

SQL Server 2014 Ändringar

Detta gamla tillstånd förändrades radikalt i och med lanseringen av SQL Server 2014. SQL Server 2014 introducerade en "ny" kardinalitetskalkylator som var aktiverad som standard när en databas var på 120-kompatibilitetsnivå. I det klassiska vitboken, "Optimera dina frågeplaner med SQL Server 2014 Cardinality Estimator", förklarar Joe Sack bakgrunden och beteendet för denna förändring redan i april 2014. I många fall gick de flesta av dina frågor snabbare när du använde den nya kardinaliteten estimator, men det var ganska vanligt att stöta på några frågor som hade stora prestandaregressioner med den nya kardinalitetskalkylatorn. Om det hände hade SQL Server 2014 inte så många alternativ för att lindra prestandaproblemen som orsakades av den nya CE:n. Joe's whitepaper täcker dessa alternativ i detalj, men i huvudsak var du begränsad till spårningsflaggor på instansnivå eller frågetips på frågenivå för att kontrollera vilken kardinalitetskalkylator som användes av frågeoptimeraren, såvida du inte ville återgå till kompatibilitetsnivå 110 eller lägre .

SQL Server 2016 Ändringar

SQL Server 2016 introducerade databasomfångade konfigurationsalternativ, som ger dig möjlighet att kontrollera vissa beteenden som tidigare konfigurerades på instansnivå, med hjälp av kommandot ALTER DATABASE SCOPED CONFIGURATION. I SQL Server 2016 inkluderade dessa alternativ MAXDOP, LEGACY_CARDINALITY ESTIMATION, PARAMETER_SNIFFING och QUERY_OPTIMIZER_HOTFIXES. Det fanns också ett CLEAR PROCEDURE_CACHE-alternativ som låter dig rensa hela plancachen för en enda databas.

Mest relevanta i detta sammanhang är LEGACY_CARDINALITY ESTIMATION och QUERY_OPTIMIZER_HOTFIXES databasomfattade konfigurationsalternativ. LEGACY_CARDINALITY ESTIMATION aktiverar äldre CE oavsett inställningen av databaskompatibilitetsnivå. Det motsvarar spårningsflaggan 9481, men det påverkar bara databasen i fråga, inte hela instansen. Det låter dig ställa in databaskompatibilitetsnivån till 130 för att få ett antal funktions- och prestandafördelar, men fortfarande använda den äldre CE-databasen i hela databasen (såvida den inte åsidosätts av en frågetips på frågenivå).

Alternativet QUERY_OPTIMIZER_HOTFIXES motsvarar spårningsflagga 4199 på databasnivå. SQL Server 2016 kommer att aktivera alla snabbkorrigeringar för frågeoptimeraren före SQL Server 2016 RTM när du använder databaskompatibilitetsnivån 130 (utan att aktivera spårningsflagga 4199). Om du aktiverar TF 4199 eller aktiverar QUERY_OPTIMIZER_HOTFIXES får du också alla snabbkorrigeringar för frågeoptimeraren som släpptes efter SQL Server 2016 RTM.

SQL Server 2016 SP1 introducerade också USE HINT-frågetipsen som är lättare att använda, förstå och komma ihåg än de äldre QUERYTRACEON-frågetipsen. Detta ger dig ännu mer finkornig kontroll över optimerarens beteende som är relaterat till databaskompatibilitetsnivån och versionen av kardinalitetskalkylatorn som används. Du kan fråga sys.dm_exec_valid_use_hints för att få en lista över giltiga USE HINT-namn för den exakta versionen av SQL Server som du kör.

SQL Server 2017 Ändringar

Den nya adaptiva frågebehandlingsfunktionen lades till i SQL Server 2017 och är aktiverad som standard när du använder databaskompatibilitetsnivå 140.

Microsoft försöker gå bort från den gamla terminologin "Nya CE" och "Gamla CE", eftersom det faktiskt finns ändringar och korrigeringar för frågeoptimering i varje ny större version av SQL Server. På grund av detta finns det inget enskilt "Nytt CE" längre. Istället vill Microsoft hänvisa till CE70 (standard CE för SQL Server 7.0 till SQL Server 2012), CE120 för SQL Server 2014, CE130 för SQL Server 2016, CE140 för SQL Server 2017 och CE150 för SQL Server 2019. Börjar med SQL Server 2019. 2017 CU10, kan du använda USE HINT-funktionen för att kontrollera detta med frågetips. Till exempel:

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

… skulle vara ett giltigt frågetips för att tvinga fram CE130-kardinalitetskalkylatorn för en viss fråga.

SQL Server 2019 Ändringar

SQL Server 2019 lägger till ännu fler prestandaförbättringar och beteendeförändringar som är aktiverade som standard när en databas använder kompatibilitetsläge 150. Ett utmärkt exempel är skalär UDF-inlining. Ett annat exempel är den intelligenta frågebehandlingsfunktionen, som är en superuppsättning av den adaptiva frågebehandlingen i SQL Server 2017.

Det finns fem nya ANVÄND TIPS-alternativ, inklusive sätt att inaktivera batch-läge eller inaktivera adaptiv minnesåterkoppling, som visas i Tabell 2:

Tabell 2:Nya alternativ för ANVÄNDNINGSTIPS

Och det finns också sexton nya databasomfattade konfigurationsalternativ (från och med CTP 2.2) som ger dig kontroll på databasnivå över fler objekt som också påverkas av spårningsflaggor eller databaskompatibilitetsnivå. Det ger dig mer finkornig kontroll över ändringar på högre nivåer som är aktiverade som standard med databaskompatibilitetsnivå 150. Dessa listas i Tabell 3:

Tabell 3 :Nya konfigurationsalternativ för databasomfattning

Slutsats

Att migrera till en modern version av SQL Server (vilket betyder SQL Server 2016 eller nyare) är betydligt mer komplicerat än det var med äldre versioner av SQL Server. På grund av förändringarna som är förknippade med de olika databaskompatibilitetsnivåerna och olika versioner av kardinalitetsuppskattning är det faktiskt mycket viktigt att tänka, planera och faktiskt testa vilken databaskompatibilitetsnivå du vill använda på den nya versionen av SQL Server som du migrerar dina befintliga databaser till.

Microsofts rekommenderade uppgraderingsprocess är att uppgradera till den senaste SQL Server-versionen, men behålla källdatabasens kompatibilitetsnivå. Aktivera sedan Query Store på varje databas och samla in baslinjedata om arbetsbelastningen. Därefter ställer du in databaskompatibilitetsnivån till den senaste versionen och använder sedan Query Store för att fixa prestandaregressioner genom att tvinga fram den senast kända bra planen.

Du vill verkligen undvika en slumpartad "blind" migration där du är lyckligt omedveten om hur detta fungerar och hur din arbetsbelastning kommer att reagera på dessa förändringar. Att ändra databaskompatibilitetsnivån till en lämplig version och använda lämpliga konfigurationsalternativ för databas, tillsammans med lämpliga frågetips där det är absolut nödvändigt, är extremt viktigt med moderna versioner av SQL Server.