Så i SQL Server 2016 kører statistikopdateringer ved hjælp af eksempeltilstand nu parallelt under kompatibilitetsniveau 130, og det er sådan det fungerer som standard for alle automatiske og manuelle statistikopdateringer. Dette forklares kort her:
- Forespørgselsoptimeringstilføjelser i SQL Server 2016
(Dokumentationen er også blevet opdateret, både emnet for kompatibilitetsniveau og emnet OPDATERING STATISTIK.)
Ville det dog ikke være rart at være i stand til at specificere, hvor mange CPU'er der faktisk kan bruges til disse operationer (bortset fra blot at tillade grænsen på 16)? Jeg tror, at det at kunne begrænse dette til 4 eller 8 ville være en indlysende og logisk ting at støtte. Især for kunder, der kører systemer med 16 eller færre kerner eller flere instanser på en boks, som ikke kan stole på Enterprise-funktioner som Resource Governor (som de fleste Enterprise-kunder heller ikke kunne være generet af at bruge, IMHO).
Den forretningsmæssige begrundelse for dette ville være den samme som begrundelserne brugt til at tilføje MAXDOP support REBUILD, DBCC CHECKDB og dens familie af vedligeholdelsesoperationer osv. Du vil forhindre denne type aktivitet i at overtage alle kernerne uden at gøre noget så drastisk som at deaktivere automatiske opdateringer eller bruge MAXDOP for hele instansen – fordi ikke alle har luksusen af vedligeholdelsesvinduer.
Og i dette tilfælde vil MAXDOP for hele instansen ikke hjælpe alligevel , fordi SQL Server 2016 RTM har en fejl, hvor MAXDOP ignoreres for stikprøver af statistikopdateringer. En rettelse er på vej, men jeg tænkte, at du skulle vide det; hvis dette volder dig et problem, er en mulighed at bruge et lavere kompatibilitetsniveau.
Men jeg vil gentage noget, jeg ofte siger:Kompatibilitetsniveauet bliver alt for overfyldt. Hvis jeg vil have parallelle samplede statistikker på min database, men jeg har nok kardinalitetsestimatregressioner til at kræve den gamle CE, er jeg nødt til at vælge den ene eller den anden.
Og en anden ting:Resource Governor er overkill til denne use case, og begrænsning af kernebrug fra statistikopdateringer burde egentlig ikke være en Enterprise-funktion (ligesom REBUILD og CHECKDB nævnt ovenfor). Fortæl mig venligst ikke, at RG er et acceptabelt alternativ, fordi det kun er muligt for brugere med Enterprise Edition *og* arbejdsbelastningsklassifikationer, der bør være begrænset af MAXDOP hele tiden . Jeg burde være i stand til at begrænse dette ved specifik handling (eller f.eks. kun for mine største/problemtabeller), ikke ved at begrænse et logins hele session.
Hvor ville jeg ønske, de ville gøre det
Ideelt set ville vi være i stand til at indstille dette på databaseniveau ved at bruge den nye DATABASE SCOPED CONFIGURATION-indstilling og på sætningsniveauet ved at bruge den velkendte OPTION (MAXDOP n) syntaks. Udsagnsniveau ville vinde, og enhver statistisk opdatering af eksempeltilstand (inklusive automatisk) uden et eksplicit MAXDOP-tip ville falde tilbage til indstillingen af databaseniveau. Dette ville tillade mig at indstille en MAXDOP på for eksempel 4 for alle automatiske statistikopdateringer, der sker på uforudsigelige tidspunkter, men 8 eller 16 for manuelle operationer i kendte vedligeholdelsesvinduer. Som et eksempel.
Hvis du vil stemme for dette, så se venligst følgende Connect-emne, og tilføj en forretningsmæssig begrundelse for dette (a la Michael Campbell):
- Forbind #628971:Tilføj MAXDOP-parameter til opdatering af statistik
Den vare har selvfølgelig været der siden 2010, så der er slet ingen omtale om DATABASE SCOPED CONFIGURATION avenue, hvorfor jeg også efterlod en kommentar.
I mellemtiden, hvis du vil deaktivere parallelisme for prøvetilstand, er der et sporingsflag for effektivt at vende tilbage til ældre adfærd (du kan også gøre dette ved at vende tilbage til et kompatibilitetsniveau på mindre end 130, men jeg anbefaler ikke dette, fordi det påvirker en masse andre ting). Jeg vil opdatere denne plads, når jeg har fået lov til at offentliggøre sporingsflaget, men lige nu holder Microsoft det fast til deres bryst.