Dus in SQL Server 2016 worden statistische updates met de voorbeeldmodus nu parallel uitgevoerd onder compatibiliteitsniveau 130, en dit is hoe het standaard werkt, voor alle automatische en handmatige statistische updates. Dit wordt hier kort uitgelegd:
- Query Optimizer-toevoegingen in SQL Server 2016
(De documentatie is ook bijgewerkt, zowel het onderwerp Compatibiliteitsniveau als het onderwerp UPDATE STATISTICS.)
Zou het echter niet fijn zijn om te kunnen specificeren hoeveel CPU's daadwerkelijk voor deze bewerkingen kunnen worden gebruikt (behalve alleen de limiet van 16 toe te staan)? Ik denk dat de mogelijkheid om dit te beperken tot 4 of 8 een voor de hand liggende en logische zaak zou zijn om te ondersteunen. Vooral voor klanten met systemen met 16 of minder cores, of meerdere instanties op een box, die niet kunnen vertrouwen op Enterprise-functies zoals Resource Governor (die de meeste Enterprise-klanten ook niet zouden kunnen gebruiken, IMHO).
De zakelijke rechtvaardiging hiervoor zou dezelfde zijn als de rechtvaardiging die wordt gebruikt voor het toevoegen van MAXDOP-ondersteuning REBUILD, DBCC CHECKDB en zijn familie van onderhoudsactiviteiten, enz. U wilt voorkomen dat dit soort activiteiten alle kernen overneemt, zonder zoiets drastisch te doen zoals het uitschakelen van automatische updates of het gebruik van instantiebrede MAXDOP - omdat niet iedereen de luxe heeft van onderhoudsvensters.
En in dit geval zal MAXDOP voor de hele instantie sowieso niet helpen , omdat SQL Server 2016 RTM een bug bevat waarbij MAXDOP wordt genegeerd voor voorbeeldstatistiekenupdates. Er komt een oplossing, maar ik dacht dat je het moest weten; als dit voor een probleem zorgt, is een optie om een lager compatibiliteitsniveau te gebruiken.
Maar ik zal iets herhalen dat ik vaak zeg:het compatibiliteitsniveau wordt veel te druk. Als ik parallelle gesamplede statistieken in mijn database wil, maar ik heb genoeg regressies voor kardinaliteitsschattingen om de oude CE te vereisen, moet ik de een of de ander kiezen.
En nog iets:Resource Governor is overkill voor deze use case, en het beperken van het kerngebruik van statistische updates zou niet echt een Enterprise-functie moeten zijn (net als de hierboven genoemde REBUILD en CHECKDB). Vertel me alsjeblieft niet dat RG een acceptabel alternatief is, omdat het alleen mogelijk is voor gebruikers met Enterprise Edition *en* workloadclassificaties die altijd door MAXDOP moeten worden beperkt. . Ik zou dit moeten kunnen beperken door een specifieke bewerking (of, laten we zeggen, alleen voor mijn grootste/probleemtabellen), niet door de hele login-sessie te beperken.
Wat zou ik willen dat ze het zouden doen
In het ideale geval zouden we dit op databaseniveau kunnen instellen, met behulp van de nieuwe DATABASE SCOPED CONFIGURATION-optie, en op instructieniveau, met behulp van de bekende OPTION (MAXDOP n)-syntaxis. Het instructieniveau zou winnen, en eventuele updates van de steekproefmodusstatistieken (inclusief automatisch) zonder een expliciete MAXDOP-hint zouden terugvallen op de instelling op databaseniveau. Hierdoor zou ik bijvoorbeeld een MAXDOP van 4 kunnen instellen voor alle automatische updates van statistieken die op onvoorspelbare tijden plaatsvinden, maar 8 of 16 voor handmatige bewerkingen in bekende onderhoudsvensters. Als een voorbeeld.
Als je hiervoor wilt stemmen, bekijk dan het volgende Connect-item en voeg een zakelijke rechtvaardiging toe (a la Michael Campbell):
- Connect #628971:MAXDOP-parameter toevoegen om statistieken bij te werken
Dat item is er natuurlijk al sinds 2010, dus er is helemaal geen melding gemaakt van de DATABASE SCOPED CONFIGURATION-weg, daarom heb ik ook een opmerking achtergelaten.
Als u in de tussentijd parallellisme voor de voorbeeldmodus wilt uitschakelen, is er een traceervlag om effectief terug te keren naar ouder gedrag (u kunt dit ook doen door terug te keren naar een compatibiliteitsniveau van minder dan 130, maar ik raad dit niet aan omdat het beïnvloedt veel andere dingen). Ik zal deze ruimte bijwerken wanneer ik toestemming heb gekregen om de traceringsvlag openbaar te maken, maar op dit moment houdt Microsoft hem stevig tegen hun borst.