OPDATERINGER til statistik

De seneste adskillige udgivelser af SQL Server har introduceret en række nye funktioner, såvel som forbedringer i eksisterende funktionalitet. Et område af motoren, som er let at overse, er statistik. Når alt kommer til alt, bliver statistikker stadig oprettet på samme måde, de fortæller dig stadig om distributionen af data, de bruges stadig af Query Optimizer ... hvad er anderledes? Statistikkens grundlæggende funktion forbliver den samme - men hvordan de bruges af Query Optimizer, ændrer sig afhængigt af den Cardinality Estimator, du bruger. Der er også flere bemærkelsesværdige ændringer relateret til opdatering af statistik, og der er tilføjet ny funktionalitet omkring visning af statistikinformation. Alt i alt kan disse ændringer på tværs af de seneste udgivelser forårsage en variation i SQL Server-adfærd, som du ikke havde forventet.

Bemærk:Dette indlæg er mest anvendeligt til SQL Server 2012 og højere, men nogle detaljer for tidligere udgivelser er inkluderet til reference (og sjov).

SQL Server 7.0

Antallet af trin i et histogram er begrænset til 300. I SQL Server 6.5 og tidligere vil et histogram have det antal trin, der kunne passe på en 2K-side, baseret på størrelsen af den første kolonne i nøglen.
Databasemuligheden "opdater statistikker automatisk" er introduceret; tidligere statistikker blev kun opdateret manuelt.

SQL Server 2000

Antallet af trin i histogrammet reduceres fra 300 til 200 (teknisk set 201, hvis du inkluderer trinnet for NULL, forudsat at den første kolonne i nøglen tillader NULL).

SQL Server 2005

Opdateringer til statistik, der bruger FULLSCAN, kan køre parallelt.
Sporingsflag 2389 og 2390 er introduceret i SP1 for at hjælpe med Ascending Key-problemet, beskrevet i indlægget, Ascending Keys og Auto Quick Correct Statistics. Et detaljeret eksempel på dette scenarie findes i mit indlæg Trace Flag 2389 og den nye Cardinality Estimator.
Forekomstmuligheden "Opdater statistikker automatisk asynkront" introduceres. Bemærk, at for at dette kan være i kraft, skal indstillingen 'Opdater statistik automatisk' også være aktiveret. Hvis du ikke er klar over, hvad denne mulighed gør, kan du gennemgå dokumentationen i ALTER DATABASE SET Options. Dette er en indstilling, som Glenn anbefaler (som bemærket i hans indlæg, der henvises til nedenfor), men jeg tror, det er vigtigt at være opmærksom på potentielle problemer, som nævnt i, hvordan automatiske opdateringer til statistikker kan påvirke forespørgselsydeevne.

Bemærk: Der er en hukommelseslæk relateret til denne indstilling i SQL Server 2008 til og med SQL Server 2012; Se venligst Glenns indlæg Vigtigt hotfix til SQL Server 2008 for flere detaljer.

SQL Server 2008

Filtrerede statistikker introduceres, og disse kan oprettes separat fra et filtreret indeks. Der er nogle begrænsninger omkring filtrerede indekser med hensyn til Query Optimizer (se Tim Chapmans indlæg The Pains of Filtered Indexes og Paul Whites indlæg Optimizer Limitations with Filtered Indexes), og det er vigtigt at forstå opførselen af tælleren, der sporer ændringer (og kan således udløse automatiske opdateringer). Se Kimberlys indlæg Filtrerede indekser og filtrerede statistikker kan blive alvorligt forældede for flere detaljer, og jeg anbefaler også, at du tjekker hendes lagrede procedure, der analyserer dataskævhed og anbefaler, hvor du kan oprette filtreret statistik for at give flere oplysninger til Query Optimizer. Jeg har implementeret dette for flere store kunder, der har VLT'er og skæv fordeling på tværs af kolonner, der ofte bruges i prædikater.
To nye katalogvisninger, sys.stats og sys.stats_columns, er tilføjet for at give lettere indsigt i statistik og inkluderede kolonner. Brug disse to visninger i stedet for sp_helpstats, som er forældet og giver færre oplysninger.

