Utilizzando SQL Server Business Intelligence Development Studio, eseguo molti file flat nei flussi di dati di destinazione OLE DB per importare i dati nelle mie tabelle di SQL Server. In "Modalità di accesso ai dati" nell'editor di destinazione OLE DB, per impostazione predefinita è "tabella o vista" anziché "tabella o vista - caricamento rapido". Qual è la differenza; l'unica differenza che riesco a percepire è che il carico veloce trasferisce i dati molto più velocemente.
Modalità di accesso ai dati del flusso di dati SSIS: qual è il punto di "tabella o visualizzazione" rispetto al caricamento rapido?
Risposte:
Le modalità di accesso ai dati del componente di destinazione OLE DB sono disponibili in due versioni: veloce e non veloce.
Veloce, "tabella o vista - caricamento rapido" o "tabella o vista variabile del nome - caricamento rapido" significa che i dati verranno caricati in modo basato su set.
Lento: la "tabella o vista" o la "tabella o la variabile del nome della vista" comporteranno che SSIS invii istruzioni di inserimento singleton al database. Se stai caricando 10, 100, forse anche 10000 righe, c'è probabilmente una differenza di prestazioni apprezzabile tra i due metodi. Tuttavia, a un certo punto saturerai la tua istanza di SQL Server con tutte queste piccole richieste difficili. Inoltre, abuserai del diavolo dal registro delle transazioni.
Perché mai vorresti i metodi non veloci? Dati errati. Se avessi inviato 10000 righe di dati e la 9999a riga avesse una data del 29-02-2015, avresti 10k inserimenti atomici e commit / rollback. Se stavo usando il metodo Fast, l'intero batch di 10k righe ne salverà tutte o nessuna. E se vuoi sapere quali righe sono state errate, il livello più basso di granularità che avrai è 10k righe.
Ora, ci sono approcci per ottenere il maggior numero possibile di dati caricati il più velocemente possibile e gestire comunque i dati sporchi. È un approccio fallimentare a cascata e sembra qualcosa del genere
L'idea è che trovi le dimensioni giuste da inserire il più possibile in uno scatto, ma se ottieni dati errati, proverai a salvare i dati in lotti successivamente più piccoli per raggiungere le righe errate. Qui ho iniziato con una dimensione di commit di inserimento massimo (FastLoadMaxInsertCommit) di 10000. Nella disposizione Riga errore, la cambio Redirect Rowda Fail Component.
La prossima destinazione è la stessa di sopra ma qui provo un caricamento veloce e lo salvo in lotti di 100 righe. Ancora una volta, prova o fai finta di trovare una dimensione ragionevole. Ciò comporterà 100 lotti di 100 righe inviate perché sappiamo da qualche parte lì, c'è almeno una riga che ha violato i vincoli di integrità per la tabella.
Aggiungo quindi un terzo componente al mix, questa volta risparmio in lotti di 1. Oppure puoi semplicemente cambiare la modalità di accesso alla tabella dalla versione Fast Load perché produrrà lo stesso risultato. Salveremo ciascuna riga singolarmente e ciò ci consentirà di fare "qualcosa" con le singole righe errate.
Finalmente ho una destinazione sicura. Forse è la "stessa" tabella della destinazione prevista ma tutte le colonne sono dichiarate come nvarchar(4000) NULL. Qualunque cosa finisca a quel tavolo deve essere ricercata e ripulita / scartata o qualunque sia il tuo cattivo processo di risoluzione dei dati. Altri eseguono il dump su un file flat, ma in realtà, qualunque cosa abbia senso per come si desidera tenere traccia dei dati errati funziona.
Il caricamento rapido è ben documentato nelle opzioni FAST LOAD
Conservare i valori di identità dal file di dati importato o utilizzare valori univoci assegnati da SQL Server.
Conservare un valore null durante l'operazione di caricamento di massa.
Controllare i vincoli sulla tabella di destinazione o visualizzare durante l'operazione di importazione in blocco.
Acquisire un blocco a livello di tabella per la durata dell'operazione di caricamento di massa. Specificare il numero di righe nel batch e la dimensione del commit.
Qual è la differenza; l'unica differenza che riesco a percepire è che il carico veloce trasferisce i dati molto più velocemente.
Sotto il cofano, table or viewverrà utilizzato il comando SQL individuale per ogni riga da inserire vs table or view - with fast loadutilizzerà il comando BULK INSERT.
Se vedi le opzioni precedenti che sono disponibili in BULK INSERT ad es. number of rows in the batch= ROWS_PER_BATCHE commit size=BATCHSIZE
Un altro scenario sarà ..
La dimensione massima di commit dell'inserimento predefinita (2147483647) è troppo alta. Quindi, ad esempio, stai inserendo 500 KB di righe e, a causa della violazione di PK, il batch non riesce. In questo scenario, l'intero batch non riuscirà quando si utilizza l'opzione FAST LOAD. Non sarai in grado di ottenere anche la descrizione dell'errore.
È qui che puoi avere table or viewcome destinazione l'output dell'errore. Quindi, su 500K, usi FAST LOAD come inizio con una dimensione di commit dell'inserimento di 5K. Se 1 riga in quel batch fallisce, reindirizzerai il table or viewcaricamento di quel batch 5K - che utilizza l'inserimento riga per riga SOLO per 5K righe e puoi anche reindirizzare l'errore di table or viewun file flat .. in modo che se una riga non riesce il batch se 5K, sarai in grado di individuare cosa ha causato l'errore.
Il vantaggio del metodo precedente è che se nessuna delle righe fallisce, utilizzerà BULK INSERT (caricamento rapido) per l'intero batch.
Gli appassionati di SSIS billinkc hanno risposto a una domanda simile su StackOverflow .