Condividi tramite


Progettazione dei pacchetti SSIS per il parallelismo (video di SQL Server)

Si applica a: Microsoft SQL Server Integration Services

Autori: Matt Carroll, Microsoft Corporation

Durata: 00.12.37

Dimensioni: 29,2 MB

Tipo: file WMV

Guarda il video

Argomenti correlati:

Creazione e modifica di colonne identificatore

Trasferimento efficiente dei dati mediante lo spostamento di partizioni

Articoli e post di blog correlati (in lingua inglese):

Top 10 SQL Server Integration Services Best Practices

ETL World Record

Altri video (in lingua inglese):

Misurazione e comprensione delle prestazioni dei pacchetti SSIS nell'organizzazione (video di SQL Server)

Ottimizzazione del flusso di dati del pacchetto SSIS nell'organizzazione (video di SQL Server)

Informazioni sui buffer del flusso di dati SSIS (video di SQL Server)

Riepilogo del video

In questo video viene illustrato come migliorare le prestazioni dei pacchetti Integration Services con la progettazione per il parallelismo.

Riconoscimenti

Grazie a Thomas Kejser per il contributo al materiale per la serie di video di SQL Server SSIS: progettazione e ottimizzazione delle prestazioni. Questo video è il quarto della serie.

Grazie a Carla Sabotta e Douglas Laudenschlager per le indicazioni e i preziosi commenti e suggerimenti.

Note tecniche dal video

[!NOTA] Le note tecniche sono estratti scelti dal video.

Questi sono i punti cardine della progettazione parallela: suddivisione del problema, eliminazione dei conflitti e pianificazione efficiente.

L'idea alla base della progettazione parallela è la suddivisione di un problema di grandi dimensioni in parti più piccole e indipendenti da distribuire tra più risorse. Per Integration Services, la suddivisione del problema in parti più piccole si traduce nel partizionamento dei dati da elaborare. Le partizioni dovranno possibilmente essere di dimensioni uguali per consentire pianificazione e distribuzione ottimali.

Il passaggio successivo consiste nell'eliminazione dei conflitti tra queste parti più piccole, in modo che possano essere elaborate in parallelo senza reciproche interferenze. La progettazione dovrà essere senza stato (stateless), nel senso che ogni unità di lavoro sarà autonoma e non avrà bisogno di coordinarsi con elementi esterni per svolgere la propria funzione. Sarà inoltre necessario ridurre la contesa per le risorse esterne.

Infine, le piccole parti di attività indipendenti andranno distribuite perché vengano eseguite più rapidamente. In altre parole, il lavoro va pianificato e distribuito in modo che le risorse più critiche vengano utilizzate in modo efficiente. Inoltre, il tempo va impiegato in modo razionale e le attività prolungate non devono dominare il runtime. Immaginando un diagramma di Gantt delle attività da eseguire, il carico di lavoro deve essere bilanciato in modo che l'intero gruppo di attività finisca il più presto possibile.

Suddivisione del problema

I dati di origine andranno partizionati in blocchi più piccoli, all'incirca delle stesse dimensioni. Questa operazione può essere effettuata basandosi sugli intervalli naturali dei dati, ad esempio il tempo o le aree geografiche. In alternativa, se è disponibile una colonna Identity, è possibile eseguire un calcolo modulare sui valori che contiene per individuare partizioni uguali. Altrimenti, è sempre possibile applicare una funzione hash sulle colonne chiave per produrre partizioni.

Oltre a partizionare la tabella di origine, sarà opportuno partizionare le tabelle di destinazione in modo che corrispondano al partizionamento dei dati di origine. Il comando SQL SWITCH offre un modo molto efficiente di aggiungere e rimuovere partizioni in una tabella.

Eliminazione dei conflitti

Dopo aver suddiviso il problema, è necessario eliminare i potenziali conflitti tra le partizioni create. Una progettazione senza stato (stateless) consente di evitare interazioni complesse ed eventuali conflitti. Per assicurarsi che la progettazione del pacchetto sia senza stato, è necessario passare nel pacchetto tutte le informazioni necessarie allo svolgimento della sua funzione.

Assicurarsi di evitare una contesa tra blocchi. Molte connessioni che effettuano inserimenti nella stessa tabella finiranno con il creare una contesa. Per evitare questa situazione, utilizzare tabelle partizionate e sfruttare i vantaggi offerti da SQL SWITCH.

Fare attenzione ai conflitti dell'hardware di controllo. Se l'I/O su disco costituisce un problema, utilizzare più unità o unità più veloci. Se l'I/O su rete costituisce un problema, aggiungere o aggiornare i controller di rete. Se l'utilizzo della CPU o della memoria costituisce un problema, utilizzare un computer con più processori o più memoria oppure utilizzare più computer. Ricordare che Integration Services è progettato per l'esecuzione in memoria, quindi assicurarsi che ogni pacchetto disponga di memoria sufficiente.

Pianificazione efficiente

Dopo il partizionamento in attività più piccole e l'eliminazione dei conflitti tra tali attività, queste stesse attività andranno pianificate in modo da essere eseguite in modo efficiente. Per creare una pianificazione efficiente, iniziare definendo una coda di priorità del lavoro da eseguire. A questo scopo è ideale una tabella SQL.

Quindi, avviare più copie del pacchetto creato per eseguire il lavoro. Per ottenere questo scopo in modo semplice ed efficace è possibile utilizzare il comando START di Windows per richiamare dtexec.exe. Il numero di pacchetti avviati determina il grado di parallelismo che verrà utilizzato.

Ognuno dei pacchetti elaborerà il lavoro dalla coda di attività in base alla priorità, fino alla conclusione del lavoro. Un ciclo all'interno del pacchetto consente prima di recuperare un'attività dalla coda di priorità e quindi di eseguire il lavoro definito da tale attività, per poi ripetere il processo fino a quando la coda delle attività è vuota.

Demo

Nella prima esecuzione della demo, ogni attività viene elaborata in sequenza da una singola istanza del pacchetto.

Nella seconda esecuzione della demo, due processi funzionano in parallelo. Le attività vengono completate in batch di due e il tempo totale di esecuzione della demo si riduce di quasi la metà, da circa 64 a 36 secondi.

Nella terza esecuzione della demo, quattro processi funzionano in parallelo. Il tempo per le singole attività è salito da 9 a circa 14 secondi e il tempo totale di esecuzione si è ridotto da circa 36 a circa 28 secondi.

Nell'ultima esecuzione della demo, otto processi funzionano in parallelo. Poiché tutte le attività vengono elaborate contemporaneamente, il tempo per ogni attività è salito a circa 27 secondi e il tempo totale di esecuzione è quasi uguale a quello con quattro processi. In questo caso l'I/O su disco si è rivelato un collo di bottiglia perché tutti e otto processi, in reciproco conflitto, hanno cercato di leggere contemporaneamente i file di dati dal disco. Per risolvere questo problema i file dovrebbero essere distribuiti tra più dischi e controller oppure sarebbe opportuno passare a una tecnologia disco più veloce.

Vedere anche

Altre risorse

Team SQLCAT (in lingua inglese)

Guida e informazioni

Assistenza su SQL Server 2008