Evitare il metodo di recupero "Fila per riga" quando si ha a che fare con le colonne LOB di origine

12

Ho un'origine database PostgreSQL (ODBC) legacy che sto tentando di migrare al nuovo schema di SQL Server utilizzando SSIS. Ricevo un avviso che dice:

Il metodo di recupero 'Row by Row' viene applicato perché la tabella ha colonne LOB. Il contenuto della colonna è LOB

Il fatto è che nessuna colonna deve davvero essere LOB. Ce ne sono alcuni che sono tipi TEXT, ma potrebbero adattarsi facilmente all'interno di un varchar (max). Ancora più strano, tuttavia, la maggior parte sono già varchars, ma sembra che qualsiasi cosa su varchar (128) sia trattata come se fosse un LOB (in anticipo, il tipo di dati è DT_NTEXT).

Ho provato ad eseguire un comando SQL manuale in cui ho esplicitamente eseguito il cast di ogni tipo di stringa in un varchar di una lunghezza appropriata nell'istruzione select e sono ancora impostati come DT_NTEXT nell'origine ODBC.

Non sono un DBA, quindi è del tutto possibile che stia facendo qualcosa di veramente stupido. Vorrei solo sapere il modo migliore per garantire che i tipi finissero come varchar in modo da poter recuperare in batch. Qualche idea?

Nel caso in cui sia importante, sto usando SSIS-BI 2014 in Visual Studio 2013.

— Chris Pratt
fonte

3

Quando li hai espressamente espressi nel sistema di origine su dimensioni non massime, era presente in un flusso di dati esistente o ne hai creato uno nuovo o almeno un nuovo componente di origine per esso? Quando si fornisce una query con gli stessi nomi di colonna e solo tipi più magri, alcune volte ciò non si registra come una modifica, quindi l'editor non avvia un processo di raccolta dei metadati (che può essere costoso). Inoltre, un varchar (max) verrà trattato come un LOB per un flusso di dati SSIS e ciò potrebbe danneggiare agilebi.com/jwelch/2010/05/11/…

— billinkc

Nel componente dell'origine dati ODBC, è possibile selezionare una tabella o utilizzare una query. È qui che sto facendo il casting: in una query personalizzata. Ho citato varchar(max)solo una scorciatoia per dire che i dati della colonna possono rientrare nella dimensione massima del varchar, che è di circa 4000, a scopi di SSIS, credo. In realtà non sto lanciando nulla varchar(max); tuttavia, ho lanciato alcune colonne varchar(4000), solo per sicurezza.

— Chris Pratt,

3

Apparentemente questo si riduce a SSIS che tratta qualsiasi varchar maggiore di 128 come NTEXT. Non so perché. Posso, tuttavia, andare nelle proprietà avanzate della sorgente ODBC e cambiare i tipi in qualcosa come DT_WSTR. Che sembra funzionare per la maggior parte.

Tuttavia, ho determinato che alcuni dei tavoli con cui ho a che fare in realtà stanno portando verso l'alto di 4000 byte in alcune delle loro colonne TEXT, quindi purtroppo devo lasciare quelle colonne come DT_NTEXT per prevenire il troncamento (SSIS non permetterà si imposta un tipo DT_WSTR con più di 4000 byte). Suppongo che in questi casi, sono solo bloccato con il recupero riga per riga, ma almeno sono stato in grado di correggere alcune tabelle.

— Chris Pratt
fonte

3

Ho usato la conversione dei dati per varchar maggiore di 128 come NTEXT ma ciò che ha rimosso l'errore per me alla fine è il set Convalida dati esterni su False.

— Ceci
fonte

0

Questa soluzione ha funzionato per me:

Ho rimosso l'errore modificando il parametro Max Varchar nella proprietà dell'origine dati. Vai alla gestione connessione. Seleziona l'opzione di generazione accanto alla stringa di connessione. Fare clic sul pulsante di connessione per accedere a più opzioni. Modifica il valore di Max Varchar.

— Carbon 4horse
fonte

0

Nel mio caso l'origine è ODBC Filemaker che tratta anche il testo lungo come tipo di dati LOB. Il mio pacchetto era bloccato per molto tempo a causa dell'estrema riduzione delle prestazioni del metodo di recupero Row by Row perché la tabella ha colonne LOB. Pertanto, pur essendo distribuito, si usava per il timeout dopo molto tempo e alla fine falliva.

Sto condividendo la soluzione reale che ha funzionato come un incantesimo per me. Un giorno del valore di oltre 30.000 pull di dati di tipo LOB è durato circa 10 minuti per me:

Abbassa DefaultBufferMaxRows fino a 1 e aumenta DefaultBufferSize al massimo, ad esempio 100 MB. Quindi modificare il DSN ODBC di origine selezionando l'opzione "tratta testo come varchar lungo". E mappare i tipi di dati come da origine a destinazione (senza alcuna modifica nell'editor avanzato nella fonte).

— Shatabdi Das Chowdhury
fonte