Aggiorna statistiche con scansione completa su SQL Server 2014 utilizza il 100% della CPU, su 2008 R2, il 15%

Perché le statistiche di aggiornamento della scansione completa utilizzano il 100% della CPU su SQL Server 2014 quando utilizza forse il 20% della CPU su SQL Server 2008 R2, per le stesse tabelle, con funzionalità hardware simile?

Ho esaminato MAXDOPaltre opzioni e non vedo davvero nulla che risalti. Mi rendo conto che potrebbero esserci impostazioni che potrebbero causare questo, ma le impostazioni sono molto simili per entrambi i database (ad esempio, MAXDOPè 4 per entrambi, con entrambi i core multipli). Entrambi sono Enterprise Edition.

C'è qualcosa di "diverso" in SQL Server 2014 rispetto a SQL Server 2008 R2 che potrebbe spiegarlo? Ho l'opzione di memoria al 90% per entrambi i server. Qualche idea su cosa cercare?

Eseguo le statistiche di aggiornamento con scansione completa (100%) una volta alla settimana su due server utilizzando SQL Server 2008 R2 / SP3 e SQL Server 2014 / SP2 e i database hanno la stessa struttura. Sul server 2008 R2 le statistiche di aggiornamento di due tabelle molto grandi richiedono diverse ore, che è quello che mi aspetto, ma la CPU rimane sotto il 20% circa di utilizzo per tutto il tempo. Sul server 2014, tuttavia, la CPU passa al 100% per circa 40 minuti. Le tabelle sono un po 'più piccole sul server 2014. Vedo questo utilizzando i menu di analisi di SQL Monitor.

Ecco l'output del file di registro Ola su SQL Server 2014, la CPU passa al 100% da circa 2:10 a 2:45:

Date and time: 2017-06-24 02:10:20  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000005_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:07:48  
Date and time: 2017-06-24 02:18:08  

Date and time: 2017-06-24 02:18:08  
Command: UPDATE STATISTICS [InVA].[dbo].[AuditField] [_WA_Sys_00000006_15502E78] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:32:22  
Date and time: 2017-06-24 02:50:30  

Ecco l'output del file di registro Ola su SQL Server 2008 R2 per le due statistiche sopra, ma la CPU arriva forse al 15%:

Date and time: 2017-06-24 03:30:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000003_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:05:00  
Date and time: 2017-06-24 03:35:32  

Date and time: 2017-06-24 03:35:32  
Command: UPDATE STATISTICS [InGA].[dbo].[AuditField] [_WA_Sys_00000004_0425A276] WITH FULLSCAN  
Outcome: Succeeded  
Duration: 00:52:31  
Date and time: 2017-06-24 04:28:03

Non posso eseguirli con il server maxdop = 1 poiché ciò elimina tutta la generazione di piani paralleli e ciò potrebbe danneggiare l'applicazione. Ho intenzione di andare nella direzione opposta e aumentarlo a 8 (ci sono 16 core sulla scatola) e vedere cosa succede. Può andare più veloce per ridurre la durata del pegging della CPU. Questo lavoro viene eseguito mentre gli utenti sono per lo più andati.

Gli aggiornamenti delle statistiche possono andare in parallelo in base a molte opzioni diverse in SQL Server:

• Soglia di costo per il parallelismo : una query deve essere così alta per guidare il treno del parallelismo. I tuoi due server potrebbero avere impostazioni CTFP diverse che causano l'aggiornamento a thread singolo dell'aggiornamento 2008R2, mentre quello del 2014 può essere multi-thread.
• Massimo grado di parallelismo : determina il numero massimo di core che una query può utilizzare al massimo se SQL Server decide di parallelizzarlo fino a quel punto. Il box 2008R2 potrebbe avere MAXDOP impostato su 1, mentre il box 2014 potrebbe averlo impostato sul valore predefinito 0 (illimitato).
• Resource Governor : questa funzione Enterprise Edition consente di limitare gruppi di utenti o applicazioni diversi a MAXDOP diversi.

Nelle versioni successive di SQL Server (2016 e successive), questo diventa ancora più complicato:

• Opzioni con ambito a livello di database : è possibile fare clic con il pulsante destro del mouse su un database, accedere alle proprietà e impostare il livello MAXDOP per quel database.
• Suggerimenti sul parallelismo statistico - a partire da SP2 2016, le istruzioni per la creazione e l'aggiornamento delle statistiche accettano i suggerimenti MAXDOP

Come hai notato, il tuo 2008R2 sta andando a thread singolo, mentre quello del 2014 sta a thread multipli (finendo così più velocemente, ma massimizzando la CPU mentre è in esecuzione).

Per trovare il giusto equilibrio per i tuoi lavori statistici, pensa a:

• Quali altri carichi di lavoro stanno accadendo nel database contemporaneamente? Puoi permetterti di dominare la scatola durante brevi periodi? Ad esempio, nei data warehouse che rimangono inattivi durante la maggior parte delle ore del fine settimana, ho visto gente scricchiolare sugli aggiornamenti delle statistiche con scansioni complete quando sanno comunque che nessuno sta usando il server. In ambienti transazionali pesanti, è necessario iniziare a utilizzare meno impatto per le attività di manutenzione se gli utenti si lamentano anche durante i periodi di mezzanotte.
• FullScan è davvero necessario? Stai visualizzando query che ottengono buoni piani solo quando usi l'opzione fullscan o la stai semplicemente facendo come una best practice? Man mano che il database cresce, se i tuoi investimenti hardware non tengono il passo, potresti dover iniziare a fare dei compromessi nel campionamento delle statistiche piuttosto che eseguire scansioni complete.
• Puoi aggiornare le statistiche meno spesso? Ad esempio, aggiorna 1/4 delle tue statistiche ogni fine settimana e poi ogni mese tutto riceverà aggiornamenti sulle statistiche?
• Puoi aggiornare meno oggetti? Spesso vedo persone che aggiornano le statistiche anche su enormi tabelle di controllo o di archivio semplicemente perché sono state fatte alcune decine di nuovi inserti, ma quegli inserti non influenzano davvero le statistiche sul tavolo (e nessuno lo sta interrogando comunque).

_{Risposta wiki della community :}

Migliore ipotesi: il piano scelto per aggiornare le statistiche è parallelo o più parallelo sulla casella 2014 rispetto alla casella R2 del 2008.

Le statistiche di aggiornamento parallelo fullscansono in circolazione dal 2005 e per le statistiche campionate a partire dal 2016, vedere Aggiunte allo Strumento per ottimizzare le query in SQL Server 2016 di Gjorgji Gjeorgjievski sul blog del motore di database di SQL Server.

Se si dispone di Enterprise Edition, è possibile utilizzare Resource Governor per limitare la CPU utilizzata dal lavoro di manutenzione.

Prendi in considerazione anche la possibilità di votare per il suggerimento Connect Aggiungi MAXDOPparametro a Aggiorna statistiche di Javier Villegas.

Domande e risposte correlate: aggiornamento delle statistiche parallele