Quando utilizzare sort_in_tempdb per ricostruire gli indici?

Stiamo discutendo se utilizzare l'opzione SORT_IN_TEMPDB per le nostre tabelle DW. La mia comprensione è che ci sono più scritture quando si utilizza questa opzione, sebbene siano più sequenziali. Abbiamo una SAN (che a volte è stata notoriamente lenta), quindi nel nostro caso vogliamo limitare il più possibile il numero di scritture. Credo che tempdb sia su un LUN separato (set di dischi).

Abbiamo un sacco di spazio su disco nel nostro file di dati e nel nostro file tempdb. In questo caso, trarremmo vantaggio dall'utilizzo di SORT_IN_TEMPDB?

Una cosa che mi ha colpito è stato questo commento su questa risposta

Quando si ricostruisce un indice, è necessario il doppio dello spazio dell'indice + 20% per l'ordinamento. Quindi, in generale, per ricostruire ogni indice nel tuo db hai solo bisogno del 120% del tuo indice più grande nel tuo DB. Se usi SORT_IN_TEMPDB, vinci solo il 20%, hai ancora bisogno di un 100% adizionale nel tuo file di dati. Inoltre, l'uso di sort in tempdb aumenta drasticamente il carico di I / O, poiché invece di scrivere l'indice una volta nel file di dati, ora lo si scrive una volta nel tempdb e quindi lo si scrive nel file di dati. Quindi non è sempre l'ideale.

Sicuramente non vogliamo aumentare il nostro carico di I / O con la nostra SAN lenta / forse erroneamente configurata.

Quale sarebbe il modo migliore per testarlo? Ricostruendo semplicemente la tabella con e senza l'opzione e registrando i tempi?

Modifica : abbiamo 8 file tempdb, ciascuno da 15 GB. Abbiamo impostato i flag TF 1117/1118 e IFI è abilitato. Al momento eseguiamo una combinazione di ricostruzione con l'opzione sort_in_tempdb e senza di essa.

Grazie!

SQL Server 2012 Enterprise

SORT_IN_TEMPDBsignifica che il server SQL utilizzerà tempdbper allocare lo spazio temporaneo invece di allocare spazio nel database utente il cui indice viene ricostruito. Questo significa che avrai bisogno di meno spazio libero nel tuo database utente durante un'operazione di ricostruzione dell'indice e più spazio libero in tempdb.

Ti offre un vantaggio maggiore quando tempdb si trova su un diverso set di dischi (LUN) dal database utente.

Da SORT_IN_TEMPDB Opzione - BOL :

Se l' opzione SORT_IN_TEMPDB è impostata su ON e tempdb si trova su un set separato di dischi dal filegroup di destinazione, durante la prima fase, le letture delle pagine di dati si verificano su un disco diverso dalle scritture nell'area di lavoro di ordinamento in tempdb. Ciò significa che le letture del disco delle chiavi dei dati generalmente continuano più serialmente su tutto il disco e anche le scritture sul disco tempdb sono generalmente seriali, così come le scritture per costruire l'indice finale. Anche se altri utenti utilizzano il database e accedono a indirizzi del disco separati, il modello generale di letture e scritture è più efficiente quando viene specificato SORT_IN_TEMPDB rispetto a quando non lo è.

Assicurati di leggere i requisiti di spazio su disco quando SORT_IN_TEMPDB è ON .

SAN lenta / eventualmente erroneamente configurata

Conosci il punto dolente. Perché non lavori con il tuo amministratore SAN per risolverlo? Una SAN configurata in modo errato o lento causerà tutti i tipi di problemi come la lentezza .

Alcuni punti importanti da notare:

• Utilizzare MAXDOP = 1 durante la ricostruzione di un indice online , altrimenti aumenterà la frammentazione.
• Riforgiare / ricostruire in modo intelligente gli indici in base al livello di frammentazione e ai frammenti di pagina.
• Leggi l'esperienza di SQLFool con la creazione di un indice da 60 GB
• Assicurati di aver configurato correttamente tempdb - TF 1117 (CRESCERE TUTTI I FILE IN UN FILEGROUP EQUALMENTE) e 1118 (SOLO ESTREMI COMPLETI) e avere più file di dati tempdb .

Quale sarebbe il modo migliore per testarlo?

Sì, devi testarlo analizzando i waitstats quando ricostruisci l'indice con e senza SORT_IN_TEMPDB. Misura anche il tempo di esecuzione e quando lo fai in PROD, assicurati di farlo durante una finestra di manutenzione o meno attività del server. Controlla anche i dati di lettura / scrittura e la latenza del registro .

Non sono sicuro che tu abbia l' inizializzazione dei file istantanei , ma ne trarrà vantaggio durante il ripristino, durante la crescita automatica dei file di dati e durante la creazione di un nuovo database (solo per completezza).