UPPDATERINGAR till statistik

De senaste versionerna av SQL Server har introducerat en rad nya funktioner, såväl som förbättringar av befintlig funktionalitet. Ett område av motorn som är lätt att förbise är statistik. När allt kommer omkring skapas statistik fortfarande på samma sätt, den berättar fortfarande om distributionen av data, den används fortfarande av Query Optimizer ... vad är skillnaden? Statistikens grundläggande funktion förblir densamma – men hur de används av frågeoptimeraren ändras beroende på vilken kardinalitetsskattare du använder. Det finns också flera anmärkningsvärda ändringar relaterade till uppdatering av statistik och ny funktionalitet har lagts till kring visning av statistikinformation. Sammantaget kan dessa ändringar över de senaste utgåvorna orsaka en variation i SQL Server-beteende som du inte förväntade dig.

Obs:Det här inlägget är mest tillämpligt på SQL Server 2012 och högre, men vissa detaljer för tidigare utgåvor ingår som referens (och roligt).

SQL Server 7.0

Antalet steg i ett histogram är begränsat till 300. I SQL Server 6.5 och tidigare skulle ett histogram ha det antal steg som får plats på en 2K-sida, baserat på storleken på den första kolumnen i nyckeln.
Databasalternativet "uppdatera statistik automatiskt" introduceras; tidigare uppdaterades statistik endast manuellt.

SQL Server 2000

Antalet steg i histogrammet reduceras från 300 till 200 (tekniskt sett 201, om du inkluderar steget för NULL, förutsatt att den första kolumnen i nyckeln tillåter NULL).

SQL Server 2005

Uppdateringar av statistik som använder FULLSCAN kan köras parallellt.
Spårningsflaggor 2389 och 2390 introduceras i SP1 för att hjälpa till med problemet med stigande nyckel, som beskrivs i inlägget, stigande nycklar och statistik för automatisk snabbkorrigering. Ett detaljerat exempel på detta scenario finns i mitt inlägg Trace Flag 2389 och den nya Cardinality Estimator.
Förekomstalternativet "Uppdatera statistik automatiskt asynkront" introduceras. Observera att för att detta ska vara i kraft måste alternativet "Uppdatera statistik automatiskt" också vara aktiverat. Om du inte är klar över vad det här alternativet gör, läs dokumentationen i ALTER DATABASE SET Options. Det här är en inställning som Glenn rekommenderar (som noteras i hans inlägg som hänvisas till nedan), men jag tror att det är viktigt att vara medveten om potentiella problem, som noteras i Hur automatiska uppdateringar av statistik kan påverka frågeprestanda.

Obs! Det finns en minnesläcka relaterad till den här inställningen i SQL Server 2008 till och med SQL Server 2012; Se Glenns inlägg Viktig snabbkorrigering för SQL Server 2008 för mer information.

SQL Server 2008

Filtrerad statistik introduceras och denna kan skapas separat från ett filtrerat index. Det finns vissa begränsningar kring filtrerade index med avseende på Query Optimizer (se Tim Chapmans inlägg The Pains of Filtered Indexes och Paul Whites post Optimizer Limitations with Filtered Indexes), och det är viktigt att förstå beteendet hos räknaren som spårar ändringar (och kan därför utlösa automatiska uppdateringar). Se Kimberlys inlägg Filtrerade index och filtrerad statistik kan bli allvarligt inaktuell för mer information, och jag rekommenderar också att du kollar in hennes lagrade procedur som analyserar dataskevhet och rekommenderar var du kan skapa filtrerad statistik för att ge mer information till frågeoptimeraren. Jag har implementerat detta för flera stora kunder som har VLT:er och skev distribution över kolumner som ofta används i predikat.
Två nya katalogvyer, sys.stats och sys.stats_columns, läggs till för att ge enklare insikt i statistik och inkluderade kolumner. Använd dessa två vyer istället för sp_helpstats, som är föråldrat och ger mindre information.

SQL Server 2008R2 SP1

Spårningsflagga 2371 görs tillgänglig, som kan användas för att minska antalet ändringar som krävs för att automatiska uppdateringar av statistik ska ske. Som en påminnelse är jag ett fan av att uppdatera statistik regelbundet genom ett schemalagt jobb och att lämna den automatiska uppdateringen aktiverad som en säkerhet.

SQL Server 2008R2 SP2

Funktionen sys.dm_db_stats_properties ingår, som ger samma information som finns i rubriken för DBCC SHOW_STATISTICS, samt en modifieringskolumn som kan användas för att spåra ändringar och programmässigt avgöra om en uppdatering behövdes. Kommer du ihåg att jag föredrar att använda ett jobb för att uppdatera statistik? Det jobbet blev bara mycket smartare med denna DMF...nu kan jag se hur mycket data som har ändrats och ENDAST uppdatera statistik om en viss procentandel av data har ändrats. Slick.

SQL Server 2012

Uppdatering av statistik gör inte att planer blir ogiltiga OM inga rader har ändrats. Det här är ett som överraskar många människor, och Kimberly har ett roligt inlägg, Vad fick den planen att gå fruktansvärt fel – ska du uppdatera statistik?, som går igenom hennes äventyr för att ta reda på det här.

SQL Server 2012 SP1

DBCC SHOW_STATISTICS kräver bara SELECT-behörigheten – tidigare krävde det att en användare var medlem i sysadmin, eller en medlem av databasrollen db_owner eller db_ddladmin. Detta kan inaktiveras globalt med spårningsflagga 9485.
Innehåller sys.dm_db_stats_properties (se 2008R2 SP2 notering ovan)

SQL Server 2012 SP2

