Perché le query causano la fuoriuscita di tempdb?


27

sfondo

Sto eseguendo la migrazione di un database da 160 GB da MSSQL 2008 (standard) su un server Win 2008 con RAM da 48 GB a un nuovo server che esegue MSSQL 2012 (edizione Web a 64 bit) su Win 2012 con 64 GB di RAM. Il vecchio server è attivo e sotto carico; il nuovo server non è in produzione. Il nuovo server ha 8 file tempdb (4 GB ciascuno).

Problema

Durante i test sul nuovo server vedo passaggi in numerose query che causano avvisi che menzionano "l'operatore ha utilizzato tempdb per versare dati durante l'esecuzione". Sono stato in grado di evitare i tipi riscrivendo alcune delle query, ma questo non risolve davvero il problema. Le stesse query sul vecchio server non causano sversamenti. Ho letto che gli sversamenti si verificano quando MSSQL non può completare un'operazione in memoria e deve versare / pagina in tempdb. Dovrei essere preoccupato per gli sversamenti?

Esempi

inserisci qui la descrizione dell'immagine

Ho eseguito sp_updatestats sul database, quindi le statistiche dovrebbero essere aggiornate, ma noterai che ci sono alcune discrepanze tra il numero di righe stimato e quello effettivo.

Preoccupazione per la memoria

Ho impostato un'impostazione di memoria massima per MSSQL di 58 dei 64 GB. Attualmente MSSQL ha consumato circa 35 GB di memoria, ma ha un set di lavoro di soli 682 MB. Il vecchio server (anche se in produzione, gestione del carico) ha 44 GB di memoria impegnata in MSSQL di cui 43,5 GB nel suo set di lavoro.

inserisci qui la descrizione dell'immagine

Non so se gli sversamenti potrebbero essere correlati a un'impostazione di memoria: qualcuno ha qualche idea? MSSQL ha attualmente acri di RAM da risparmiare, quindi perché si sta riversando in tempdb per alcuni tipi e corrispondenze hash?


7
L'avviso nel piano di esecuzione è nuovo nel 2012. Hai verificato che non si fosse diffuso sul vecchio server? Stavi monitorando per questo?
Martin Smith,

@MartinSmith ah, non avevo capito che l'avviso era nuovo. Non stavo monitorando gli sversamenti sul vecchio server. Lo indagherò.

1
Punto leggermente tangente ma sono seduto di fronte a un join di 10 tabelle che, per impostazione predefinita, utilizza principalmente i join di unione con stime di riga molto buone che causano sversamenti di livello 0 tempdb e 25s di runtime. Forzare i join hash (e l'ordine) rimuove gli sversamenti e viene eseguito in 9 secondi. Mi chiedo se la fusione tra hash o la fuoriuscita causi la differenza e se l'ottimizzatore stia correttamente ponderando l'effetto di una fuoriuscita apparentemente nota (perché le stime delle righe sono molto buone).
crokusek,

Il nuovo server ha numa hardware?
stacylaray,

Risposte:


28

Ci sono diverse domande qui:

D: Perché le query non erano già state superate?

Lo erano, ma SQL Server Management Studio non ha rivelato questo come un chiaro errore prima di SQL 2012. È un ottimo esempio del motivo per cui quando si esegue l'ottimizzazione delle prestazioni, è necessario andare più in profondità rispetto al piano di esecuzione grafico.

D: Perché le query si riversano sul disco?

Perché SQL Server non ha concesso loro sufficiente memoria per completare le operazioni. Forse il piano di esecuzione ha sottovalutato la quantità di memoria richiesta, o forse la scatola è sotto pressione della memoria, o sono solo grandi interrogazioni. (Ricorda, SQL Server utilizza la memoria per tre cose: memorizzazione nella cache delle pagine di dati non elaborati, memorizzazione nella cache dei piani di esecuzione e area di lavoro per le query. La memoria dell'area di lavoro finisce per essere piuttosto piccola.)

D: Come posso ridurre gli sversamenti?

Scrivendo affermazioni T-SQL di grandi dimensioni, disponendo di statistiche aggiornate, mettendo abbastanza memoria nel server, costruendo gli indici giusti e interpretando i piani di esecuzione quando le cose non vanno come previsto. Scopri il libro di Grant Fritchey query di SQL Server Performance Tuning per le spiegazioni dettagliate di tutte quelle.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.