Tengo una fuente de base de datos PostgreSQL heredada (ODBC) que intento migrar al nuevo esquema de SQL Server usando SSIS. Recibo una advertencia que dice:
El método de búsqueda 'Fila por fila' se aplica porque la tabla tiene columnas de LOB. El contenido de la columna es LOB
La cuestión es que ninguna de las columnas realmente necesita ser LOB. Hay algunos que son tipos de TEXTO, pero podrían caber fácilmente dentro de un varchar (max). Sin embargo, aún más extraño, la mayoría ya son varchars, pero parece que cualquier cosa sobre varchar (128) se está tratando como si fuera un LOB (por adelantado, el tipo de datos es DT_NTEXT).
Intenté hacer un comando SQL manual donde fundí explícitamente cada tipo de cadena en un varchar de una longitud adecuada en la instrucción select, y todavía se están configurando como DT_NTEXT en la fuente ODBC.
No soy un DBA, así que es muy posible que esté haciendo algo realmente estúpido. Solo me gustaría saber la mejor manera de asegurarme de que los tipos terminen como varchars para que pueda obtener lotes. ¿Algunas ideas?
En caso de que sea importante, estoy usando SSIS-BI 2014 dentro de Visual Studio 2013.
fuente
varchar(max)como una abreviatura para decir que los datos de la columna pueden caber dentro del tamaño máximo de varchar, que es alrededor de 4000, para los propósitos de SSIS, creo. En realidad no estoy lanzando nadavarchar(max); sin embargo, eché algunas columnas avarchar(4000), solo para estar seguro.Respuestas:
Aparentemente, esto se reduce a SSIS que trata cualquier varchar mayor de 128 como NTEXT. No estoy seguro de por qué. Sin embargo, puedo entrar en las propiedades avanzadas de la fuente ODBC y volver a cambiar los tipos a algo como DT_WSTR. Lo que parece funcionar en su mayor parte.
Sin embargo, sí determiné que algunas de las tablas con las que estoy tratando en realidad transportan más de 4000 bytes en algunas de sus columnas TEXT, por lo que desafortunadamente tengo que dejar esas columnas como DT_NTEXT para evitar el truncamiento (SSIS no permitirá configura un tipo DT_WSTR con más de 4000 bytes). Supongo que en estos casos, solo estoy atrapado con la búsqueda fila por fila, pero al menos pude arreglar algunas tablas.
fuente
Utilicé la conversión de datos para el varchar mayor que 128 como NTEXT, pero lo que eliminó el error para mí eventualmente es configurar Validar datos externos en Falso.
fuente
Esta solución funcionó para mí:
Eliminé el error cambiando el parámetro Max Varchar en la propiedad del origen de datos. Vaya al administrador de conexión. Seleccione la opción de compilación junto a la cadena de conexión. Haga clic en el botón de conexión para acceder a más opciones. Cambia el valor de Max Varchar.
fuente
En mi caso, la fuente es Filemaker ODBC, que también trata el texto largo como tipo de datos LOB. Mi paquete solía colgarse durante mucho tiempo debido a la disminución extrema en el rendimiento del método de búsqueda Fila por fila porque la tabla tiene columnas LOB. Por lo tanto, mientras se implementaba, solía agotar el tiempo de espera después de un largo tiempo y finalmente falla.
Estoy compartiendo la solución real que funcionó a las mil maravillas. Un día por valor de más de 30k de extracción de datos tipo LOB me llevó aproximadamente 10 minutos ::
Baje las DefaultBufferMaxRows a 1 y aumente DefaultBufferSize al máximo, es decir, 100 MB. Luego cambie el DSN ODBC de origen marcando la opción 'tratar texto como varchar largo'. Y mapee los tipos de datos tal como son de origen a destino (sin ningún cambio en el editor avanzado en origen).
fuente