Tengo un paquete SSIS: dos tareas de flujo de datos, 8 componentes cada una, lectura de dos archivos sin formato, nada espectacular. Si lo ejecuto en BIDS, demora aproximadamente 60 segundos. Tengo un servidor de Sandbox DB con el paquete ejecutándose en un trabajo que también demora 30-60 segundos. En mi servidor de producción, el mismo trabajo con el mismo paquete toma entre 30 segundos y12 horas.

Con el registro habilitado en el paquete, parece que se atasca, inicialmente al menos, en la fase de ejecución previa de una u otra (o ambas) tareas de flujo de datos. Pero también puedo ver los datos que entran, lentamente, en trozos, así que creo que se moverá de allí más tarde. El subsistema IO se ve afectado y el SSIS genera muchos archivos temporales grandes (alrededor de 150 MB). Mis archivos de datos de entrada solo se juntan aproximadamente 24 MB) y está leyendo y escribiendo vigorosamente desde esos archivos (¿golpeando?).

Es de destacar que si apunto mi instancia BIDS del paquete al servidor de producción, ¡solo se demoran unos 60 segundos en ejecutarse! Por lo tanto, debe ser algo con la ejecución de dtexec, no el DB en sí.

Ya he intentado optimizar mi paquete, reduciendo el tamaño del byte de la fila de entrada, e hice que las dos tareas de flujo de datos se ejecutaran en serie en lugar de en paralelo, sin éxito.

Ambos servidores de bases de datos ejecutan MSSQL 2008 R2 de 64 bits, el mismo nivel de parche. Ambos servidores son máquinas virtuales en el mismo host, con la misma asignación de recursos. La carga en el servidor de producción no debe ser mucho mayor que en el servidor de sandbox en este momento. La única diferencia que puedo ver es que el servidor de producción se está ejecutandoWindows Server 2008, mientras que el sandbox está en Windows Server 2008R2.

¡¡¡Ayuda!!! Cualquier idea para probar es bienvenida, ¿qué podría estar causando esta gran discrepancia?

Apéndice A

Así es como se ve mi paquete ...

El flujo de control es extremadamente simple:

El flujo de datos se ve así:

La segunda tarea de flujo de datos es exactamente la misma, solo que con un archivo de origen y una tabla de destino diferentes.

Notas

La restricción de finalización en el flujo de control solo está ahí para hacer que las tareas se ejecuten en serie para tratar de reducir los recursos necesarios al mismo tiempo (no es que haya ayudado a resolver el problema) ... no hay una dependencia real entre las dos tareas.

Soy consciente de los posibles problemas con el bloqueo y el bloqueo parcial de las transformaciones (no puedo decir que las entienda por completo, pero al menos un poco) y sé que el agregado y la combinación de fusión están bloqueando y podrían causar problemas. Sin embargo, una vez más, todo esto funciona bien y rápidamente en todos los demás entornos, excepto en el servidor de producción ... así que, ¿qué da?

El motivo de la combinación de combinación es hacer que la tarea espere a que se completen las dos ramas de la multidifusión. La rama derecha encuentra la fecha y hora mínima en la entrada y elimina todos los registros en la tabla después de esa fecha, mientras que la rama izquierda lleva los nuevos registros de entrada para la inserción, por lo tanto, si la rama derecha continúa antes del agregado y la eliminación, los nuevos registros ser eliminado (esto sucedió). No conozco una mejor manera de manejar esto.

La salida de error de "Eliminar registros" siempre está vacía, esto es deliberado, ya que en realidad no quiero ninguna fila de esa rama en la combinación (la combinación solo está ahí para sincronizar la finalización, como se explicó anteriormente).

Ver comentario a continuación sobre los iconos de advertencia.