La visualizzazione di un piano di esecuzione stimato genera attese CXPACKET, PAGELATCH_SH e LATCH_EX [ACCESS_METHODS_DATASET_PARENT]

Sto eseguendo Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) su una VM 4 vCPU con max degree of parallelismimpostato su 2e cost threshold for parallelismimpostato su 50.

Al mattino, quando provo a visualizzare un piano di esecuzione stimato per una query SELECT TOP 100 , mi imbatto in enormi attese e l'operazione di rendering del piano stimato richiede minuti, spesso volte nell'intervallo 5-7 minuti. Ancora una volta, questa non è l'esecuzione effettiva della query, questo è solo il processo per visualizzare un piano di esecuzione stimato .

sp_WhoIsActivemostrerà PAGEIOLATCH_SHattese o LATCH_EX [ACCESS_METHODS_DATASET_PARENT]attese e quando eseguo lo script WaitingTasks.sql di Paul Randal durante l'operazione mostra CXPACKETattese con i thread di lavoro che mostrano PAGEIOLATCH_SHattese:

* campo descrizione risorsa = exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

I thread di lavoro sembrano riportare statsin memoria l'intera tabella (poiché i numeri di pagina così come i successivi numeri di pagina mostrati dalla query di Paul Randal puntano nuovamente alla chiave cluster per la statstabella). Una volta che il piano è tornato, è sostanzialmente istantaneo per il resto della giornata, anche dopo aver visto la maggior parte del statslogoramento della tabella dalla cache con solo alcuni record rimanenti (che presumo siano stati estratti a causa della ricerca di operazioni da query simili).

Mi aspetterei questo comportamento iniziale se la query si stesse effettivamente eseguendo con un piano che utilizzava gli operatori SCAN, ma perché lo fa quando si valutano i piani di esecuzione per arrivare solo a un operatore SEEK come mostrato nel piano sopra collegato? Cosa posso fare (oltre a eseguire questa dichiarazione prima dell'orario di ufficio in modo che i miei dati siano opportunamente memorizzati nella cache) per migliorare le prestazioni qui? Suppongo che una coppia di indici di copertura sarebbe utile, ma garantirebbero davvero qualsiasi cambiamento nel comportamento? Devo lavorare con alcune limitazioni della finestra di archiviazione e manutenzione qui e la query stessa viene generata da una soluzione del fornitore, quindi qualsiasi altro suggerimento (oltre a una migliore indicizzazione) sarebbe il benvenuto a questo punto.

Sembra che la tua richiesta di un piano di esecuzione effettivo abbia attivato gli aggiornamenti delle statistiche. Dato che dici che questo succede di mattina, immagino che ci sia un processo durante la notte che fa molte modifiche ai tavoli coinvolti?

Pertanto, SQL Server utilizza le statistiche per creare il piano, ha raggiunto la soglia di modifica ed esegue aggiornamenti automatici delle statistiche come parte dell'operazione.

Nell'XML del piano stimato che hai condiviso, vedo queste date di aggiornamento ravvicinate per le statistiche di questa mattina:

LastUpdate="2019-05-06T09:12:49.92"
LastUpdate="2019-05-06T09:12:58.3"
LastUpdate="2019-05-06T09:13:20.33"
LastUpdate="2019-05-06T09:13:09.67"
LastUpdate="2019-05-06T09:12:59.05"
LastUpdate="2019-05-06T09:12:39.56"

Se questi sono molto grandi, tavoli occupati (sembra probabile sulla base delle percentuali di campionamento), allora non è troppo sorprendente che gli aggiornamenti statistiche stanno prendendo un sacco di cavalli.

Quando vedo i tempi di piano stimati lunghi in SSMS, è uno dei seguenti in ordine di probabilità:

1. Query Optimizer ha deciso che era necessario creare o aggiornare le statistiche.
2. La dimensione del piano stimato è molto grande (diciamo,> 10 MB) e SSMS richiede semplicemente molto tempo per visualizzarlo.
3. La compilazione stessa delle query ha richiesto molto tempo a causa dell'utilizzo della CPU nella ricerca di un piano abbastanza buono.
4. Il server è in estrema difficoltà. Ad esempio, potrei dover aspettare che un gateway diventi disponibile.
5. Vari bug che portano a tempi di compilazione estremamente lunghi.

Per la tua situazione, la risposta è quasi sicuramente che SQL Server sta aggiornando o creando statistiche. Ci sono alcuni indizi: la dimensione del piano di query è piccola, il piano di query è relativamente semplice con un basso costo e la CPU di compilazione è significativamente inferiore al tempo di compilazione:

Il nuovo collaboratore Josh Darnell ha anche indicato un buon indizio sull'ultimo tempo aggiornato per le statistiche nell'XML.

SQL Server 2019 introduce un nuovo tipo di attesa, WAIT_ON_SYNC_STATISTICS_REFRESH , per quando le query sono in attesa di aggiornamenti delle statistiche. È molto più facile diagnosticare questo problema su quella versione. Fino ad allora dovrai solo fare affidamento su tecniche indirette.

Le soluzioni alternative includono l'aggiornamento delle statistiche durante un periodo di manutenzione o l'attivazione di Async Statistiche aggiornamento automatico per il database. Si prega di comprendere le ramificazioni complete di tale opzione prima di modificarla. I piani di query verranno creati prima dell'aggiornamento delle statistiche anziché dopo gli aggiornamenti delle statistiche. Per alcuni carichi di lavoro può essere una vittoria enorme. Per altri può fare più male che bene.