SQL Server 2008R2 SP1

Trace Flag 2371 er gjort tilgængeligt, som kan bruges til at reducere antallet af ændringer, der kræves for at automatiske opdateringer af statistik kan finde sted. Som en påmindelse er jeg fan af at opdatere statistikker med jævne mellemrum gennem et planlagt job og lade den automatiske opdatering være aktiveret som en sikkerhed.

SQL Server 2008R2 SP2

Funktionen sys.dm_db_stats_properties er inkluderet, som giver den samme information, som findes i overskriften på DBCC SHOW_STATISTICS, samt en modifikationskolonne, der kan bruges til at spore ændringer og programmæssigt bestemme, om en opdatering var nødvendig. Kan du huske min præference for at bruge et job til at opdatere statistik? Det job er lige blevet meget smartere med denne DMF...nu kan jeg se, hvor meget data der er blevet ændret og KUN opdatere statistik, hvis en vis procentdel af data er ændret. Glat.

SQL Server 2012

Opdatering af statistik vil ikke medføre, at planer bliver ugyldige, HVIS ingen rækker er ændret. Dette er en, der overrasker mange mennesker, og Kimberly har et sjovt indlæg, Hvad fik den plan til at gå grueligt galt – skal du opdatere statistikker?, som går gennem hendes eventyr for at finde ud af dette.

SQL Server 2012 SP1

DBCC SHOW_STATISTICS kræver kun SELECT-tilladelsen – tidligere krævede det, at en bruger var medlem af sysadmin eller et medlem af databaserollen db_owner eller db_ddladmin. Dette kan deaktiveres globalt med sporingsflag 9485.
Indeholder sys.dm_db_stats_properties (se 2008R2 SP2 note ovenfor)

SQL Server 2012 SP2

Kumulativ opdatering 1 introducerer en rettelse relateret til, at stigende nøgler ikke bliver korrekt identificeret, selv med sporingsflag 2389 og 2390 i brug. Dette kræver sporingsflag 4139 ud over CU1, som angivet i KB 2952101.

SQL Server 2014

Den nye Cardinality Estimator introduceres, implementeret ved at sætte databasekompatibilitetstilstanden til 120 eller ved at bruge sporingsflag 2312. Hvis du ikke har læst noget om den nye CE, anbefaler jeg at starte med Cardinality Estimator-dokumentationen og derefter læse Joe Sacks whitepaper, Optimering af dine forespørgselsplaner med SQL Server 2014 Cardinality Estimator, for dybdegående detaljer.
Opførslen fra Trace Flags 2389 og 2390 for stigende nøgler er nu implementeret via databasekompatibilitetstilstanden. Hvis din databasekompatibilitetstilstand er indstillet til 120 (eller højere i senere udgivelser), behøver du ikke bruge Trace Flags 2389 og 2390 til SQL Server for at identificere statistik, der har stigende nøgler.
Inkrementel statistik introduceres for partitioner og kan ses gennem den nye DMF sys.dm_db_incremental_stats_properties. Inkrementelle statistikker giver mulighed for at opdatere statistik for en partition uden at opdatere dem for hele tabellen. De yderligere statistikoplysninger fra den trinvise statistik bruges dog ikke af Query Optimizer, men den foldes ind i tabellens hovedhistogram.
CU2 indeholder den samme rettelse som nævnt ovenfor for SQL Server 2012 SP2, der også kræver sporingsflag 4139.

SQL Server 2014 SP1

Sporingsflag 7471 er back-porteret til CU6, som oprindeligt var tilgængelig i SQL Server 2016 som angivet nedenfor.

SQL Server 2016

