Come posso superare le scarse prestazioni di debug di SSIS?

Question

Sto utilizzando SSIS per sincronizzare i dati tra due database. Ho usato SSIS e DTS in passato, ma in genere scrivo un'applicazione per cose di questa natura (sono programmatore e mi risulta più semplice).

Nel mio pacchetto utilizzo un'attività SQL che restituisce circa 15.000 righe. L'ho collegato a un contenitore Foreach e all'interno di ciò assegno i valori della colonna del gruppo di risultati alle variabili, quindi associo tali variabili ai parametri che vengono inviati a un'altra attività SQL.

Il problema che sto riscontrando riguarda il debug e non solo il debug più complicato come i punti di interruzione e la valutazione dei valori in fase di esecuzione. Voglio dire semplicemente che se eseguo questo con il debug piuttosto che senza, ci vogliono ore per completarlo. Ho finito per riscrivere il processo in Delphi, e quello che mi è venuto in mente è il seguente:

Push completo di dati:
Ciò estrae 15.000 righe, aggiorna una tabella di destinazione per ogni riga, quindi estrae 11.000 righe e aggiorna una tabella di destinazione per ogni riga.

Debug:
App Delphi: 139s
SSIS: 4 ore, 46 minuti

Non debug:
App Delphi: 132s
SSIS: 384s

Aggiornamento dei dati:
Ciò estrae 3.000 righe, ma non sono necessari aggiornamenti o apportati alla tabella di destinazione. Quindi estrae 11.000 righe ma, di nuovo, non sono necessari o apportati aggiornamenti alla tabella di destinazione.

Debug:
App Delphi: 42s
SSIS: 1 ora, 10 minuti

Non debug:
App Delphi: 34s
SSIS: 205s

La cosa strana è che ho la sensazione che la maggior parte di questo tempo dedicato al debug sia solo l'aggiornamento degli elementi dell'interfaccia utente in Visual Studio. Se osservo la scheda di avanzamento, un nodo viene aggiunto a un albero per ogni iterazione (in totale migliaia) e questo diventa sempre più lento man mano che il processo procede. Cercare di interrompere il debug di solito non funziona, poiché Visual Studio sembra bloccato in un ciclo che aggiorna l'interfaccia utente. Se controllo il profiler per SQL Server, non viene eseguito alcun lavoro effettivo. Non sono sicuro che la macchina sia importante, ma dovrebbe essere più che all'altezza del lavoro (quad core, 4 gig di ram, scheda video da 512 mb).

Questo tipo di comportamento è normale? Come ho detto, sono un programmatore commerciale, quindi non ho problemi a scrivere un'app per questo genere di cose (in effetti ci vuole molto meno tempo per codificare un'applicazione che "disegnarla" in SSIS, ma io immagino che il margine si ridurrà con più lavoro svolto in SSIS), ma sto cercando di capire dove qualcosa come SSIS e DTS si adatterebbe alla mia cassetta degli attrezzi. Finora nulla mi ha davvero impressionato. Forse sto abusando o abusando in qualche modo di SSIS?

Qualsiasi aiuto sarebbe molto apprezzato, grazie in anticipo!

Answer 1

Il flusso e i loop di controllo SSIS non hanno prestazioni molto elevate e non sono progettati per l'elaborazione di queste quantità di dati. Soprattutto durante il debug - prima e dopo l'esecuzione di ogni attività, il debugger invia notifiche al processo di progettazione, che aggiorna i colori delle forme e questo potrebbe essere lento.

È possibile ottenere prestazioni molto migliori utilizzando il flusso di dati. Il flusso di dati non funziona con le singole righe, funziona con i buffer delle righe - molto più velocemente e il debugger viene informato solo dell'inizio / fine dei buffer - quindi il suo impatto è meno evidente.

Answer 2

SSIS non è progettato per eseguire una foreach del genere. Se stai facendo qualcosa per ogni riga in arrivo, probabilmente vorrai leggerli in un flusso di dati e quindi utilizzare una ricerca o unire l'unione, determinare se eseguire un INSERT (questi si verificano in blocco) o un oggetto comando del database per più SQL UPDATE comandi (un'opzione con prestazioni migliori è quella di raggrupparli nella tabella di gestione temporanea ed eseguire un singolo AGGIORNAMENTO).

In un'altra situazione di sincronizzazione tipica, leggi tutti i dati in una tabella di gestione temporanea ed esegui un AGGIORNAMENTO di SQL Server sulle righe esistenti (INNER JOIN) e INSERT sulle nuove righe (LEFT JOIN, rhs IS NULL). Esiste anche la possibilità di utilizzare server collegati, ma i join possono essere lenti, dal momento che tutti (o molti) i dati potrebbero dover passare attraverso la rete.

Ho pacchetti SSIS che importano regolarmente 24 milioni di righe, inclusa la gestione della conversione e della convalida dei dati e la modifica lenta delle dimensioni utilizzando il componente TableDifference, e si comporta relativamente rapidamente per quella grande quantità di dati rispetto a un programma client separato.

Answer 3

Ho notato che questo è il comportamento, avevo un pacchetto SSIS per le mosse, che ha funzionato da qualche parte nel quartiere di 3 milioni di voci, non è stato possibile eseguire il debug in quanto sarebbe stato eseguito per circa 3-4 giorni.

SSIS è ancora il modo in cui l'ho fatto, semplicemente non "debug" con SSIS, li eseguo quando lavoro con i set di dati completi. Se devo eseguire il debug, utilizzo set di dati molto piccoli.