error code 0x80004005 sql-server ssis etl

sql-server - error code 0x80004005 ssis



La tarea de flujo de datos de SSIS se bloquea en la ejecución de la fase de ejecución previa (9)

Espero que esto ayude a alguien. Estaba intentando usar esta fuente OLE DB para ejecutar un SP con un parámetro. No lo necesitaba para devolver nada, así que dejé esa parte fuera. Pero no me lo permitió, gritó "no se devolvió ninguna información de columna por el sql". Así que configuré una declaración de sql ficticio en mi SP, que establecí en nunca verdadero. Pero nunca obtuvo esa columna como salida y el trabajo simplemente se colgó en la fase de ejecución previa. Así que cambié esa prueba para que siempre fuera verdadera, devolví la columna y listo. No hago nada con la columna, pero creo que se necesita allí.

Tengo una tarea de flujo de datos que se cuelga en ejecución.
El flujo es simple, hace dos consultas a diferentes tablas (ambas con un par de uniones), luego ordena y combina los elementos a través de una identificación común, agrega una columna estática a todos los registros, guarda el conteo de filas en una variable de usuario para más adelante utilizar y finalmente inserta en una tabla en otro DB. Estamos utilizando orígenes y destino OLE DB. La fuente es MSSQL 2000 y el destino es MSSQL 2012

