Quindi, in SQL Server 2016, gli aggiornamenti delle statistiche che utilizzano la modalità di esempio ora vengono eseguiti in parallelo con il livello di compatibilità 130, ed è così che funziona per impostazione predefinita, per tutti gli aggiornamenti delle statistiche automatici e manuali. Questo è spiegato brevemente qui:
- Aggiunte Query Optimizer in SQL Server 2016
(Anche la documentazione è stata aggiornata, sia l'argomento Livello di compatibilità che l'argomento AGGIORNAMENTO STATISTICHE.)
Non sarebbe bello, tuttavia, poter specificare quante CPU possono essere effettivamente utilizzate per queste operazioni (oltre a consentire semplicemente il limite di 16)? Penso che essere in grado di limitarlo a 4 o 8 sarebbe una cosa ovvia e logica da supportare. Soprattutto per i clienti che eseguono sistemi con 16 o meno core o più istanze su una scatola, che non possono fare affidamento su funzionalità Enterprise come Resource Governor (che la maggior parte dei clienti Enterprise non potrebbe essere disturbata dall'utilizzo, IMHO).
La giustificazione aziendale per questo sarebbe la stessa delle giustificazioni utilizzate per aggiungere il supporto MAXDOP REBUILD, DBCC CHECKDB e la sua famiglia di operazioni di manutenzione, ecc. Si desidera evitare che questo tipo di attività prenda il controllo di tutti i core, senza fare qualcosa di così drastico come disattivare gli aggiornamenti automatici o utilizzare MAXDOP a livello di istanza, perché non tutti hanno il lusso delle finestre di manutenzione.
E in questo caso, MAXDOP a livello di istanza non aiuterà comunque , perché SQL Server 2016 RTM presenta un bug in cui MAXDOP viene ignorato per gli aggiornamenti delle statistiche campionate. È in arrivo una soluzione, ma ho pensato che dovresti saperlo; se questo ti causa un problema, un'opzione consiste nell'utilizzare un livello di compatibilità inferiore.
Ma ribadisco qualcosa che dico spesso:il livello di compatibilità sta diventando troppo affollato. Se voglio statistiche campionate in parallelo sul mio database ma ho abbastanza regressioni della stima della cardinalità da richiedere il vecchio CE, devo scegliere l'una o l'altra.
E un'altra cosa:Resource Governor è eccessivo per questo caso d'uso e limitare l'utilizzo di base dagli aggiornamenti delle statistiche non dovrebbe essere davvero una funzionalità Enterprise (proprio come REBUILD e CHECKDB menzionati sopra). Per favore non dirmi che RG è un'alternativa accettabile, perché è possibile solo per gli utenti con Enterprise Edition *e* classificazioni del carico di lavoro che dovrebbero essere vincolate da MAXDOP tutto il tempo . Dovrei essere in grado di limitarlo con un'operazione specifica (o, diciamo, solo per le mie tabelle più grandi/problematiche), non vincolando l'intera sessione di accesso.
Come vorrei che lo facessero
Idealmente, saremmo in grado di impostarlo a livello di database, utilizzando la nuova opzione DATABASE SCOPED CONFIGURATION, ea livello di istruzione, utilizzando la familiare sintassi OPTION (MAXDOP n). Il livello di istruzione vincerebbe e qualsiasi aggiornamento delle statistiche in modalità campione (incluso automatico) senza un suggerimento MAXDOP esplicito ricadrebbe sull'impostazione del livello di database. Ciò mi consentirebbe di impostare un MAXDOP di 4, ad esempio, per tutti gli aggiornamenti automatici delle statistiche che si verificano in momenti imprevedibili, ma 8 o 16 per le operazioni manuali in finestre di manutenzione note. Ad esempio.
Se vuoi votare per questo, consulta il seguente elemento Connect e aggiungi una giustificazione commerciale per questo (alla Michael Campbell):
- Connetti #628971 :aggiungi il parametro MAXDOP per aggiornare le statistiche
Naturalmente, quell'elemento esiste dal 2010, quindi non si fa menzione del viale DATABASE SCOPED CONFIGURATION, motivo per cui anche io ho lasciato un commento.
Nel frattempo, se vuoi disabilitare il parallelismo per la modalità di campionamento, c'è un flag di traccia per tornare effettivamente al comportamento precedente (puoi farlo anche ripristinando un livello di compatibilità inferiore a 130, ma non lo consiglio perché influenza molte altre cose). Aggiornerò questo spazio quando mi sarà stata data l'autorizzazione a rivelare pubblicamente il flag di traccia, ma in questo momento Microsoft lo tiene stretto al petto.
