Kompatibilitetsniveauer og Cardinality Estimation Primer

Introduktion

Mellem 1998 og begyndelsen af ​​2014 brugte SQL Server én kardinalitetsestimator (CE), men ville introducere et nyt databasekompatibilitetsniveau med hver ny større version af SQL Server (med undtagelse af SQL Server 2008 R2). De oprindelige kompatibilitetsniveauer for SQL Server er vist efter hovedversionen af ​​SQL Server i tabel 1:

Tabel 1:SQL Server-versioner og indbyggede kompatibilitetsniveauer

Mellem SQL Server 7.0 og SQL Server 2012 var der ingen forbindelse mellem kompatibilitetsniveauet for en database og den kardinalitetsvurdering, som forespørgsler i den database ville bruge. Dette skyldes, at der kun var den ene kardinalitetsestimator, som modtog en større opdatering i 1998. Kompatibilitetsniveauet for en database blev kun brugt til baglæns funktionel kompatibilitet og til at aktivere/deaktivere nogle nye funktioner i hver ny version af SQL Server (se denne Stack Exchange-svar for eksempler på, hvordan adfærd ændrede sig mellem 80 og 90, sandsynligvis den mest forstyrrende ændring). I modsætning til filversionen af ​​en SQL Server-database kan du til enhver tid ændre kompatibilitetsniveauet for en database til et hvilket som helst understøttet kompatibilitetsniveau med en simpel ALTER DATABASE-kommando.

Som standard, hvis du har oprettet en ny database i SQL Server 2012, ville kompatibilitetsniveauet være sat til 110, men du kan ændre det til et tidligere niveau, hvis du ønsker det. Hvis du gendannet en databasesikkerhedskopi fra en SQL Server 2008-instans til en SQL Server 2012-instans, ville den opgradere filversionen af ​​databasen, men ville forlade kompatibilitetsniveauet, hvor den havde været på SQL Server 2008-instansen (medmindre den var 80, hvilket ville blive opgraderet til 90, minimumsversionen understøttet af SQL Server 2012). Udover at kende den grundlæggende forskel mellem filversionen af ​​en database og kompatibilitetsniveauet af en database, behøvede de fleste DBA'er og udviklere ikke at bekymre sig meget om databasekompatibilitetsniveauer, før SQL Server 2014 blev frigivet. I mange tilfælde fik de fleste databaser aldrig deres kompatibilitetsniveauer ændret efter en migrering til en ny version af SQL Server. Dette forårsagede normalt ingen problemer, medmindre du faktisk havde brug for en ny funktion eller adfærd, der ændrede sig i det seneste databasekompatibilitetsniveau.

SQL Server 2014 Ændringer

Denne gamle tilstand ændrede sig radikalt med udgivelsen af ​​SQL Server 2014. SQL Server 2014 introducerede en "ny" kardinalitetsvurdering, der var aktiveret som standard når en database var på 120 kompatibilitetsniveau. I det klassiske hvidbog, "Optimering af dine forespørgselsplaner med SQL Server 2014 Cardinality Estimator", forklarer Joe Sack baggrunden og adfærden for denne ændring tilbage i april 2014. I mange tilfælde kørte de fleste af dine forespørgsler hurtigere, når du brugte den nye kardinalitet estimator, men det var ret almindeligt at støde på nogle forespørgsler, der havde store præstationsregressioner med den nye kardinalitetsestimator. Hvis det skete, havde SQL Server 2014 ikke så mange muligheder for at afhjælpe ydeevneproblemerne forårsaget af den nye CE. Joe's whitepaper dækker disse muligheder meget detaljeret, men i det væsentlige var du begrænset til sporingsflag på forekomstniveau eller forespørgselstip på forespørgselsniveau for at kontrollere, hvilken kardinalitetsestimator, der blev brugt af forespørgselsoptimeringsværktøjet, medmindre du ønskede at vende tilbage til kompatibilitetsniveau 110 eller lavere .

SQL Server 2016 Ændringer

SQL Server 2016 introducerede konfigurationsmuligheder med databaseomfang, som giver dig mulighed for at kontrollere nogle adfærd, der tidligere var konfigureret på instansniveau, ved hjælp af en ALTER DATABASE SCOPED CONFIGURATION-kommando. I SQL Server 2016 inkluderede disse muligheder MAXDOP, LEGACY_CARDINALITY ESTIMATION, PARAMETER_SNIFFING og QUERY_OPTIMIZER_HOTFIXES. Der var også en CLEAR PROCEDURE_CACHE-indstilling, der lod dig rydde hele plancachen for en enkelt database.

Mest relevante i denne sammenhæng er LEGACY_CARDINALITY ESTIMATION og QUERY_OPTIMIZER_HOTFIXES databaseomfangede konfigurationsmuligheder. LEGACY_CARDINALITY ESTIMATION aktiverer det gamle CE uanset indstillingen af ​​databasekompatibilitetsniveauet. Det svarer til sporingsflag 9481, men det påvirker kun den pågældende database, ikke hele instansen. Det giver dig mulighed for at indstille databasekompatibilitetsniveauet til 130 for at få en række funktionelle og ydeevnefordele, men stadig bruge den gamle CE-database i hele (medmindre den tilsidesættes af et forespørgselstip på forespørgselsniveau).