Los síntomas:

  • Cuando se ejecuta, el flujo de datos obtiene el ícono amarillo "en ejecución" habitual. Sin embargo, cuando hace doble clic para ver el flujo de datos, ninguno de los elementos tiene una marca amarilla, roja o verde.
  • Esto continúa por largos períodos de tiempo, al principio duró alrededor de 20 minutos, después de eso comenzó a hacerse más largo o simplemente no regresó en absoluto.
  • La salida muestra:
    Información: 0x40043006 en la tabla Load Sandbox, SSIS. Canalización: Comienza la preparación para la fase de ejecución.
    Información: 0x40043007 en la tabla Load Sandbox, SSIS.Pipeline: Comienza la fase de ejecución previa.
    Y nada más hasta que se detenga la ejecución.
  • Sí, esto ha funcionado antes. Y sí, hemos utilizado una única consulta (en un procedimiento almacenado) para realizar este ETL, pero queríamos migrar todos los pasos a SSIS.

    • Soluciones fallidas:

  • No hay búsquedas.
  • El tamaño del búfer predeterminado para el flujo de tareas se aumentó a 40485760 y luego a 80971520.
  • Las filas máximas predeterminadas del búfer para la tarea se establecieron en 1000000.
  • La validación de retraso se estableció en Verdadero para la tarea.
  • Todos los elementos dentro de la tarea se configuraron Validar datos externos en Falso.
  • Ambas consultas tenían:
    CONFIGURAR FMTONLY APAGADO;
    CONFIGURAR NOCOUNT ENCENDIDO;
    añadido al principio.
  • Ambas consultas tenían MAXDOP establecido en 1.
  • Establecer el tiempo de ejecución de ejecución de 64 bits del proyecto en Falso.
  • Se modificó la carga de destino de Tabla o Vista a Tabla o Vista: carga rápida sin bloqueos ni restricciones.
  • Establecer filas por lote a 1000 para una carga rápida.
  • Algunas soluciones alternativas proponen separar el flujo de tareas en dos o más flujos de tareas. Pero esto no es posible, ya que lo que necesitamos hacer es una combinación de la información que se encuentra en ambas consultas de origen.

    • Bits extra: Realmente espero que alguien me pueda ayudar. Soy bastante nuevo en SSIS, esta es la primera vez que lo uso. Normalmente trabajo con Pentaho para mi ETL, pero el cliente necesita la solución que se implementará en SSIS. He estado luchando contra este problema durante un par de días y estoy empezando a quedarme sin ideas para resolverlo.

    Cuando se ejecuta a través de la línea de comandos, también se atasca y obtengo el siguiente resultado:

    Progress: 2013-03-19 14:36:26.21 Source: Load Sandbox Table Validating: 0% complete End Progress Progress: 2013-03-19 14:36:26.21 Source: Load Sandbox Table Validating: 12% complete End Progress Progress: 2013-03-19 14:36:26.22 Source: Load Sandbox Table Validating: 25% complete End Progress Progress: 2013-03-19 14:36:26.22 Source: Load Sandbox Table Validating: 37% complete End Progress Progress: 2013-03-19 14:36:26.23 Source: Load Sandbox Table Validating: 50% complete End Progress Progress: 2013-03-19 14:36:26.25 Source: Load Sandbox Table Validating: 62% complete End Progress Progress: 2013-03-19 14:36:26.25 Source: Load Sandbox Table Validating: 75% complete End Progress Progress: 2013-03-19 14:36:26.25 Source: Load Sandbox Table Validating: 87% complete End Progress Progress: 2013-03-19 14:36:26.25 Source: Load Sandbox Table Validating: 100% complete End Progress Warning: 2013-03-19 14:36:26.26 Code: 0x80047076 Source: Load Sandbox Table SSIS.Pipeline Description: The output column "ITEM_OID (1)" (47) on output "Merge Join Outp ut" (28) and component "Merge Join" (11) is not subsequently used in the Data Fl ow task. Removing this unused output column can increase Data Flow task performa nce. End Warning Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 0% complete End Progress Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 12% complete End Progress Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 25% complete End Progress Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 37% complete End Progress Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 50% complete End Progress Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 62% complete End Progress Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 75% complete End Progress Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 87% complete End Progress Progress: 2013-03-19 14:36:26.27 Source: Load Sandbox Table Prepare for Execute: 100% complete End Progress Progress: 2013-03-19 14:36:26.31 Source: Load Sandbox Table Pre-Execute: 0% complete End Progress Progress: 2013-03-19 14:36:26.31 Source: Load Sandbox Table Pre-Execute: 12% complete End Progress Progress: 2013-03-19 14:36:26.31 Source: Load Sandbox Table Pre-Execute: 25% complete End Progress Progress: 2013-03-19 14:36:26.34 Source: Load Sandbox Table Pre-Execute: 37% complete End Progress Progress: 2013-03-19 14:36:45.69 Source: Load Sandbox Table Pre-Execute: 50% complete End Progress

    Después de eso se congela de nuevo.

    SOLUCIÓN (Publicando esto aquí porque no puedo responder mi propia pregunta por otras 5 horas, lo haré cuando se me permita).
    Finalmente lo tengo
    Resulta que hay un problema con la validación, pero no solo los elementos de SSIS pasan por esa validación, como se indica en la cuarta solución fallida de la pregunta.
    Las CONEXIONES también se validan y tienen su propia propiedad de Validación de retardo, que debe establecerse en verdadero.
    Después de eso, el tiempo de ejecución pasó de más de 40 minutos o no se ejecutó a menos de un minuto para el proceso completo (Esto es solo un paso de un proceso mucho más grande)
    Espero que las personas con este mismo problema puedan encontrar esta solución fácilmente porque hay muchas personas que se encuentran con este problema y casi no hay soluciones publicadas en línea.

    En pocas palabras: compruebe que todos los elementos que participan en la tarea, incluidas las conexiones DB, tengan la propiedad de verificación de retraso establecida en Verdadero.

    Este problema sigue activo con SQL Server 2012/2014.

    Ninguna de las soluciones mencionadas anteriormente ayudó. De hecho, nada cambió retrasando la validación, cambiando la configuración del destino OLD DB o la conexión OLE DB.

    Leyendo el hilo desde este enlace: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/35a484c7-4850-4f86-b14a-5dfb50491ab2/long-duration-preexecute-phase?forum=sqlintegrationservices

    Se sugiere que el problema sea con el plan de ejecución.

    Esto fue cierto para mi caso y al agregar una condición 1 = 1 a mi configuración OLE DB Source, el servidor SQL forzado generó un nuevo plan de ejecución que solucionó el problema para mí.

    Finalmente lo tengo Resulta que hay un problema con la validación, pero no solo los elementos de SSIS pasan por esa validación, como se indica en la cuarta solución fallida de la pregunta. Las CONEXIONES también se validan y tienen su propia propiedad de Validación de retardo, que debe establecerse en verdadero. Después de eso, el tiempo de ejecución pasó de más de 40 minutos o no se ejecutó a menos de un minuto para el proceso completo (esto es solo un paso de un proceso mucho más grande). Espero que las personas con este mismo problema puedan encontrar esta solución fácilmente porque hay mucho. de personas que se encuentran con este problema y casi no hay soluciones publicadas en línea.

    En pocas palabras: compruebe que todos los elementos que participan en la tarea, incluidas las conexiones DB, tengan la propiedad de verificación de retraso establecida en Verdadero.

    Me encontré con el mismo problema hace unos minutos y las sugerencias anteriores no me funcionaron (la validación de retardo = verdadero parece ser la respuesta). Recientemente descubrimos algunos problemas con la detección de parámetros y, una vez que lo solucioné, en mis procedimientos almacenados, mi paquete se ejecutó en <1 min. Considere revisar sus procedimientos almacenados para ver si esta puede ser la causa.

    Obtuve los mismos síntomas pero configuré la validación de retardo en Verdadero en cada componente que no resolvió mi problema

    Lo resolví cambiando el método OLE DB de la tabla o vista al comando sql.

    Saludos.

    Otra cosa que hay que intentar, aparentemente, es marcar la casilla de verificación "Usar tiempo de ejecución de 32 bits": esto es si ve el problema cuando ejecuta el paquete como un trabajo en su servidor DB (que es de 64 bits, y en mi caso en menos, SQL Server 2008R2). Vaya al trabajo, haga clic con el botón derecho en> Propiedades ...> Pasos> haga clic con el botón derecho en el paso de su paquete SSIS> Propiedades ...> General> Opciones de ejecución (pestaña)> Use 32 bit runtime.

    Estaba viendo este problema, pero solo una vez implementé el paquete en el servidor (tenía un proveedor de registro habilitado para poder verlo atascado después de la fase "Pre-Ejecutar"). Siempre funcionó bien en BIDS (y bien en otro servidor, curiosamente… todavía no estoy seguro de por qué).

    Un hilo here me dio una idea de esta solución que parece funcionar, aunque mi problema aparece intermitentemente, así que YMMV. También hay otras posibles soluciones en ese hilo.

    Sé que esto es viejo, pero acabo de encontrar un enlace sobre esto que puede ayudar. Personalmente, estoy usando una vista para exportar solo datos a una base de datos externa, y la validación de los datos lleva mucho tiempo validando la vista.

    https://connect.microsoft.com/SQLServer/feedback/details/258901/ssis-views-as-data-source-very-poor-performance-or-ssis-hangs

    La parte importante de esto es la respuesta de Microsoft.

    Publicado por Microsoft el 4/28/2008 a las 2:45 PM

    Este es un problema conocido y el resultado del diseño actual.

    Hay 2 formas de extraer datos de una vista en el origen de OLE DB:

    1. Utilice el método de acceso "Tabla o vista"

    2. Utilice el método de acceso "Comando SQL" e ingrese una consulta "seleccionar * de ***"

    Un plan de ejecución diferente se genera en los dos enfoques.

    El usado en el primero no es tan eficiente como el segundo.

    Si encuentra el problema de rendimiento al utilizar el primer enfoque, puede cambiar al segundo enfoque como una solución alternativa.

    También hemos publicado este problema en el blog: http://blogs.msdn.com/sqlperf/archive/2007/04/29/set-up-ole-db-source-to-read-from-view-efficiently.aspx .

    Debido a que este es un artículo ''Por diseño'' y creemos que hay una solución alternativa, no proporcionaremos ningún cambio en este momento. Como resultado, estamos cerrando el caso asociado con su presentación. Si no está de acuerdo, no dude en volver a enviarlo.

    Apreciamos su tiempo, esfuerzo y apoyo de SSIS.

    Solucioné mi problema cambiando el modo de acceso a datos al comando SQL y pegando mi vista en el texto del comando SQL en el origen de OLE DB.

    Ya teníamos nuestras Validaciones demoradas configuradas en True y no podíamos / no queríamos cambiarlo a una declaración SQL.
    Encontré ValidateExternalMetadata en los flujos de datos que cambié a False y que parecen funcionar como un campeón.

    Revisé los pasos de OP y él menciona que hicieron eso en el Paso 5