重新部署SSIS包 - 缓存？

我们注意到最近有一个问题，重新部署的SSIS包有时似乎没有包含最新的更改......当我使用记事本搜索dtsx时，我在代码中看到修改后的脚本，所以更改肯定存在。重新部署SSIS包 - 缓存？

我的假设是，SSIS包的脚本组件最终被编译到程序中的某个程序集中 - 这很可能是因为我想如果没有先编译它，C＃代码就无法运行。所以在理论上，如果这些程序集最终会被缓存，并且不会立即被覆盖（出于某种原因），这可以解释这个问题。

使我认为我的理论是正确的唯一“证据”是如果我在某个点继续运行包，它会突然转向新的代码。

但是，到目前为止，我还没有找到为什么以及如何发生这种情况，如果是......任何人都可以帮忙吗？

UPDATE： MSDN说：“不像早期版本，你可以指出脚本是否被预编译，所有的脚本在SQL Server 2008集成服务（SSIS）和更高版本预编译的。” - 如果按预编译的，它们表示代替预编译版本运行的实际程序包（我认为这是因为程序包本身似乎没有编译，因为代码在记事本中是可见的），所以必须有一种方法强制引擎覆盖预编译的程序集......但是如何？

UPDATE： 一个SSIS的四个核心部件是SQL ServerIntegration Services服务，这是一个Windows服务。显然这个服务会缓存组件/任务元数据，以便SSIS运行时引擎可以轮询缓存以查看安装的内容，这可能有助于加快程序包加载时间。但是，如果程序包存储在文件系统中（不在SQL集成服务中）并由代理程序作业执行，代理作业将使用64位版本的DTEXEC来执行程序包。我还没有找到有证据表明任何缓存都会涉及到，但是在执行的验证阶段检查一些参数肯定有选项，例如版本号 - 可能是有原因的。

来源

2012-07-05 G Berdal

只是说我们今天在这里有完全相同的问题。重新启动代理程序或SQLSISS都有帮助。 – 2013-05-31 13:24:28

诀窍是从涉及的表中添加和删除列。显然，这不是我们要走的路，我们肯定对这个问题的答案感兴趣 – 2013-06-03 06:22:07

另外：我认为缓存存储在磁盘的某个位置，因为它在服务器重启后仍然存在 – 2013-06-03 06:25:45

您是否查看过sysssispackages，将msdb中包的版本内部版本号与Visual Studio/SSIS中的内部版本号进行比较？

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

（必要时，调整WHERE子句找到你的包。永远不要“SELECT * FROM msdb.dbo.sysssispackages”，因为它包含了一列包XML）

而且在Visual Studio中打开软件包，然后右键单击软件包的背景，然后从上下文菜单中选择“属性”。看看字段VersionBuild。它应该与上面的SELECT匹配！

我知道这不是您的问题的实际解决方案，但它可能有助于找出问题的原因所在。如果该数字较旧，则意味着您的软件包部署无效。

来源

2013-07-02 13:07:17 cmenke

+1好的建议。我们将尝试重现问题，并检查这是否可以帮助我们至少指出这是问题所在。显然我们仍在寻找解决问题的实际解决方案。 – 2013-07-02 13:12:51

现在你可以发表评论;） – 2013-07-02 13:13:17

+ cmenke：你的查询返回8行：SqlTraceCollect，SqlTraceUpload，TSQLQueryCollect，TSQLQueryUpload，PerfCountersCollect，PerfCountersUpload，QueryActivityCollect，QueryActivityUpload。显然这些都不是我的问题。我们的部署过程如下：我们的msi包只是将dtsx复制到文件夹，更改配置文件（对于conn信息等）。然后我们的调度程序运行dtexec/F“％dtsfile％”/ Rep EPW/Conf％dtsconfig％>％logfile％我们是否需要执行其他操作？ – 2013-07-02 13:23:54

这并不能明确解决您的疑惑，但是如果您正在运行基于文件系统的软件包，并且想要验证正在运行的软件包是您部署的软件包，则有一种方法可以做到这一点。

建立你的包。
打开包装上的属性并记下“版本构建”属性（或者，打开记事本中的.dtsx并找到DTS：VersionBuild属性。）
部署您的包。
在您的SQL Agent作业步骤中，转到Verification选项卡。
在“验证包构建”输入框中输入版本构建。
执行作业步骤。

我不知道这是否会强制SSIS抛出它的缓存并获得新部署的包，但我知道如果您手动修改.dtsx包的内部版本号，然后尝试重新运行工作步骤失败，因为包构建与它所寻找的不匹配，所以它肯定会对该值进行运行时检查。

来源

2013-07-02 15:05:27

我认为步骤3和4不适用，因为我们从文件系统运行。 – 2013-07-04 09:21:29

那么，你仍然“部署”你的工作，你只是使用部署到文件系统。而且，对于子类型为SSIS包的任何SQL代理作业，您仍然具有“验证”选项卡。 – 2013-07-08 16:58:59

这听起来有点熟悉我后面碰到的东西。不幸的是，我不记得当我碰到这个（所以我不能确定），但我相信我发现的修复是确保我明确地从脚本编辑器调用Build | Build st_5bd541c294054c25b9e7eb55b92bd0e2命令（VSTA）菜单，然后关闭窗口。（显然，每个脚本的具体项目名称不同，因为它基于GUID;但是，在Build下只会有一个可能的子菜单。）

明确调用Build命令可确保二进制代码脚本获取ASCII编码并保存在生成的.dtsx文件的XML中。我习惯了SSIS 2005，每当我关闭脚本编辑器时，都会随时为我构建。显然，在编辑器关闭时，SSIS 2008并不总是构建脚本项目，这是奇怪的边缘情况。

BTW，预编译的二进制文件似乎是存储在一个称为BinaryItem源XML的标记：

<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

这可能是值得检查你的源代码控制系统的历史，看看是否是得到了一些更新那些棘手的错误。

警告：我还没有找到关于此的官方Microsoft文档。

来源

2013-07-02 21:14:02

我是否认为这只适用于C＃脚本项目？迄今为止，我们还没有真正使用过这些。 – 2013-07-04 08:59:51

我没有检查过，但我期望它对于C＃或VB.NET项目都是一样的（我很确定这是一个SSIS 2008问题）。 – 2013-07-05 03:47:59

当我通过将.dtsx编辑为XML来修改脚本组件时，遇到了这个问题。因为它是通过XML而不是设计器编辑的，所以二进制文件从不重新编译;这是一个“杜？！”时刻。正如你所说，修正是明确重新编译每个编辑的脚本组件。 – uhleeka 2013-11-20 19:23:24

重新部署SSIS包 - 缓存？

回答

相关问题