2013-01-22 7 views
10

Da quello che ho letto:SSIS - Destinazione OLE DB - tabella o Vista carico vs Fast-carico

tabella o Vista modalità di accesso ai dati si impegna ogni riga alla volta come una transazione. Quindi, fare un pacchetto di trasferimento di 5 milioni di righe richiede molto tempo (più di 30 minuti).

modalità di accesso ai dati veloce-carico permette di specificare le righe in batch e la dimensione commit durante l'inserimento di destinazione. Ad esempio, l'inserimento di 5 milioni di record richiederebbe poco più di 2 minuti.

Ora si pone la questione in cui uno dei pacchetti SSIS che carica al DW utilizza modalità di accesso ai dati tabella o vista nella destinazione OLE DB. Dalla mia comprensione, questo è al fine di raccogliere le righe di errore che inserisce (vincolo di errore) in una tabella di record di errore. Quindi, abbiamo un processo che richiede oltre 30 minuti. A sua volta, Fast-Load richiederebbe meno di 2 minuti per la stessa azione.

Se comprendo correttamente, fast-carico sarebbe in grado di distinguere quale riga causato l'errore nel batch che a sua volta fallisce completamente i lotti? In tal caso, esiste un metodo alternativo a questa situazione in cui il batch con la riga di errore viene reindirizzato dal vincolo dell'errore e quindi elaborato nella destinazione in un modo in cui i record validi nel batch vengono inviati alla destinazione corretta durante l'invio del registrazione degli errori nella tabella dei log degli errori? È una buona idea anche farlo? È meglio mordere il tipo di pallottola per quanto riguarda la quantità di tempo necessario?

Grazie in anticipo.

risposta

11

Quello che ho visto fare in quella situazione è un approccio fallito a cascata. Tentare di inserire nella destinazione OLE DB in batch successivamente più piccoli per tentare di ottenere tanto in modalità batch prima di avviare gli inserimenti singleton.

Si supponga di avere una dimensione di commit di 10k righe (numero arbitrario, banco di prova per la vostra situazione, ecc). Reindirizzare le righe in errore su una destinazione OLE DB, sempre in modalità Caricamento veloce ma con una dimensione di commit di 2.5k righe. Aggiungi un'altra destinazione ole db, con una dimensione di commit di circa 100 e quindi una destinazione finale in modalità RBAR. È quindi possibile identificare le righe in errore e fare tutto ciò che deve essere fatto con loro.

+0

mi chiedo perché non fai un commit di X file, e se ci sono errori, non falliscono la componente, ma semplicemente reindirizzare le righe di errore direttamente al file flat? - Vedi la risposta di El.HAM – codeputer

+0

@codeputer Non sto fallendo il componente. Abbiamo la stessa risposta, solo termini diversi. L'idea è che tu tenti di impegnarti in una dimensione grande (efficiente) e poi riduci a segmenti più piccoli. Il motivo per ridurre i batch in errore è che ci sono ancora alcune buone file e non vuoi buttarle fuori. La direzione in cui le righe (file flat, tabella, ecc.) Si basano sull'architettura del tuo ETL – billinkc

+0

comprendo le buone righe, ma se le righe che non sono riuscite sono state reindirizzate, il batch non avrebbe avuto successo senza le righe che sono state reindirizzate ? – codeputer

2

Beh ho usato una destinazione in modalità FastLoad e ho reindirizzato le sue file di errore per un'altra destinazione per lo stesso DestinationTable ma in riga dalla modalità di fila.

Non era lento come Riga per riga e non veloce come Fastload ma ha funzionato per me!
Inoltre ho una descrizione di errore e errori reali.

Problemi correlati