Ambientazione

In un datawarehouse, sto unendo una tabella dei fatti a 20 dimensioni. La tabella dei fatti ha 32 milioni di righe e 30 colonne. Questa è una tabella temporanea di gestione temporanea, quindi non ho a che fare con altri utenti che leggono o scrivono sul tavolo. Seleziono 10 colonne dalla tabella di base e 20 colonne dalle rispettive dimensioni. Le tabelle delle dimensioni sono piccole (tra 3 e 15.000 righe). I campi su cui sono uniti sono sia numeri interi che nvarchars. Uso un'istruzione SELECT ... INTO. Non ci sono indici nelle tabelle.

La velocità di esecuzione di questa query è troppo lenta per essere utile.

Soluzioni provate

Poiché la query richiede troppo tempo per l'elaborazione, ho provato le seguenti soluzioni:

1. Dividi i 20 join in 4 join su 5 tavoli. Tuttavia, le prestazioni della query rimangono basse.
2. Inserisci gli indici nelle colonne chiave esterna. Nessuna riduzione significativa del tempo.
3. Assicurarsi che i campi della condizione di join siano numeri interi. Ho notato un aumento delle prestazioni del 25%. Non proprio quello che sto cercando.
4. Usa un'istruzione insert in invece di select into. Prestazioni peggiori a causa della crescita dei file di registro, sebbene il database sia in modalità di ripristino semplice.

Questi risultati mi hanno portato a includere il piano di esecuzione effettivo, che mostra che l'89% del costo risiede nell'inserto della tabella . Gli altri costi sono l'8% della scansione della tabella sulla tabella dei fatti e il 2% sulla corrispondenza dell'hash per i join interni.

Domande

1. Quali sono le possibili ragioni dell'inserimento lento della tabella?
2. Quali sono i modi per identificare questo collo di bottiglia senza il piano di esecuzione?
3. Quali azioni posso intraprendere per ridurre il costo dell'inserto della tabella?

Quali sono le possibili ragioni dell'inserimento lento della tabella? Quali sono i modi per identificare questo collo di bottiglia senza il piano di esecuzione?

Leggi Come analizzare le prestazioni di SQL Server , in particolare la parte relativa all'analisi dei tempi di attesa per l'esecuzione di singole query .

Quali azioni posso intraprendere per ridurre il costo dell'inserto della tabella?

Ciò dipenderebbe in gran parte dal risultato dell'analisi delle prestazioni. Innanzitutto, assicurarsi che la parte SELECT sia il più veloce possibile. Supponendo che il problema sia l'inserto a thread singolo completamente registrato, alcune soluzioni sono:

• Utilizzare lo switch di partizione per spostare "in" i dati. Questa è di gran lunga la soluzione migliore. Preparare i dati di gestione temporanea in una tabella di gestione temporanea separata, quindi passare questa tabella di gestione temporanea nella tabella DW. Leggi Trasferire i dati in modo efficiente utilizzando la commutazione delle partizioni .

• Assicurarsi che INSERT sia registrato minimamente. Leggi le operazioni che possono essere minimamente registrate e i prerequisiti per la registrazione minima . Anche se si utilizzano le operazioni di commutazione delle partizioni, vale comunque la pena assicurarsi che la build della tabella di gestione temporanea sia minimamente registrata.

• Assicurati che il tuo sottosistema IO sia in grado di sostenere un carico veloce. Leggi Introduzione agli SSD .

Di seguito è la mia esperienza e potrebbe aiutare chiunque altro là fuori.

Stavamo provando a trasferire alcuni dati da un database a un altro facendo anche alcune trasformazioni nel modo. Testando la trasformazione stavamo facendo molti inserti, sistemando le cose lungo la strada e poi cancellando per testare nuovamente l'inserto. Tuttavia, dopo alcuni inserimenti e troncamenti, le nostre query hanno iniziato a funzionare lentamente e un semplice inserimento ha iniziato a richiedere fino a 9 minuti mentre in precedenza era in esecuzione per circa 3 minuti.

1. Bene, abbiamo iniziato a cercare prima l'ottimizzazione di SELECT. Invece di subquery abbiamo usato #tempTables. Mentre questo ha accelerato un po 'le cose, non è stato ancora soddisfacente.
2. Ciò che ha reso tutta la differenza è stata la ricostruzione dell'indice e un aggiornamento delle statistiche sul database di destinazione e che ha portato l'inserimento in circa 2 minuti.

Quindi prova queste due strategie e vedi come funziona per te.