Kumulerad uppdatering 1 introducerar en fix relaterad till att stigande nycklar inte identifieras korrekt även med spårningsflaggor 2389 och 2390 i bruk. Detta kräver spårningsflagga 4139 förutom CU1, som anges i KB 2952101.

SQL Server 2014

Den nya Cardinality Estimator introduceras, implementeras genom att ställa in databaskompatibilitetsläget till 120, eller genom att använda spårningsflagga 2312. Om du inte har läst något om det nya CE rekommenderar jag att börja med Cardinality Estimation-dokumentationen och sedan läsa Joe Sacks whitepaper, Optimera dina frågeplaner med SQL Server 2014 Cardinality Estimator, för djupgående detaljer.
Beteendet från Trace Flags 2389 och 2390 för stigande nycklar implementeras nu via databaskompatibilitetsläget. Om ditt databaskompatibilitetsläge är inställt på 120 (eller högre i senare utgåvor) behöver du inte använda Trace Flags 2389 och 2390 för SQL Server för att identifiera statistik som har stigande nycklar.
Inkrementell statistik introduceras för partitioner och kan ses via den nya DMF sys.dm_db_incremental_stats_properties. Inkrementell statistik ger ett sätt att uppdatera statistik för en partition utan att uppdatera den för hela tabellen. Den ytterligare statistikinformationen från den inkrementella statistiken används dock inte av Query Optimizer, utan den viks in i tabellens huvudhistogram.
CU2 innehåller samma fix som nämns ovan för SQL Server 2012 SP2 som också kräver spårningsflagga 4139.

SQL Server 2014 SP1

Spårningsflagga 7471 är backporterad till CU6, ursprungligen tillgänglig i SQL Server 2016 enligt nedan.

SQL Server 2016

Spårningsflagga 2371 behövs inte längre för att minska tröskeln för automatiska uppdateringar av statistik om databaskompatibilitetsläget är satt till 130. Se Styra Autostat-beteende (AUTO_UPDATE_STATISTICS) i SQL Server.
Uppdateringar av statistik kan köras parallellt när du använder SAMPLE, inte bara FULLSCAN. Detta är kopplat till kompatibilitetsläget (måste vara 130), men kan potentiellt ge snabbare uppdateringar och därmed minska underhållsfönster. Aaron Bertrand berättar om denna förbättring i sitt inlägg, En potentiell förbättring för statistikuppdateringar:MAXDOP.
Spårningsflagga 7471 introduceras i CU1 för att tillåta flera UPDATE STATISTICS-kommandon att köras samtidigt för en enskild tabell och Jonathan ger några bra exempel på hur detta kan användas i hans post Förbättrat stöd för ombyggnader av parallellstatistik.

SQL Server 2016 SP1

Frågetipsalternativet ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS introduceras, tillsammans med FOR HINT-argumentet, vilket motsvarar spårningsflaggan 4139.
DMF sys.dm_db_stats_histogram exponeras i CU2, vilket är ett alternativ till histogrammet från DBCC SHOW_STATISTICS. Informationen i båda är densamma, använd det som är enklare för dig eller bättre passar det problem du behöver lösa.
Alternativet PERSIST_SAMPLE_PERCENT introduceras i CU4, som kan användas för att tvinga samma samplingsfrekvens att användas varje gång en statistik uppdateras framöver, och exempel på detta beteende kan hittas i inlägget, Persisting statistics samplingsfrekvens.

SQL Server 2017

Alternativet PERSIST_SAMPLE_PERCENT är tillgängligt i CU1 (se 2016 SP1-posten för ytterligare information).
Attributen StatsInfoType och OptimizerStatsUsageType läggs till i frågeplanen, som listar statistik som används under frågeoptimering. Denna finns i CU3 och är kopplad till CE-versionen (120 och högre). Det här är ganska coolt! Jag har inte haft en chans att leka med det här än, men för att få denna information tidigare var du tvungen att använda odokumenterade spårningsflaggor.
CU3 introducerade också MAXDOP-alternativet för CREATE STATISTICS och UPDATE STATISTICS, som kan användas för att åsidosätta MAXDOP-värdet för instansen eller databasen.
Ännu ett tillägg i CU3:attributen UdfCpuTime och UdfElapsedTime finns i frågeplanen, som representerar exekveringsstatistik för UDF:er med skalärt värde.

Sammanfattning

Om du funderar på att uppgradera till en nyare version, eller om du nyligen har uppgraderat, notera hur dessa ändringar påverkar din lösning. Vi har fått många kunder att kontakta oss efter att ha uppgraderat från 2005/2008/2008R2 till 2014 eller 2016 och klagat på prestandaproblem. I många fall slutfördes inte adekvata tester före uppgraderingen.

Detta är något vi verkligen fokuserar på när vi hjälper en kund att uppgradera. Utöver stegen för att flytta en produktionsinstans från en version till en annan med lite stillestånd, vill vi se till att dagen efter uppgraderingen är tråkig för DBA:er och utvecklare.

Vi testar inte bara uppgraderingsprocessen, vi testar hur systemet ser ut efter uppgraderingen. Behövs samma spårflaggor från den gamla miljön i den nya? Vilka databasinställningar behöver justeras? Förändras frågeprestanda – på gott och ont? Om du inte vet svaren på de här frågorna innan du uppgraderar produktionen, då bereder du dig på en till många dagars brandbekämpning, Sev 1-samtal, måltider vid skrivbordet, inte tillräckligt med sömn och vem vet vad mer .

Ta dig tid i förväg för att förstå effekten av de nya funktionerna och ändringarna i funktionaliteten som anges ovan, planera uppgraderingen och testa så mycket som möjligt.