Sporingsflag 2371 er ikke længere nødvendigt for at reducere tærsklen for automatiske opdateringer af statistik, hvis databasekompatibilitetstilstanden er sat til 130. Se Styring af Autostat-adfærd (AUTO_UPDATE_STATISTICS) i SQL Server.
Opdateringer til statistik kan køre parallelt, når du bruger SAMPLE, ikke kun FULLSCAN. Dette er bundet til kompatibilitetstilstanden (skal være 130), men kan potentielt give hurtigere opdateringer og dermed reducere vedligeholdelsesvinduer. Aaron Bertrand fortæller om denne forbedring i sit indlæg, En potentiel forbedring af statistikopdateringer:MAXDOP.
Sporingsflag 7471 er introduceret i CU1 for at tillade flere OPDATERINGSSTATISTIK-kommandoer at køre samtidigt for en enkelt tabel, og Jonathan giver nogle gode eksempler på, hvordan dette kan bruges i hans post Forbedret støtte til genopbygning af parallelle statistikker.

SQL Server 2016 SP1

Forespørgselstip-indstillingen ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS introduceres sammen med FOR HINT-argumentet, som svarer til sporingsflag 4139.
DMF sys.dm_db_stats_histogram er eksponeret i CU2, som er et alternativ til histogram output fra DBCC SHOW_STATISTICS. Oplysningerne i begge er de samme, brug det, der er nemmere for dig eller passer bedre til det problem, du skal løse.
Muligheden PERSIST_SAMPLE_PERCENT er introduceret i CU4, som kan bruges til at tvinge den samme samplingfrekvens til at blive brugt, hver gang en statistik opdateres fremover, og eksempler på denne adfærd kan findes i indlægget, Persisting statistics sampling rate.

SQL Server 2017

PERSIST_SAMPLE_PERCENT-indstillingen er tilgængelig i CU1 (se 2016 SP1-indgang for yderligere information).
Attributterne StatsInfoType og OptimizerStatsUsageType føjes til forespørgselsplanen, som viser statistik brugt under forespørgselsoptimering. Denne fås i CU3 og er knyttet til CE-versionen (120 og højere). Det her er ret fedt! Jeg har ikke haft mulighed for at lege med dette endnu, men for at få disse oplysninger tidligere var du nødt til at bruge udokumenterede sporingsflag.
CU3 introducerede også MAXDOP-indstillingen for CREATE STATISTICS og UPDATE STATISTICS, som kan bruges til at tilsidesætte MAXDOP-værdien for instansen eller databasen.
En yderligere tilføjelse i CU3:UdfCpuTime- og UdfElapsedTime-attributterne kan findes i forespørgselsplanen, som repræsenterer udførelsesstatistikker for UDF'er med skalarværdi.

Oversigt

Hvis du ønsker at opgradere til en nyere udgivelse, eller hvis du for nylig har opgraderet, skal du være opmærksom på, hvordan disse ændringer påvirker din løsning. Vi har haft mange kunder til at kontakte os efter opgradering fra 2005/2008/2008R2 til 2014 eller 2016 og klagede over ydeevneproblemer. I mange tilfælde blev der ikke gennemført tilstrækkelig test før opgraderingen.

Dette er noget, vi virkelig fokuserer på, når vi hjælper en klient med at opgradere. Ud over trinene til at flytte en produktionsinstans fra en version til en anden med lidt nedetid, vil vi sikre os, at dagen efter opgraderingen er en kedelig dag for DBA'er og udviklere.

Vi tester ikke blot opgraderingsprocessen, vi tester, hvordan systemet ser ud efter opgraderingen. Er der brug for de samme sporflag fra det gamle miljø i det nye? Hvilke databaseindstillinger skal justeres? Ændres forespørgselsydeevne - på godt eller ondt? Hvis du ikke kender svarene på de spørgsmål, før du opgraderer produktionen, så er du klar til en til mange dages brandslukning, Sev 1-opkald, måltider ved dit skrivebord, ikke nok søvn og hvem ved hvad ellers .

Tag dig tid på forhånd til at forstå virkningen af de nye funktioner og ændringer i funktionaliteten nævnt ovenfor, planlæg opgraderingen og test så meget som muligt.