UPDATEs voor statistieken

De laatste verschillende releases van SQL Server hebben een hele reeks nieuwe functies geïntroduceerd, evenals verbeteringen in bestaande functionaliteit. Een deel van de engine dat gemakkelijk over het hoofd wordt gezien, is de statistiek. Statistieken worden immers nog steeds op dezelfde manier gemaakt, ze vertellen je nog steeds over de distributie van gegevens, ze worden nog steeds gebruikt door de Query Optimizer... wat is er anders? De basisfunctie van statistieken blijft hetzelfde, maar hoe ze door de Query Optimizer worden gebruikt, verandert afhankelijk van de kardinaliteitschatter die u gebruikt. Er zijn ook een aantal opmerkelijke veranderingen met betrekking tot het bijwerken van statistieken en er is nieuwe functionaliteit toegevoegd rond het bekijken van statistische informatie. Al met al kunnen deze wijzigingen in de nieuwste releases een variatie in het gedrag van SQL Server veroorzaken die u niet had verwacht.

Opmerking:dit bericht is het meest van toepassing op SQL Server 2012 en hoger, maar sommige details voor eerdere releases zijn ter referentie (en leuk) opgenomen.

SQL Server 7.0

Het aantal stappen in een histogram is beperkt tot 300. In SQL Server 6.5 en eerder zou een histogram het aantal stappen hebben dat op een 2K-pagina zou passen, gebaseerd op de grootte van de eerste kolom in de sleutel.
De database-optie 'statistieken automatisch bijwerken' wordt geïntroduceerd; voorheen werden statistieken alleen handmatig bijgewerkt.

SQL Server 2000

