Question

我们最近发现一个问题，即有时重新部署SSIS包似乎不包括最新的更改...当我使用记事本搜索dtsx时，我在代码中看到修改后的脚本，所以肯定会有更改。

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

让我觉得我的理论是正确的唯一“证据”是，如果我在某个时刻继续运行包，它会突然转移到新代码。

然而，到目前为止，我还没有找到原因以及如何发生这种情况，如果是......有人可以帮忙吗？

更新 MSDN说：“与早期版本不同，您可以指出脚本是否已预编译，所有脚本都是在SQL Server 2008 Integration Services（SSIS）和更高版本中预编译的。” - 如果通过预编译，它们意味着不是实际的包而是运行预编译的版本（我认为这是因为包本身似乎没有被编译，因为代码在记事本中是可见的）那里必须是一种强制引擎覆盖预编译程序集的方法......但是如何？

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

Answer 1

这听起来有些熟悉我曾经遇到的事情。不幸的是，我不记得当我遇到了这个（所以我无法确定），但我相信我找到的解决方法是确保在关闭窗口之前，我在脚本编辑器（VSTA）菜单中显式调用了Build | Build st_5bd541c294054c25b9e7eb55b92bd0e2命令。（显然，每个脚本的具体项目名称都不同，因为它基于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文档。

Answer 2

您是否查看了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中，打开包，然后右键单击包的背景，并从上下文菜单中选择“Properties”。查看字段VersionBuild。它应该匹配上面SELECT的数字！

我知道这不是您问题的实际解决方案，但它可能有助于找到问题的原因所在。如果数字较旧，则表示您的程序包部署无效。

Answer 3

这并没有专门解决你的问题，但是如果你正在运行基于文件系统的软件包并想要验证正在运行的软件包是你部署的软件包，那么有一种方法可以做到这一点。

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

我不知道这是否会强制SSIS丢弃其缓存并获取新部署的软件包，但我知道您是否手动修改.dtsx软件包的内部版本号然后尝试重新运行它失败的作业步骤，因为包构建与它正在查找的内容不匹配，所以它肯定会对该值进行运行时检查。

重新部署SSIS包 - 缓存？

3 个答案: