Volver a implementar paquetes de SSIS - ¿Caché?

Question

Hemos notado recientemente un problema que los paquetes SSIS redistribuidos en algún momento no parecen incluir los últimos cambios ... Cuando busco el dtsx usando el bloc de notas, veo el script modificado en el código para que los cambios definitivamente estén allí.

Mi suposición era que los componentes de scripts de los paquetes de SSIS finalmente se compilan en un ensamblado en algún lugar del proceso; esto es bastante probable ya que me imagino que el código de C# no se puede ejecutar sin algo que lo compile primero. Entonces, en teoría, si estas asambleas terminarían en caché y no se sobrescribirían inmediatamente (por alguna razón) eso explicaría este problema.

La única "evidencia" que me hace pensar que mi teoría es correcta es si continúo ejecutando el paquete en algún momento, de repente cambia al nuevo código.

Sin embargo, hasta ahora no he encontrado por qué y cómo está sucediendo esto, si es ... ¿Alguien puede ayudar?

ACTUALIZACIÓN: MSDN dice: "A diferencia de las versiones anteriores donde se puede indicar si las secuencias de comandos se precompilan, todos los scripts están precompilados en SQL Server 2008 Integration Services (SSIS) y versiones posteriores." - Si por precompilados significan que en lugar del paquete real se ejecuta una versión precompilada (creo que esto porque el paquete en sí no parece compilarse ya que el código es visible en el Bloc de notas) debe haber una forma de forzar al motor a sobrescribir el conjunto precompilado ... pero ¿cómo?

ACTUALIZACIÓN: Uno de los cuatro componentes básicos de SSIS es el servicio Services de SQL ServerIntegration, que es un servicio de Windows. Aparentemente, este servicio almacenará en caché metadatos de componentes/tareas para que el motor de tiempo de ejecución de SSIS pueda sondear el caché para ver qué está instalado, lo que puede ayudar a acelerar los tiempos de carga del paquete. Sin embargo, si los paquetes están almacenados en el sistema de archivos (no en SQL Integration Services) y ejecutados por Agent Jobs, el trabajo del agente utilizará la versión de 64 bits de DTEXEC para ejecutar los paquetes. Todavía no he encontrado evidencia de que el almacenamiento en caché esté involucrado allí, pero ciertamente hay opciones para verificar una serie de parámetros en la fase de validación de la ejecución, como los números de versión, puede ser por una razón.

Answer 1

¿Ha mirado en sysssispackages para comparar el número de compilación de la versión del paquete en msdb con su número de compilación en Visual Studio/SSIS?

SELECT name, verbuild 
FROM msdb.dbo.sysssispackages 
WHERE name LIKE '%bla%' 

(Ajuste cláusula WHERE como sea necesario para encontrar su paquete. No vuelvas "SELECT * FROM msdb.dbo.sysssispackages", ya que contiene el código XML paquete en una de las columnas.)

Y en Visual Studio, abra el paquete, luego haga clic con el botón derecho en el fondo del paquete y seleccione "Propiedades" en el menú contextual. Mire el campo VersionBuild. ¡Debe coincidir con el número de SELECT arriba!

Sé que esto no es una solución real para su problema, pero puede ayudar a localizar dónde está la causa del problema. Si el número es anterior, significa que la implementación de su paquete no funcionó.

Answer 2

Esto no resuelve específicamente el misterio que tiene, pero si está ejecutando paquetes basados ​​en el sistema de archivos y desea verificar que el paquete que se está ejecutando es el que implementó, hay una manera de hacerlo.

1. Construya su paquete.
2. Abrir las propiedades de su paquete y anotar la propiedad "versión de compilación" (alternativamente, abrir la dtsx en libreta y encontrar el DTS:. VersionBuild atributo)
3. de implementar el paquete.
4. En su paso de trabajo Agente SQL, vaya a la pestaña Verificación.
5. Ingrese la compilación de versión en el cuadro de entrada "Verificar compilación de paquete".
6. Ejecute el paso de trabajo.

No sé si esto forzará a SSIS a descartar su caché y obtener el paquete recién implementado, pero sé si modifica el número de compilación del paquete .dtsx a mano y luego intenta volver a ejecutarlo el paso de trabajo falla porque la compilación del paquete no coincide con lo que está buscando, por lo que definitivamente está haciendo una verificación en tiempo de ejecución de ese valor.

Answer 3

Esto suena algo familiar para algo que encontré hace un tiempo. Lamentablemente, no recuerdo exactamente cuando encontré (así que no puedo verificarlo con certeza), pero creo que la solución que encontré fue para asegurarme de que invoqué explícitamente el comando Build | Build st_5bd541c294054c25b9e7eb55b92bd0e2 del editor de scripts (VSTA) menú antes de cerrar la ventana. (El nombre del proyecto específico será diferente para cada secuencia de comandos, obviamente, ya que está basado en un GUID;. Sin embargo, sólo habrá una posible submenú bajo Build)

explícitamente invocando el comando Build asegura que el código binario para la script se codifica en ASCII y se guarda en el XML del archivo .dtsx resultante. Me había acostumbrado a SSIS 2005 siempre construyéndome cada vez que cerraba el editor de scripts. Aparentemente, existen casos extremos extraños en los que SSIS 2008 no siempre genera el proyecto de script cuando se cierra el editor.

Por cierto, los binarios precompilados parecen estar almacenada en una etiqueta del código fuente XML llamado BinaryItem:

<DTS:Executable DTS:ExecutableType="Microsoft.SqlServer.Dts.Tasks.ScriptTask.ScriptTask, Microsoft.SqlServer.ScriptTask, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" DTS:ThreadHint="0"> 
    <DTS:Property DTS:Name="ObjectName">SCR_StepOne</DTS:Property> 
    <DTS:ObjectData> 
     <ScriptProject Name="ST_5bd541c294054c25b9e7eb55b92bd0e2" VSTAMajorVersion="2" VSTAMinorVersion="1" Language="CSharp" EntryPoint="Main" ReadOnlyVariables="User::FileOneName,User::OutputFolder" ReadWriteVariables=""> 
     <BinaryItem Name="\bin\release\st_5bd541c294054c25b9e7eb55b92bd0e2.csproj.dll"> 
      TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
      AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v 
      ZGUuDQ0KJAAAAAAAAABQRQAATAEDADuOb04AAAAAAAAAAOAAAiELAQgAABAAAAAIAAAAAAAAPi8A 
      AAAgAAAAQAAAAABAAAAgAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAMAQIUAABAA 

Podría valer la pena comprobar el origen de la historia del sistema de control de código para ver si eso estaba consiguiendo puestas al día para algunos de esos errores screwy

Advertencia: No he encontrado la documentación oficial de Microsoft sobre esto.