Het aantal stappen in het histogram is teruggebracht van 300 naar 200 (technisch gezien 201, als u de stap voor NULL opneemt, ervan uitgaande dat de eerste kolom in de sleutel NULL's toestaat).

SQL Server 2005

Updates van statistieken die FULLSCAN gebruiken, kunnen parallel worden uitgevoerd.
Tracevlaggen 2389 en 2390 zijn geïntroduceerd in SP1 om te helpen bij het probleem van de oplopende sleutel, beschreven in de post, Oplopende sleutels en Auto Quick Correct-statistieken. Een gedetailleerd voorbeeld van dit scenario wordt gegeven in mijn post Trace Flag 2389 en de nieuwe Cardinality Estimator.
De instantieoptie 'Statistieken automatisch asynchroon bijwerken' wordt geïntroduceerd. Merk op dat om dit van kracht te laten zijn, ook de optie 'Statistieken automatisch bijwerken' moet zijn ingeschakeld. Als u niet duidelijk bent over wat deze optie doet, raadpleegt u de documentatie in ALTER DATABASE SET Options. Dit is een instelling die Glenn aanbeveelt (zoals vermeld in zijn post waarnaar hieronder wordt verwezen), maar ik denk dat het belangrijk is om op de hoogte te zijn van mogelijke problemen, zoals vermeld in Hoe automatische updates van statistieken de prestaties van zoekopdrachten kunnen beïnvloeden.

Opmerking: Er is een geheugenlek met betrekking tot deze instelling in SQL Server 2008 tot en met SQL Server 2012; zie Glenn's post Belangrijke hotfix voor SQL Server 2008 voor meer details.

SQL Server 2008

Gefilterde statistieken worden geïntroduceerd, en deze kunnen afzonderlijk van een gefilterde index worden gemaakt. Er zijn enkele beperkingen rond gefilterde indexen met betrekking tot de Query Optimizer (zie Tim Chapman's post The Pains of Filtered Indexes en Paul White's post Optimizer Limitations with Filtered Indexes), en het is belangrijk om het gedrag te begrijpen van de teller die wijzigingen bijhoudt (en kan dus automatische updates activeren). Zie Kimberly's bericht Gefilterde indexen en gefilterde statistieken kunnen ernstig verouderd raken voor meer details, en ik raad ook aan haar opgeslagen procedure te bekijken die scheeftrekking van gegevens analyseert en aanbeveelt waar u gefilterde statistieken kunt maken om meer informatie te verstrekken aan de Query Optimizer. Ik heb dit geïmplementeerd voor verschillende grote klanten met VLT's en scheve verdeling over kolommen die vaak in predikaten worden gebruikt.
Twee nieuwe catalogusweergaven, sys.stats en sys.stats_columns, zijn toegevoegd om gemakkelijker inzicht te krijgen in statistieken en opgenomen kolommen. Gebruik deze twee weergaven in plaats van sp_helpstats, die verouderd is en minder informatie geeft.

SQL Server 2008R2 SP1

Trace Flag 2371 wordt beschikbaar gesteld, die kan worden gebruikt om het aantal wijzigingen te verminderen dat nodig is om automatische updates van statistieken te laten plaatsvinden. Ter herinnering:ik ben er een voorstander van om statistieken regelmatig bij te werken via een geplande taak en om de automatische update voor de zekerheid ingeschakeld te laten.

SQL Server 2008R2 SP2

De functie sys.dm_db_stats_properties is inbegrepen, die dezelfde informatie biedt als in de kop van DBCC SHOW_STATISTICS, evenals een wijzigingskolom die kan worden gebruikt om wijzigingen bij te houden en programmatisch te bepalen of een update nodig was. Weet je nog mijn voorkeur voor het gebruik van een baan om statistieken bij te werken? Die taak is zojuist een stuk slimmer geworden met deze DMF ... nu kan ik kijken hoeveel gegevens zijn gewijzigd en ALLEEN de statistieken bijwerken als een bepaald percentage gegevens is gewijzigd. Glad.

SQL Server 2012

Het bijwerken van statistieken zal er niet toe leiden dat plannen ongeldig worden ALS er geen rijen zijn gewijzigd. Dit is er een die veel mensen verrast, en Kimberly heeft een leuke post, Wat zorgde ervoor dat dat plan vreselijk mis ging - moet je de statistieken bijwerken?, die haar avontuur doorloopt om dit uit te zoeken.

SQL Server 2012 SP1

DBCC SHOW_STATISTICS vereist alleen de SELECT-machtiging – voorheen moest een gebruiker lid zijn van sysadmin, of een lid van de databaserol db_owner of db_ddladmin. Dit kan globaal worden uitgeschakeld met traceringsvlag 9485.
Omvat sys.dm_db_stats_properties (zie opmerking 2008R2 SP2 hierboven)

SQL Server 2012 SP2

Cumulatieve update 1 introduceert een oplossing voor het niet correct identificeren van oplopende sleutels, zelfs niet met traceervlaggen 2389 en 2390 in gebruik. Dit vereist traceringsvlag 4139 naast CU1, zoals vermeld in KB 2952101.

SQL Server 2014

De nieuwe Cardinality Estimator is geïntroduceerd, geïmplementeerd door de database-compatibiliteitsmodus in te stellen op 120, of door traceringsvlag 2312 te gebruiken. Als je niets hebt gelezen over de nieuwe CE, raad ik aan te beginnen met de Cardinality Estimation-documentatie en dan Joe te lezen Sack's whitepaper, Uw queryplannen optimaliseren met de SQL Server 2014 Cardinality Estimator, voor diepgaande details.
Het gedrag van Trace Flags 2389 en 2390 voor oplopende sleutels wordt nu geïmplementeerd via de databasecompatibiliteitsmodus. Als de compatibiliteitsmodus van uw databases is ingesteld op 120 (of hoger in latere releases), hoeft u Trace Flags 2389 en 2390 voor SQL Server niet te gebruiken om statistieken met oplopende sleutels te identificeren.
Incrementele statistieken zijn geïntroduceerd voor partities en kunnen worden bekeken via de nieuwe DMF sys.dm_db_incremental_stats_properties. Incrementele statistieken bieden een manier om statistieken voor een partitie bij te werken zonder ze voor de hele tabel bij te werken. De aanvullende statistische informatie uit de incrementele statistieken wordt echter niet gebruikt door de Query Optimizer, maar wordt samengevouwen in het hoofdhistogram voor de tabel.
CU2 bevat dezelfde oplossing als hierboven vermeld voor SQL Server 2012 SP2 waarvoor ook traceringsvlag 4139 is vereist.

SQL Server 2014 SP1

Tracevlag 7471 is teruggezet naar CU6, oorspronkelijk beschikbaar in SQL Server 2016, zoals hieronder vermeld.

SQL Server 2016

Tracevlag 2371 is niet langer nodig om de drempel voor automatische updates van statistieken te verlagen als de databasecompatibiliteitsmodus is ingesteld op 130. Zie het gedrag van Autostat (AUTO_UPDATE_STATISTICS) besturen in SQL Server.
Updates van statistieken kunnen parallel worden uitgevoerd bij gebruik van SAMPLE, niet alleen FULLSCAN. Dit is gekoppeld aan de compatibiliteitsmodus (moet 130 zijn), maar kan mogelijk snellere updates bieden en dus de onderhoudsvensters verkleinen. Aaron Bertrand vertelt over deze verbetering in zijn post, Een potentiële verbetering voor statistieken-updates:MAXDOP.
Trace flag 7471 is geïntroduceerd in CU1 zodat meerdere UPDATE STATISTICS-commando's gelijktijdig kunnen worden uitgevoerd voor een enkele tabel en Jonathan geeft enkele geweldige voorbeelden van hoe dit kan worden gebruikt in zijn post Verbeterde ondersteuning voor parallelle statistische reconstructies.

SQL Server 2016 SP1

De optie voor de query-hint ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS wordt geïntroduceerd, samen met het FOR HINT-argument, dat het equivalent is van traceringsvlag 4139.
Het DMF sys.dm_db_stats_histogram wordt weergegeven in CU2, wat een alternatief is voor de histogramuitvoer van DBCC SHOW_STATISTICS. De informatie in beide is hetzelfde, gebruik wat voor u gemakkelijker is of beter past bij het probleem dat u moet oplossen.
De optie PERSIST_SAMPLE_PERCENT is geïntroduceerd in CU4, die kan worden gebruikt om te forceren dat dezelfde steekproeffrequentie wordt gebruikt telkens wanneer een statistiek in de toekomst wordt bijgewerkt, en voorbeelden van dit gedrag zijn te vinden in de post, Aanhoudende steekproeffrequentie voor statistieken.

SQL Server 2017

De optie PERSIST_SAMPLE_PERCENT is beschikbaar in CU1 (zie SP1-item 2016 voor aanvullende informatie).
De attributen StatsInfoType en OptimizerStatsUsageType worden toegevoegd aan het Queryplan, waarin de statistieken worden weergegeven die tijdens de queryoptimalisatie worden gebruikt. Deze is beschikbaar in CU3 en is gekoppeld aan de CE-versie (120 en hoger). Dit is best gaaf! Ik heb hier nog niet mee kunnen spelen, maar om deze informatie eerder te krijgen moest je ongedocumenteerde traceervlaggen gebruiken.
CU3 introduceerde ook de MAXDOP-optie voor CREATE STATISTICS en UPDATE STATISTICS, die kan worden gebruikt om de MAXDOP-waarde voor de instantie of database te overschrijven.
Nog een toevoeging in CU3:de kenmerken UdfCpuTime en UdfElapsedTime zijn te vinden in het Queryplan, die uitvoeringsstatistieken vertegenwoordigen voor scalaire waarde UDF's.

Samenvatting

Als u op zoek bent naar een upgrade naar een nieuwere release, of als u onlangs een upgrade heeft uitgevoerd, let dan op de invloed van deze wijzigingen op uw oplossing. Veel klanten hebben contact met ons opgenomen na een upgrade van 2005/2008/2008R2 naar 2014 of 2016, met klachten over prestatieproblemen. In veel gevallen is er voorafgaand aan de upgrade niet voldoende getest.

Dit is iets waar we ons echt op focussen wanneer we een klant helpen upgraden. Naast de stappen om een productie-instantie van de ene versie naar de andere te verplaatsen met weinig downtime, willen we ervoor zorgen dat de dag na de upgrade een saaie dag is voor DBA's en ontwikkelaars.

We testen niet alleen het upgradeproces, we testen hoe het systeem eruitziet na de upgrade. Zijn dezelfde traceervlaggen uit de oude omgeving nodig in de nieuwe? Welke database-instellingen moeten worden aangepast? Veranderen de prestaties van query's - ten goede of ten kwade? Als je het antwoord op die vragen niet weet voordat je de productie opwaardeert, dan ben je klaar voor een tot vele dagen brandbestrijding, Sev 1-oproepen, maaltijden aan je bureau, niet genoeg slaap en wie weet wat nog meer .

Neem van tevoren de tijd om de impact van de nieuwe functies en wijzigingen in de functionaliteit die hierboven worden vermeld te begrijpen, plan de upgrade en test zoveel mogelijk.