Problema al ejecutar un paquete SSIS desde un proyecto del catálogo de Integration Services de SQLServer

Problema al ejecutar un paquete SSIS desde un proyecto del catálogo de Integration Services de SQLServer Carlos 16 Junio, 2016 - 13:08

Recientemente he llevado a cabo una migración de un proyecto de SSIS 2008 a SSIS 2010 fruto de una migración de un servidor SQL Server 2008 R2 a un SQL Server 2012.

En primera instancia, tras el proceso de migración y hacer algunos ajustes, todo funcionó correctamente, y todos los paquetes se ejecutaban sin problemas, tanto desde el entorno IDE de Integracion Services, SQL Server Data Tools, como si se programaba su ejecución desde el agente de SQL Server.

Para aprovechar las nuevas características de SQL Server 2012, el siguiente paso fue la conversión de las conexiones de cada paquete a conexiones globales, y cargar el proyecto y los paquetes dentro del catálogo de Integration Services de la nueva base de datos, y configurar un entorno de producción y otro de desarrollo dentro del mismo catálogo para poder así lanzar los mismos procesos en uno u otro entorno de una manera flexible y bien controlada, un gran avance de esta versión de SSIS.

Todo bien menos un problema que surge al programar la ejecución de los paquetes del catálogo desde el agente de SQL Server. La ejecución de los paquetes se lanza correctamente, pero uno de ellos siempre produce una excepción devolviendo un error de memoria. No es problema de la llamada desde el agente porque este paquete en realidad se llama desde otro paquete, que es el que ejecuta el job del agente, y los otros packages a los que llama se ejecutan sin problemas.

Lo más extraño es que este error sólo se produce en la ejecución desde el catálogo de IS de la base de datos, pero si se ejecuta el mismo paquete desde SQL Server Data Tools, tanto directamente como llamándolo desde el otro package, el paquete se ejecuta con normalidad, no devuelve ningún error, y hace todo lo que tiene que hacer.

Es verdad que este package es uno de los que maneja mayor volumen de datos, y por eso en algún punto debe tener algún problema de memoria que lo hace fallar al ejecutarlo desde el catálogo, pero debería funcionar igual desde ambos entornos, no?

¿Alguien se ha encontrado algún problema parecido? ¿Puede ser algún problema de configuración de la base de datos o del entorno de ejecución?

El error de overflow de memoria se puede solucionar configurando los componentes para utilizar buffers de memoria en lugar de utilizar la opción por defecto que no los utiliza, y para más seguridad se puede definir un fichero donde almacenar la caché si la memoria llega a su límite, pero lo raro sigue siendo que con SQL Server 2008 no hubiera ningún problema, y con SQL Server 2012 surjan estos problemas con la gestión de la memoria.

Además me he encontrado otro cliente al que le ha pasado lo mismo al pasar de 2008 a 2012. ¿Alguien sabe si es un problema de la versión, o si no es un problema sino que la gestión de memoria se ha de llevar de otra manera?

¿A alguien le ha pasado lo mismo con SQL Server 2014 o 2016?