Indstillingen QUERY_OPTIMIZER_HOTFIXES svarer til sporingsflag 4199 på databaseniveau. SQL Server 2016 vil aktivere alle query optimizer hotfixes før SQL Server 2016 RTM, når du bruger 130 databasekompatibilitetsniveauet (uden at aktivere sporingsflag 4199). Hvis du aktiverer TF 4199 eller aktiverer QUERY_OPTIMIZER_HOTFIXES, får du også alle de forespørgselsoptimerings-hotfixes, der blev udgivet efter SQL Server 2016 RTM.

SQL Server 2016 SP1 introducerede også USE HINT-forespørgselstip, der er nemmere at bruge, forstå og huske end de ældre QUERYTRACEON-forespørgselstip. Dette giver dig endnu mere finkornet kontrol over optimeringsadfærd, der er relateret til databasekompatibilitetsniveauet og den version af kardinalitetsestimatoren, der bruges. Du kan forespørge sys.dm_exec_valid_use_hints for at få en liste over gyldige USE HINT-navne til den nøjagtige build af SQL Server, som du kører.

SQL Server 2017 Ændringer

Den nye adaptive forespørgselsbehandlingsfunktion blev tilføjet i SQL Server 2017 og er aktiveret som standard, når du bruger databasekompatibilitetsniveau 140.

Microsoft forsøger at bevæge sig væk fra den gamle terminologi "Ny CE" og "Gamle CE", da der faktisk er ændringer og rettelser til forespørgselsoptimering i hver ny større version af SQL Server. På grund af dette er der ikke længere et enkelt "New CE". I stedet ønsker Microsoft at henvise til CE70 (standard CE for SQL Server 7.0 til SQL Server 2012), CE120 for SQL Server 2014, CE130 for SQL Server 2016, CE140 for SQL Server 2017 og CE150 for SQL Server 2019. Startende med SQL Server 2019. 2017 CU10, kan du bruge USE HINT-funktionen til at styre dette med forespørgselstip. For eksempel:

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

… ville være et gyldigt forespørgselstip til at tvinge CE130-kardinalitetsestimatoren til en bestemt forespørgsel.

SQL Server 2019 Ændringer

SQL Server 2019 tilføjer endnu flere præstationsforbedringer og adfærdsændringer, der er aktiveret som standard, når en database bruger kompatibilitetstilstand 150. Et godt eksempel er skalar UDF-inlining. Et andet eksempel er den intelligente forespørgselsbehandlingsfunktion, som er et supersæt af den adaptive forespørgselsbehandling i SQL Server 2017.

Der er fem nye USE TIP-muligheder, inklusive måder at deaktivere batch-tilstand eller deaktivere adaptiv hukommelses-tildelingsfeedback, som vist i tabel 2:

Tabel 2 :Nye muligheder for BRUG TIP

Og der er også seksten nye konfigurationsmuligheder med databaseomfang (fra CTP 2.2), som giver dig kontrol på databaseniveau over flere elementer, der også er påvirket af sporingsflag eller databasekompatibilitetsniveau. Det giver dig mere finmasket kontrol over ændringer på højere niveau, der er aktiveret som standard med databasekompatibilitetsniveau 150. Disse er angivet i tabel 3:

Tabel 3:Nye konfigurationsmuligheder med databaseomfang

Konklusion

Migrering til en moderne version af SQL Server (hvilket betyder SQL Server 2016 eller nyere) er betydeligt mere kompliceret, end det var med ældre versioner af SQL Server. På grund af de ændringer, der er forbundet med de forskellige databasekompatibilitetsniveauer og forskellige kardinalitetsberegningsversioner, er det faktisk meget vigtigt at tænke, planlægge og faktisk afprøve, hvilket databasekompatibilitetsniveau du vil bruge på den nye version af SQL Server, som du migrerer dine eksisterende databaser til.

Microsofts anbefalede opgraderingsproces er at opgradere til den seneste SQL Server-version, men behold kildedatabasens kompatibilitetsniveau. Aktiver derefter Query Store på hver database og indsaml basisdata om arbejdsbyrden. Dernæst indstiller du databasekompatibilitetsniveauet til den seneste version og bruger derefter Query Store til at rette ydeevneregressioner ved at fremtvinge den sidst kendte gode plan.

Du vil virkelig gerne undgå en tilfældig "blind" migration, hvor du er lykkeligt uvidende om, hvordan dette fungerer, og hvordan din arbejdsbyrde vil reagere på disse ændringer. Ændring af databasekompatibilitetsniveauet til en passende version og brug af de passende databaseomfattede konfigurationsmuligheder sammen med passende forespørgselstip, hvor det er absolut nødvendigt, er ekstremt vigtigt med moderne versioner af SQL Server.