Så i SQL Server 2016 körs nu statistikuppdateringar med hjälp av exempelläge parallellt under kompatibilitetsnivå 130, och det är så här det fungerar som standard, för alla automatiska och manuella statistikuppdateringar. Detta förklaras kort här:
- Frågeoptimeringstillägg i SQL Server 2016
(Dokumentationen har också uppdaterats, både ämnet kompatibilitetsnivå och ämnet UPPDATERA STATISTIK.)
Skulle det dock inte vara trevligt att kunna specificera hur många processorer som faktiskt kan användas för dessa operationer (annat än att bara tillåta taket på 16)? Jag tror att att kunna begränsa detta till 4 eller 8 skulle vara en självklar och logisk sak att stödja. Speciellt för kunder som kör system med 16 eller färre kärnor, eller flera instanser på en box, som inte kan lita på Enterprise-funktioner som Resource Governor (som de flesta företagskunder inte heller kunde bry sig om att använda, IMHO).
Affärsmotiveringen för detta skulle vara densamma som motiveringarna som används för att lägga till MAXDOP-stöd REBUILD, DBCC CHECKDB och dess familj av underhållsoperationer, etc. Du vill förhindra att denna typ av verksamhet tar över alla kärnor, utan att göra något så drastiskt som att stänga av automatiska uppdateringar eller använda MAXDOP för hela instansen – eftersom inte alla har lyxen att underhålla fönster.
Och i det här fallet hjälper inte instansomfattande MAXDOP ändå , eftersom SQL Server 2016 RTM har en bugg där MAXDOP ignoreras för urval av statistikuppdateringar. En fix kommer, men jag tänkte att du borde veta; om detta orsakar dig problem är ett alternativ att använda en lägre kompatibilitetsnivå.
Men jag kommer att upprepa något jag ofta säger:Kompatibilitetsnivån blir alldeles för trång. Om jag vill ha parallell samplade statistik i min databas men jag har tillräckligt många kardinalitetsuppskattningsregressioner för att kräva den gamla CE, måste jag välja det ena eller det andra.
Och en annan sak:Resource Governor är överdriven för detta användningsfall, och att begränsa kärnanvändningen från statistikuppdateringar borde egentligen inte vara en Enterprise-funktion (precis som REBUILD och CHECKDB som nämns ovan). Säg inte att RG är ett acceptabelt alternativ, eftersom det bara är möjligt för användare med Enterprise Edition *och* arbetsbelastningsklassificeringar som bör begränsas av MAXDOP hela tiden . Jag borde kunna begränsa detta genom specifik operation (eller, säg, endast för mina största/problemtabeller), inte genom att begränsa en inloggnings hela session.
Hur jag önskar att de skulle göra det
Helst skulle vi kunna ställa in detta på databasnivå med det nya alternativet DATABASE SCOPED CONFIGURATION och på satsnivån med den välbekanta OPTION (MAXDOP n) syntaxen. Uttalandets nivå skulle vinna, och alla statistiska uppdateringar av exempelläge (inklusive automatiska) utan ett uttryckligt MAXDOP-tips skulle falla tillbaka till databasnivåinställningen. Detta skulle tillåta mig att ställa in ett MAXDOP på t.ex. 4 för alla automatiska statistikuppdateringar som sker vid oförutsägbara tider, men 8 eller 16 för manuella operationer i kända underhållsfönster. Som ett exempel.
Om du vill rösta för detta, se följande Connect-objekt och lägg till en affärsmotivering för detta (a la Michael Campbell):
- Anslut #628971:Lägg till MAXDOP-parameter för att uppdatera statistik
Naturligtvis har den artikeln funnits där sedan 2010, så det nämns inte alls om DATABASE SCOPED CONFIGURATION avenue, vilket är anledningen till att jag lämnade en kommentar också.
Under tiden, om du vill inaktivera parallellism för sampelläge, finns det en spårningsflagga för att effektivt återgå till äldre beteende (du kan också göra detta genom att återgå till en kompatibilitetsnivå mindre än 130, men jag rekommenderar inte detta eftersom det påverkar många andra saker). Jag kommer att uppdatera det här utrymmet när jag har fått rätt att avslöja spårningsflaggan offentligt, men just nu håller Microsoft den hårt mot sitt bröst.